Hello,
I think I have found a bug in org-crypt, or that org-crypt documentation
is not clear enough. The following configuration snippet in the
org-crypt section of the org manual, as well as the docstring for
org-crypt-key, suggest that a key value of nil can be used to specify
symmetric
Hello,
I think I've found a bug in the agenda display when
'org-agenda-dim-blocked-tasks' is set to 'invisible', and there is a task
that is a habit (i.e., 'STYLE' property set to 'habit') and is blocked
(e.g., because 'org-enforce-todo-dependencies' is set to 't' or there is
an 'ORDERED'
Hello,
I'm not sure what is the expected behaviour of the COMMENT keyword for
TODOs and the agenda, since I only found it in the "Exporting" section
of the manual, but I find the following behaviour inconsistent:
- Tasks with a COMMENT keyword or under a heading with a COMMENT keyword
do not
Hello,
I would like to report a minor typo in the manual, although I'm not sure
if this is the right place (please point me to it if it's not).
In the section Appendix A Hacking -> Using the Mapping API
(https://orgmode.org/manual/Using-the-Mapping-API.html), it says that
org-map-entries returns
Hello,
I recently tried to use (org-capture '(4) key) (i.e., C-u prefix
argument GOTO, so not actually capturing anything, just
moving to the target) as part of the function passed as target for
another capture template, using file+function, as in the example below:
(setq
Max Nikulin writes:
> Ignacio, I think, you can add (require 'org-capture) inside your
> function just before `let' and it would work almost as lazy loading.
Thanks, I was already using (require 'org-capture) in my init file to
solve this. As I said, it's not really a problem for me, I was
> So the problem is in (org-user-idle-seconds), which in my window system
> boils down to a call to (current-idle-time). It should return 0 after
> answering the prompt, but in my system it keeps counting up. At this
> point I stopped investigating since that function is defined in C.
>
I have
> Anyone else duplicating this error would be useful to know.
I can't reproduce this bug in Emacs 27.2.
Please send some more information like your Emacs and Org versions and
your org related configuration. See
https://orgmode.org/manual/Feedback.html for an easy way to include
this information
Hello,
I have fixed the bug reported in
https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00188.html,
https://lists.gnu.org/archive/html/emacs-orgmode/2019-02/msg00333.html,
and
https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00127.html.
In the last of those threads (two
I've also investigated the issue a little bit further and wrote and
email with my conclusions about the same time Max wrote his. I comment
inline about a few of your thoughts:
> For `defcustom' autoload generates no more than
>
> (defvar org-capture-templates nil "...")
>
> It seems, behavior
>>> For `defcustom' autoload generates no more than
>>>
>>> (defvar org-capture-templates nil "...")
>>>
>>> It seems, behavior depends on whether `org-capture-templates' has the :set
>>> attribute.
>> Not really, all defcustoms have a :set attribute, be it passed
>> explicitly as a
>>> My recommendation would be to come up
>>> with a non-org specific example which reproduces the behaviour and then
>>> ask on emacs-devel, using the example to demonstrate the issue.
>>
>> I agree. I'm on it.
After trying to build a simple example I have realized a part of my
analysis was
> I'll write now the email to emacs-devel with all these issues and
> mention in this thread the corresponding debbugs thread in case anyone
> wants to follow it.
54...@debbugs.gnu.org
> While I don't know if this is a bug, it certainly doesn't seem to be
> doing the right thing from an 'intuitive' point of view. I would expect
> when a variable is bound to a value inside a let and a function is then
> called which uses that variable, the initial let bound value should be
>
Hello,
I think I've found a bug with org-capture autoload. If the first time
you use org-capture before it's actually loaded is within a let form binding
org-capture-templates, it produces an error saying that the template was
not found.
For example, if we call this:
(let
Max Nikulin writes:
> On 10/03/2022 19:53, Ignacio Casso wrote:
>> For example, if we call this:
>>(let ((org-capture-templates
>> '(("d" "default" entry
>> (file+headline org-default-notes-file "Tasks"
"Tory S. Anderson" writes:
> Ignacio Casso writes:
>
>>> Anyone else duplicating this error would be useful to know.
>>
>> I can't reproduce this bug in Emacs 27.2.
>
> This is good news: it means I can probably proceed with bisection and
>
Hello,
In Emacs 27.2, with an up to date version of org from ELPA (9.5.2),
org-agenda considers timestamps that appear in property drawers, so the
entry below appears in the daily agenda view.
* Heading
:PROPERTIES:
:timestamp: <2022-03-12 sáb>
:END:
However, in the latest Emacs version
Hello,
> CONTEXT: When I'm idling with the clock running, Org asks if I want
> to resolve the clock when I come back (this is by setting
> org-clock-idle-time).
>
> PROBLEM: I'm not sure how recent the change was, but Org started
> asking me _multiple times_ what I want to do when back.
I have
> Hi,
>
> I don't know how closely it is related to your problem, but I've
> reported another issue revolving around the use of read-char for the
> prompt to resolve clocks. See
> [[https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html]].
>
> Unfortunately I an not advanced
>> What you see in the new Org version is not a bug. Property values are
>> treated as plain text by Org.
>>
>> I was unable to find a place in manual describing that timestamps cannot
>> be placed inside property values:
>> I personally see allowing timestamps (and links) inside property values
> The following patch should fix it:
>
> [4. patch --- text/x-diff; 0001-fixed-bug.patch]
> From bc5092fdef512280b7d7d3aa04f1ba887360a759 Mon Sep 17 00:00:00 2001
> From: Ignacio
> Date: Thu, 24 Mar 2022 01:15:44 +0100
> Subject: [PATCH] fixed bug
>
> ---
> lisp/org/org.el | 3 ++-
> 1 file
Hello,
The manual says in https://orgmode.org/manual/Internal-Links.html#DOCF25
(footnote 25), that in-buffer completion can be used to insert links
targeting a headline in current buffer. So a user can type [[* and C-M-i
and all headlines in the buffer are offered for completion.
However, that
enda as it would a deadline for tomorrow at
22:59, that is, with a warning that it is due in one day, and not as a
deadline for today at 22:59 would appear.
Regards,
Ignacio
Ignacio Casso writes:
> Hello,
>
> After last Saturday's hour change in Spain, org-agenda thinks that
> times
> A first step to debug date issues is to check current timezone
Thanks Max.
> (getenv "TZ")
This returns nil
> $ timedatectl
And this returns
Local time: mié 2022-03-30 12:17:36 CEST
Universal time: mié 2022-03-30 10:17:36 UTC
RTC time: mié
>
> Ubuntu-20.04 LTS has emacs-26.3, so...
>
> Could you, please, try
>
> (encode-time '(0 0 23 29 3 2022 nil -1 nil))
> ^^^
Thanks. Using -1 as DST argument indeed fixes it.
However, while testing that, I've realized that I made a mistake in the
bug report.
> Hmm, I see the problem. I didn't think about that.
> Thank you very much for your suggestion. But what about using
> read-char-exclusive? It seems to have a timeout argument too, and
> should apparently fix the issue (ie. the prompt will no longer
> disappear at the first unintentional click).
Hello,
I think `org-complex-heading-regexp' and
`org-complex-heading-regexp-format' should consider COMMENT keywords, as
they do with TODO keywords, priorities, and tags.
Firstly, with things as they are, different methods for accessing the
headline text are inconsistent. For example, for the
Hello,
After last Saturday's hour change in Spain, org-agenda thinks that
timestamps after 23:00 correspond to the next day in Emacs 29. I'm not
actually sure if that is the reason, since I usually use Emacs 27, but I
guess it must be that if I have found out three days after the hour
change.
I
Hello,
The recent threads about timestamps inside property drawers, which
mentioned the issue of timestamps and links being recognized in contexts
where they should not, had me experimenting a bit, and I found the
following bug (point 3) which was probably introduced by some change
regarding
Hello,
After restricting the agenda to a file for a single agenda command, with
'C-c a < a', and exiting the agenda with 'x', (org-agenda-files) still
returns that file instead of the original list of agenda files. This can
be easily solved using the UNRESTRICTED optional argument in
Ihor Radchenko writes:
> Ignacio Casso writes:
>
>> Link abbreviations do not work inside property drawers and are instead
>> confused with internal links. The following org file illustrates this
>> behavior.
>
> This is to be expected. org-op
Ihor Radchenko writes:
> Ignacio Casso writes:
>
>> So a simple solution to this would be preserving the value of
>> `org-link-abbrev-alist-local' when switching to the temporal buffer. I
>> think this is orthogonal to the issue of the parser, and it's a bug on
>&
>> (cond ((org-in-regexp org-link-any-re)
>>(let ((org-link-abbrev-alist
>> (append org-link-abbrev-alist org-link-abbrev-alist-local)))
>> (org-link-open-from-string (match-string-no-properties 0
>> ...)
>> ...
>> What do you think?
>
> I do not like this
Ihor Radchenko writes:
> Ignacio Casso writes:
>
>>> A better approach could be using org-link-expand-abbrev. It is an API
>>> function and should be forward-compatible.
>>
>> Do you mean something like this?
>>
>> (defun org-open-at-point-globa
Hello,
Link abbreviations do not work inside property drawers and are instead
confused with internal links. The following org file illustrates this
behavior.
#+LINK: org-manual https://orgmode.org/manual/
* Heading
:PROPERTIES:
:myprop: [[org-manual:Hyperlinks.html]]
:END:
- Opening
Max Nikulin writes:
> On 05/04/2022 11:20, Kyle Meyer wrote:
>> Max Nikulin writes:
>>
>>> Emacs copy of Org changed the way of calling `encode-time' as a result
>>> interpretation of last nils returned by `org-parse-string' altered from
>>> ignored to "no DST".
>>>
>> My suggestion:
>>1.
> LGTM! Unless others have objections, I am inclined to merge the patch
> fully. But please add changlog entries to the commit message.
Done. I attach the patch with the new commit message.
>From 26d157aedfaf1496174682a1f9033d83160a06c2 Mon Sep 17 00:00:00 2001
From: Ignacio Casso
Hello,
I'll take this chance to bring this up again, since it's also an issue
concerning org-crypt and it may be relevant if you decide to update
org-crypt's documentation:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-12/msg00675.html.
Regards,
Ignacio
David Masterson writes:
> Ihor
hing code.
Done. I attach the new patch:
>From 54e05dc54fe7091f2d1c7e0c44e01cf5abeb4907 Mon Sep 17 00:00:00 2001
From: Ignacio Casso
Date: Sun, 12 Jun 2022 10:38:53 +0200
Subject: [PATCH] Do not mark buffer as modified with
org-preserve-local-variables
* lisp/org-macs.el (org-preserve-local-variables): Do not mark buffer
as
to do this for org-mode threads?
I know I can reference the Emacs discussion with just bug#54399, but I'm
using long lists.gnu.org/archive/... links for org-mode.
I attach the new patch (same diff, different commit message):
>From c38584ea4e396f56d34ca934582c43436372b102 Mon Sep 17 00:00:00 2001
r-undo-list' so maybe
there are some cases that I have not considered and for which this patch
could be problematic. Let me know what you think:
>From 14506bea13bf6278d95825257d90bbc3390ae8f1 Mon Sep 17 00:00:00 2001
From: Ignacio Casso
Date: Sun, 12 Jun 2022 10:38:53 +0200
Subject: [PATCH] Do not
ch]
>From b20e23013329fab574a4d05eb5be8cde1d43dad1 Mon Sep 17 00:00:00 2001
From: Ignacio Casso
Date: Fri, 10 Jun 2022 12:39:43 +0200
Subject: [PATCH] using `set-default-toplevel-value' in `defcustom' setters
---
lisp/ob-lilypond.el | 2 +-
lisp/ob-shell.el | 2 +-
lisp/org-capture.el | 2 +-
lisp/org-cloc
Hello,
Copying a subtree with `org-copy-subtree' in an org file with local
variables marks the buffer as modified. This is because
`org-copy-subtree' calls `org-preserve-local-variables', which deletes
local variables, executes some body, and then inserts them again, which
results in a modified
> Sounds reasonable. Could you prepare a patch?
> COMMENT should be inside a shy group and note that there might be an
> arbitrary number of space after COMMENT string.
Here it is.
>From 54cd366c97bd64c226cc6fc79e125ee9f026ff66 Mon Sep 17 00:00:00 2001
From: Ignacio
Date: Fri, 6 May 2022
Ihor Radchenko writes:
> Ignacio Casso writes:
>
>>> Sounds reasonable. Could you prepare a patch?
>>> COMMENT should be inside a shy group and note that there might be an
>>> arbitrary number of space after COMMENT string.
>>
>> Here it is.
>
Ihor Radchenko writes:
> Samuel Wales writes:
>
>> some code removes it. for example creating a link to a headline using
>> capture.
>
> Yeah. org-link--normalize-string. But it is internal function, so I would
> not rely on it.
>
> Also, rather than relying on regexps, I would use
>
in git. It's Ignacio
Casso, and I appear in the commit author field as just Ignacio. I have
fixed it now for future commits.
This topic was brought up again in
https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html,
I continue the discussion here:
>> Still, I think it might be interesting to compare this topic with the
>> one I linked in my reply,
>>
I've replied to this email in the original thread about the COMMENT
keyword to continue the discussion there, since it may be a little
off-topic here. --Ignacio
>> Still, I think it might be interesting to compare this topic with the
>> one I linked in my reply,
>>
>> P.D: Just when I was going to send this I tried to investigate it a
>> little bit more to not waste anyone's time, and I found the variable
>> 'org-agenda-skip-comment-trees', which defaults to 't'. So now I see that
>> if it is set to 'nil' it would not be inconsistent to me anymore, but I
51 matches
Mail list logo
