Re: problem with diary sexps
Eric S Fraga writes: > On Tuesday, 5 Apr 2022 at 19:22, Ihor Radchenko wrote: >> More accurate error can be found after setting calendar-debug-sexp to t. >> I got the following backtrace clearly indicating lexical scope issue: > > Which makes sense. The diary code does use entry and date as global > variables so really needs updating... Should be fixed now in f6813dbe. See https://orgmode.org/list/87zgkxjb0m@gnu.org Best, Ihor
[BUG] buffer displays incorrectly after capture
I think this is a real bug. Am I wrong? Seems like it should be easy to fix. On Mon, Apr 4, 2022 at 11:25 AM Skip wrote: > On Fri, Apr 1, 2022 at 3:46 PM Skip wrote: > > Another manifestation of the problem shows up when using > > auto-revert-mode. Starting with the single headline in a folded state > > as above, when I execute the following command in a shell, > > echo "* TODO bar :action:" >>capture.org > > then the capture.org buffer looks like this: > > * TODO foo :action:...* TODO bar :action: > > > > TAB unfolding the first headline shows up like this: > > * TODO foo :action: > > some text...* TODO bar :action: > > I confirmed that the buffer display bug occurs with emacs -Q. Steps to > reproduce: > 1. From a shell, open emacs with an empty file: > emacs -Q test.org > > 2. From emacs, enable auto-revert-mode: > M-x auto-revert-mode > > 3. From another shell, add text to the file: > echo "* foo\nsome text\n" >>test.org > > 4. From emacs, fold the headline: > S-TAB > > 5. From the shell, add more text to the file: > echo "* bar\n" >>test.org > > 6. Observe the incorrect display of the two headlines: > * foo...* bar > > 7. From emacs, fix the buffer display: > S-TAB > > 8. Observe the correct display of the two headlines: > * foo... > * bar > > This bug seems to trigger when text is added indirectly to an org-mode > buffer, via both capture and auto-revert. I suspect it would show up > via refile as well.
Re: How to handle strings with commas in macros?
On 7 April 2022, Kaushal Modi wrote:
The comma needs to be backslash escaped.
{{{m(Denton\, William)}}}
Ref: (org) Macro Replacement
Aha! Thanks to you and Eric for pointing this out. I missed that footnote (and
I should have tried escaping with a backslash anyway, since that's the solution
to so many things).
I'd been looking at the documentation on the web site, as I usually do, but the
pointer to the info page got me looking at that. I'm going to start referring
to it first and see how that goes.
Bill
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
Re: Removing obsolete function `org-truely-invisible-p'.
On 07 Apr 2022, Ihor Radchenko wrote: Karl Fogel writes: Unfortunately, the 'CONTRIBUTE' file at the top level of the Org Mode source tree gives incomplete guidance on commit messages (it just says to follow what Emacs does, so I did that). I didn't realize that https://orgmode.org/worg/org-contribute.html#commit-messages has further, slightly different guidance. Could you elaborate? We have the following in etc/CONTRIBUTE: * Main contribution rules ... See [[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] for guidance on how to contribute effectively. Sure, I'll elaborate. The "..." in your quoted text above contains, among other things, this item: - Org mode no longer uses ChangeLog entries to document changes. Instead, special commit messages are used, as described in the `CONTRIBUTE' file in the main Emacs repository. That item is just one in a list of several items in section 4 (which is under the top-level heading "Main contribution rules"). At the very end of the "Main contribution rules" top-level section comes this line: See [[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] for guidance on how to contribute effectively. So when I went searching in CONTRIBUTE specifically for guidance on commit messages, I searched for the string "commit message". That took me to the item I quote above, which states pretty clearly that the Emacs guidelines apply here. It does not state that there is any other source of guidance about commit messages, nor does it say anything to indicate that Org Mode has commit message guidelines that are a superset of (i.e., more complicated than) Emacs's guidelines. The string "commit message" does not appear anywhere else in Org Mode's CONTRIBUTE file. So, naturally, after I read that item, I assumed that I was ready to write the commit message, since I already knew Emacs's guidelines. Meanhwile, the https://orgmode.org/worg/org-contribute.html page is a bit long, and it starts out with a bunch of very generic guidance that is not useful to developer contributing a code patch. (I'm not saying that material isn't useful, by the way. I think it's good to have it there. I'm just saying it doesn't provide anything useful to one particular demographic. But it's still good because someone might be making some other kind of contribution.) In that page, the part about "Commit messages and ChangeLog entries" starts about three-quarters of the way down. Virtually none of the material preceding it had anything to do with my circumstances, and since I had just seen very clear guidance (in CONTRIBUTE) about how to write commit messages, I timed out before making it that far. A good solution to this would be to revise the item in CONTRIBUTE to make it clear that there is special Org Mode guidance on commit messages that goes beyond what Emacs itself wants. I was too tired to go through the process to contribute that change though, so instead I wrote this long email :-). Thanks! Merged as d80aa2776 to main. Thank you very much! Best regards, -Karl
Re: How to handle strings with commas in macros?
On Thursday, 7 Apr 2022 at 12:29, William Denton wrote:
> on export and LaTeX will format it. That works fine. But in an index of
> names,
> if I want
>
> {{{m(Denton, William)}}}
You have to escape the , unfortunately:
{{{m(Denton\, William)}}}
--
: Eric S Fraga, with org release_9.5.2-427-g40a348 in Emacs 29.0.50
Re: How to handle strings with commas in macros?
On Thu, Apr 7, 2022 at 12:30 PM William Denton wrote:
> I'm using macros to format names in a LaTeX export, like so:
>
> on export and LaTeX will format it. That works fine. But in an index of
> names,
> if I want
>
> {{{m(Denton, William)}}}
>
> then Org takes that as two arguments to the macro, and outputs
>
> \m{Denton}
>
> Is there a way to get around this?
>
The comma needs to be backslash escaped.
{{{m(Denton\, William)}}}
Ref: (org) Macro Replacement
> (1) Since commas separate the arguments, commas within arguments have
to be escaped with the backslash character. So only those backslash
characters before a comma need escaping with another backslash
character.
How to handle strings with commas in macros?
I'm using macros to format names in a LaTeX export, like so:
#+latex_header: \newcommand\m[1]{\textsc{#1}}
#+macro: m \m{$1}
Thus
{{{m(William Denton)}}}
becomes
\m{William Denton}
on export and LaTeX will format it. That works fine. But in an index of names,
if I want
{{{m(Denton, William)}}}
then Org takes that as two arguments to the macro, and outputs
\m{Denton}
Is there a way to get around this?
Thanks,
Bill
--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
Re: Drop defadvice from Org
Hi Ihor, Ihor Radchenko writes: > The change in (eval ...) call inside org-diary-sexp-entry broke sexp > timestamps. See orgmode.org/list/875ynnojvf.fsf@localhost Fixed, thanks! -- Bastien
bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
Consider the following change of `encode-time' calling convention: last 3 elements of the TIME argument as a list should be optional. I mean IGNORED, DST, and ZONE. (encode-time '(0 30 20 07 04 2022 nil -1 nil)) (encode-time '(0 30 20 07 04 2022)) ; currently causes an error Since Emacs-27 time fields as separated arguments are considered obsolete for calls of `encode-time'. Org mode keeps compatibility with Emacs-26 where passing all time components as a single list is not supported. Moreover, some time ago an attempt to use new style argument in the Emacs git repository (the change was never committed to the Org repository) caused a bug with handling of daylight saving time. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54731 for more details, the commit reverted the changes is 8ef37913d3. I have tried to create a compatibility wrapper for Org mode that chooses calling convention of `encode-time' in dependence of Emacs version. I have realized that there are enough call sites where components of time are gathered from scratch and not obtained from e.g. prior call of `decode-time'. It is inconvenient to add 3 extra mandatory components at the each place. I am reluctant to add a helper that accepts 6-components list and adds 3 fields to the end of the list. I am afraid that it may affect e.g. agenda performance. From my point of view it is better to change implementation of `encode-time' so that it may accept 6-component list SECOND...YEAR. It should not add noticeable performance penalty but makes the function more convenient in use. Old-style separate arguments for time components permits optional fields ended with ZONE. I do not mind that it should be deprecated since it is the source of surprise similar to the mentioned bug. Daylight saving time field matters only as a list component and ignored as a separate argument (by the way, it should be stressed in the docstring). It is too easy to confuse list and separate arguments in the code since both ways works but with a subtle difference: nil does not mean ignore the value. (encode-time '(0 30 20 07 04 2022 nil nil nil)) ; wrong! (encode-time 0 30 20 07 04 2022 nil nil nil) ; no problem In the Org code it is unsure which way to call `encode-time' is more convenient. In a half of the cases a list is obtained from another function, but another half is timestamp built from computed components. Unless the inconsistency with DST I would say that both ways to call the function should be supported. So my proposal is to not force Org mode to use new calling convention for `encode-time' till DST and ZONE list components will became optional ones in a released Emacs version. For a while minor changes in a couple of places in Org code should make it immune to accidental usage of new calling convention (modulo compatibility).
Re: org-cite styles don't allow * in them
On Thu, Apr 7, 2022 at 12:17 AM Ihor Radchenko wrote: > "Bruce D'Arcus" writes: > > > On Sun, Apr 3, 2022 at 5:07 PM John Kitchin > wrote: > >> > >> I was looking into using latex commands as styles in org-cite, e.g. > >> > >> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is > not allowed. Could that be allowed? > > > > I have no insight into the restriction, but I hope it can be removed. > > I do like the proposal in general, but I can see a potential issue for > users. Constructs like "word*:" can be recognised as a valid bold > emphasis ending. For example: > > >>> Some *bold emphasis with reference [cite/citet*:@key] will end > >>> at "citet*", but not here*. > That is a fair point, and also an issue with links that have * in them (which is also already allowed). I can't say it has ever been reported as an issue though. > > Note that inserting zero-width space will not only be awkward here, but > also breaks parser: e.g. [cite/citet:@key] is not currently > recognised as a citation. A less awkward solution (IMO) would be to use an entity like ⋆. It is straightforward to add that to the org-element-citation-prefix-re. Then I see something like this. [image: image.png] I don't know how difficult it would be to improve the emphasis handling, it seems like the start/end markers should not cross some element boundaries. > > Best, > Ihor >
Re: Thanks for good docs
I'm in total agreement. The indexing of the org info manual is excellent and generally gets me to what I want very quickly. -- : Eric S Fraga, with org release_9.5.2-424-g09575c in Emacs 29.0.50
