Re: citations: org-cite vs org-ref 3.0
Max Nikulin writes: > On 28/03/2022 20:16, Bruce D'Arcus wrote: >> On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin wrote: >>> >>> John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) >>> https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu you clearly >>> stated a technical limitation that is a real reason why org-cite is not >>> an option for you and for some other users: performance has not been >>> optimized for large BibTeX databases. It is deserved to be mentioned. >> >> FWIW, Ihor posted a patch related to this a week or so ago. > > I am optimistic concerning that patch since a couple of users confirmed > improvement, but it is up to John to decide if it is acceptable in > comparison to org-ref. I am unsure concerning startup time. I think this will be a problem that is processor specific. It is important that org have a reasonable performance here, but I don't think it was a goal to have the fastest bibtex/json/etc. parser available, just a reasonable default that works out of the box. That is, it doesn't take too long to read the database for insertion, and fontification is not a performance breaker, on say a moderate sized database and org-file. Getting high performance from large databases and large files with lots of citations (say a dissertation or big review article) takes some work. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
Messing Emacs-orgmode Digest,
Sorry for the mess I made in my last message :$
Re: org-cite styles as flags (idea)
On Wed, Mar 30, 2022 at 8:36 AM Max Nikulin wrote:
>
> Hi,
>
> In a recent thread it was discussed that currently style selection is
> not always obvious:
>
> John Kitchin. citations: org-cite vs org-ref 3.0.
> Sun, 27 Mar 2022 13:00:40 -0400.
> https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu
>
> > [cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}?
> >
> > Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even,
> > \citenum?
> >
> > I get it, you can define [cite/noauthor/year:] or even [cite/year:] or
> > [cite/y:] and even [cite/citeyear:] to get the command in there, and
> > something for each of those other ones. Maybe even the documented
> > convention will change to some other potentially mnemonic form.
>
> It seems, no backends uses hierarchy of substyles. Please, correct me, I
> may be wrong since I was BibTeX user and have not tried BibLaTeX.
>
> I have an idea to consider each component started from slash as
> independent boolean flags (or constraints), so they can be reordered
>
> /author/bare/caps = /caps/bare/author
An earlier version of the oc processors had that syntax, but Nicolas
found it too complex to implement.
But I'm not sure; it's possible your suggestion differs from that
beyond the syntax.
Practically speaking, it's useful for portability if an author does
"text/x" and an export processor doesn't support "x", that it still
will use "text".
Bruce
> For citeproc.el it is a natural mapping since e.g. noauthor is
> implemented as a value of suppress-author parameter. For BibTeX commands
> it may be described as set of properties, so the code discards ones
> inconsistent with provided criteria. E.g. (:bare t :author nil :noauthor
> t :full nil) for \citeyear, :caps does not matter.
>
> As at was suggested earlier, /year modifier existing in oc-csl should be
> implemented for oc-natbib.
>
> [cite/author/noauthor:...] should generate a warning as an impossible
> combination and fallback to defaults.
>
> The origin of the proposal is the following part of the discussion:
>
> Bruce D'Arcus, Tue, 29 Mar 2022 12:14:03 -0400
> https://list.orgmode.org/caf-fpgocm5m5jzsou-37v77me76ewwg_xcd4d7k30ffxs0h...@mail.gmail.com
> > On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin wrote:
> >
> >> It seems modifiers are set of boolean flags (positive "year" or negative
> >> "suppress-author") in citeproc.el, set of values in natbib, and a kind
> >> of hierarchy in org-cite. From my point of view, set of constrains
> >> (flags) is the most general variant in this list.
> >
> > I think that's right, and is how it's represented in a GUI app like
> > Zotero. But that's not so convenient in a plain text format.
>
> I may easily miss something important making such idea broken. At least
> it looks like a backward-compatible change if old /caps-full is mapped
> to new /caps/full (or /full/caps).
>
>
[O] Google Docs now supports MarkDown, but not Org syntax
Google Docs now supports MarkDown, not Org syntax :(. https://workspaceupdates.googleblog.com/2022/03/compose-with-markdown-in-google-docs-on.html -k.
Re: citations: org-cite vs org-ref 3.0
Am 29.03.2022 um 18:14 schrieb Bruce D'Arcus: On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin wrote: ... You even have managed to convince me that, besides adding missing style names, some existing ones should be adjusted. noauthor/bare for citeyear example makes for me much more sense ... This does need some attention, but there are wrinkles here. Citeyear is specific to author-date styles, while noauthor is intended to be more general. Anyway citation style is rather specific for a particular CSL style. I tried some styles: https://github.com/citation-style-language/styles/blob/master/ieee.csl https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl nature.csl science.csl and for all these styles even "author" is meaningless since they are numeric styles. Yes. I think it's more relevant in author-date to note styles. I believe biblatex has a command relevant here, but Denis knows biblatex better than I. I'm not sure I understand the question here. What command should be in biblatex? There's \citeauthor if that's what you've meant. So it is not more general. Switching CSL style means necessity to update styles in each citations (unless it is possible to specify global or per-cite mapping). Not really. Arguably the most important style is "text", which applies to any output style; author-date, note-based, numeric. When you start getting into some of the others, the range of styles a given style may apply to shrinks. But you might say author-date styles are pretty dependent on such local citation modification. If those are output to a style that has no such notions (like a numeric one), then a processor can just ignore it. Just to add to this: When Bruce and I have worked on that list of styles we found that portability can only be ensured when using high-level commands (such as biblatex's autocite), but once you start using low-level commands like citeyear etc. you really lose that portability to a certain degree. It seems modifiers are set of boolean flags (positive "year" or negative "suppress-author") in citeproc.el, set of values in natbib, and a kind of hierarchy in org-cite. From my point of view, set of constrains (flags) is the most general variant in this list. I think that's right, and is how it's represented in a GUI app like Zotero. But that's not so convenient in a plain text format. But it's a good way to explain the differences. I think it's probably a good idea to add "year" to the latex processors too. I agree. Negations are more confusing when an author needs just year. Well, negations have the advantage of being more portable. Say you have this: Doe argues X and Y [cite/noauthor:@doe]. It's perfectly clear what this should mean in a author-year, author-title or note-based styles, i.e., print the citation without the author element. (That's obviously a simplification since some citations might not have an author element, but let's just go with it for the moment.) In a numeric style you can just ignore the noauthor modifier and fall back to the default numeric citation. Now, consider this instead: Doe argues X and Y [cite/year:@doe]. This might work in author-year styles, but not in author-title, not in note-based styles, and not in numeric styles. Considering the problem that some citations don't have an author element I even considered using style names like [cite/head:@doe] [cite/tail:@doe] or [cite/car:@doe] [cite/cdr:@doe] or [cite/first:@doe] [cite/rest:@doe] But that obviously a bit esoteric. Denis
org-cite styles as flags (idea)
Hi,
In a recent thread it was discussed that currently style selection is
not always obvious:
John Kitchin. citations: org-cite vs org-ref 3.0.
Sun, 27 Mar 2022 13:00:40 -0400.
https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu
[cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}?
Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even,
\citenum?
I get it, you can define [cite/noauthor/year:] or even [cite/year:] or
[cite/y:] and even [cite/citeyear:] to get the command in there, and
something for each of those other ones. Maybe even the documented
convention will change to some other potentially mnemonic form.
It seems, no backends uses hierarchy of substyles. Please, correct me, I
may be wrong since I was BibTeX user and have not tried BibLaTeX.
I have an idea to consider each component started from slash as
independent boolean flags (or constraints), so they can be reordered
/author/bare/caps = /caps/bare/author
For citeproc.el it is a natural mapping since e.g. noauthor is
implemented as a value of suppress-author parameter. For BibTeX commands
it may be described as set of properties, so the code discards ones
inconsistent with provided criteria. E.g. (:bare t :author nil :noauthor
t :full nil) for \citeyear, :caps does not matter.
As at was suggested earlier, /year modifier existing in oc-csl should be
implemented for oc-natbib.
[cite/author/noauthor:...] should generate a warning as an impossible
combination and fallback to defaults.
The origin of the proposal is the following part of the discussion:
Bruce D'Arcus, Tue, 29 Mar 2022 12:14:03 -0400
https://list.orgmode.org/caf-fpgocm5m5jzsou-37v77me76ewwg_xcd4d7k30ffxs0h...@mail.gmail.com
On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin wrote:
It seems modifiers are set of boolean flags (positive "year" or negative
"suppress-author") in citeproc.el, set of values in natbib, and a kind
of hierarchy in org-cite. From my point of view, set of constrains
(flags) is the most general variant in this list.
I think that's right, and is how it's represented in a GUI app like
Zotero. But that's not so convenient in a plain text format.
I may easily miss something important making such idea broken. At least
it looks like a backward-compatible change if old /caps-full is mapped
to new /caps/full (or /full/caps).
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day
> 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é 2022-03-30 10:17:37 Time zone: Europe/Madrid (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no > I have not looked what changed in emacs in respect to timezones. The function `encode-time', which is implemented in C, has changed, since it returns different things in Emacs 27 and Emacs 29, when it receives as argument the return value of (org-parse-time-string ).
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day
On 30/03/2022 14:13, Ignacio Casso wrote: Actually, this only happens with SCHEDULED timestamps, so it might be considered org-mode's fault since the handling of normal and SCHEDULED timestamps is not always consistent. A first step to debug date issues is to check current timezone (getenv "TZ") $ timedatectl I have not looked what changed in emacs in respect to timezones.
Re: #+include vs. resizing & centrering [SOLUTION]
Sorry, I finally found a solution by myself :)
Using a minipage instead of a scalebox tolerates the \begin{center} that is
automatically inserted:
#+LATEX: \center \begin{minipage}[c]{.85\textwidth}
#+INCLUDE: ./test.dot src dot :file test.png
#+LATEX: \end{minipage}
However, if someone has a pure/clean org-mode solution, I would love to learn
it :)
On 3/30/22 11:07, Guillaume MULLER wrote:
> Dear all,
>
> Thanks for org-mode, it is so perfect :)
>
> I'm currently fighting with a problem that I cannot find a solution to
> (either on my own or with help on the web). If someone could help me, I would
> be very thankful.
>
> I have an org-mode file that "includes" ane xternally generated image, like
> so:
>
> #+INCLUDE: ./test.dot src dot :file test.png
>
> The thing is the resulting image is too big. So I want to resize it.
>
> I've tried several things that did not work:
> - add #+ATTR_LATEX: :width xxx before the #+INCLUDE
> - add :width xxx or :scale xxx on the #+INCLUDE line itself
> - ...
>
> Thus I resolved to use plain LaTeX code with something like:
> #+LATEX: \center \scalebox{.85}{%
> #+INCLUDE: ./test.dot src dot :file test.png
> #+LATEX: }
>
> Then the problem is that #+INCLUDE adds a \begin{center}\end{center} around
> the image inclusion, and \scalebox{} does not like that, making the resulting
> .tex file not compile ("perhaps missing \item").
>
> Again, I've tried several unsuccessful things :
> - add #+ATTR_LATEX: :center nil before the #+INCLUDE
> - add :center nil on the #+INCLUDE line itself
> - ...
>
> If anyone has an idea how a can solve the problem of resizing a #+INCLUDE'd
> image, either in plain org or with a LaTeX "warkaround", I would be very
> grateful.
>
> Thanks !
>
> Guillaume MULLER, PhD
--
Guillaume MULLER, PhD
OpenPGP_signature
Description: OpenPGP digital signature
#+include vs. resizing & centrering
Dear all,
Thanks for org-mode, it is so perfect :)
I'm currently fighting with a problem that I cannot find a solution to (either
on my own or with help on the web). If someone could help me, I would be very
thankful.
I have an org-mode file that "includes" ane xternally generated image, like so:
#+INCLUDE: ./test.dot src dot :file test.png
The thing is the resulting image is too big. So I want to resize it.
I've tried several things that did not work:
- add #+ATTR_LATEX: :width xxx before the #+INCLUDE
- add :width xxx or :scale xxx on the #+INCLUDE line itself
- ...
Thus I resolved to use plain LaTeX code with something like:
#+LATEX: \center \scalebox{.85}{%
#+INCLUDE: ./test.dot src dot :file test.png
#+LATEX: }
Then the problem is that #+INCLUDE adds a \begin{center}\end{center} around the
image inclusion, and \scalebox{} does not like that, making the resulting .tex
file not compile ("perhaps missing \item").
Again, I've tried several unsuccessful things :
- add #+ATTR_LATEX: :center nil before the #+INCLUDE
- add :center nil on the #+INCLUDE line itself
- ...
If anyone has an idea how a can solve the problem of resizing a #+INCLUDE'd
image, either in plain org or with a LaTeX "warkaround", I would be very
grateful.
Thanks !
Guillaume MULLER, PhD
OpenPGP_signature
Description: OpenPGP digital signature
Re: Emacs-orgmode Digest, Vol 193, Issue 30
Thanks, Detlef, I re-installed this essential package for me.
El 28/03/2022 a las 18:00, emacs-orgmode-requ...@gnu.org escribió:
Send Emacs-orgmode mailing list submissions to
emacs-orgmode@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/emacs-orgmode
or, via email, send a message with subject or body 'help' to
emacs-orgmode-requ...@gnu.org
You can reach the person managing the list at
emacs-orgmode-ow...@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emacs-orgmode digest..."
Today's Topics:
1. Re: citations: org-cite vs org-ref 3.0 (John Kitchin)
2. Re: citations: org-cite vs org-ref 3.0 (John Kitchin)
3. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus)
4. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus)
5. Re: Is there a maintained calf-calendar fork? (Detlef Steuer)
6. Re: [PATCH] Fix typo in org-todo-list doc string (Bastien)
7. Re: Bug: Incorrect weekday in The Org Manual [9.3
(release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] (Bastien)
8. Re: citations: org-cite vs org-ref 3.0 (Max Nikulin)
9. Re: Faulty SVG width in default HTML export style (Bastien)
10. Re: Custom TODO states for one item (Bastien)
11. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus)
12. ox-latex table tabbing support. (em...@vergauwen.me)
--
Message: 1
Date: Sun, 27 Mar 2022 13:00:40 -0400
From: John Kitchin
To: Nicolas Goaziou
Cc: Vikas Rawal,emacs-orgmode@gnu.org
Subject: Re: citations: org-cite vs org-ref 3.0
Message-ID:
Content-Type: text/plain; charset=utf-8
Nicolas Goaziou writes:
Hello,
John Kitchin writes:
I do not think it is productive for the community to say or consider it
is a sad situation. Many good things have emerged from these
discussions, even if it is not yet consensus on a solution. It is a
complex problem, with many years of effort by many people on each side.
That is an indication of how ambitious this project is and that there
may be more than one solution that is needed.
[...]
There are more than 8 years of legacy org-ref documents. I have written
40+ scientific papers with it, and countless technical documents with
more than 8000 cite links among them. org-ref has exceeded 190K
downloads from MELPA, so I feel obligated to maintain org-ref for
myself, and those users. org-ref may be heavyweight in bundling a lot of
capability together that could be separated into individual packages,
but it is also convenient for people who need it, and a GitHUB issue or
pull request away from new features. I remain committed to supporting
this, and I do it in a way I can manage, hence the monolithic package
design.
I think there's a misunderstanding here. Org Cite was never meant as
a replacement for Org Ref. It was designed from the beginning as
a framework other libraries could rely on and extend in their own way.
Org Ref could have been one of them.
It looks like a social problem to me. I remember well asking for
feedback when implementing the various prototypes, i.e., ways to make
Org Cite more useful to other libraries. I don't think I got much of it,
barring the cross-references topic, which is not solved. Maybe I was not
explicit enough about what I was expecting. For example, this is—please
correct me if I'm wrong—the first time I read about the "BibLaTeX is not
fully implemented in Org Cite" and "Org Cite is adding an extra
abstraction layer on top of BibLaTeX commands" issues, which are both
trivial to solve, either on the Org Cite or the Org Ref side. But then
again, it is perfectly fine if Org Cite doesn't provide that, as some
libraries can extend it if needed.
I don't think it is the first time I have mentioned biblatex is not
fully implemented, but I am not sure. I have mentioned things like
\citenum somewhere, but it is not the main point.
I know it is not that difficult to add support for LaTeX export in
org-cite, e.g. [cite/num:]. I don't think it is all that easy to add
additional backend support though, for something like [cite/num:] in
HTML or other backends. No doubt, it is not impossible, if someone would
just do it, and that might include extending citeproc too, or developing
some pre-processing function to get a citation number, or something
else. Whether cite/num or any other command exists is not the main
point. What is the point is what mechanisms exist to support the
addition, and the exports to various backends.
Regarding that org-cite adds an abstraction layer, how else could one
interpret this (from
https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax)
other than abstraction:
[cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}?
Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even,
\citenum?
I get it, you can define [cite/noauthor/year:] or
Re: [BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Actually, this only happens with SCHEDULED timestamps, so it might be considered org-mode's fault since the handling of normal and SCHEDULED timestamps is not always consistent. The reason it is different is that `org-agenda-get-timestamps' looks for timestamps in the org buffer using a regular expression that already matches only the expected date. `org-agenda-get-scheduled' can't do that, so it uses a regular expression that matches any timestamp, converts the timestamp to an absolute date using `org-agenda--timestamp-to-absolute', and compares with the current agenda date. `org-agenda-get-timestamps' also has to do something similar for repeated tasks. However, the function used to get the absolute date is different for those timestamps. The function for scheduled timestamps boils down to (time-to-days (encode-time (org-parse-time-string timestamp))) but for repeating timestamps, it boils down to (calendar-absolute-from-gregorian (org-date-to-gregorian timestamp)) For the timestamp "<2022-03-30 mié 23:00>", the second form returns 738244 in my machine, which corresponds to (org-today) at 30/03/2022, but the second returns 738245. Thus, repeated timestamps still work, but scheduled timestamps don't. Is there a reason why two different ways to obtain those dates are used? For completion, I have also checked deadline timestamps, and they suffer from the same problem as scheduled timestamps. A deadline for today at 23:00 will appear in the agenda 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 > 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 have tried to track down the problem, and it doesn't seem to be the > fault of any org-mode code change. The problem is that > (org-time-string-to-time timestamp), defined as (encode-time > (org-parse-time-string timestamp)), returns different things in Emacs 27 > and Emacs 29. > > Let's consider the timestamp "<2022-03-29 mar 23:00>" as an example: > > 1) (org-parse-time-string "<2022-03-29 mar 23:00>") returns (0 0 23 29 3 > 2022 nil nil nil). > > 2) (encode-time '(0 0 23 29 3 2022 nil nil nil)) returns '(25155 29520) > in Emacs 27, but (25155 33120) in Emacs 29 > > 3.1) (time-to-days '(25155 29520)) returns 738243 > > 3.2) (time-to-days '(25155 33120)) returns 738244 > > 4) (org-today) returns 738243 > > Therefore, org-agenda thinks that "<2022-03-29 mar 23:00>" is today in > Emacs 27, but tomorrow in Emacs 29. > > `encode-time' is defined in C, and is probably system dependent, so this > is probably not an org-mode bug. But maybe org-mode code could try to be > smart about this? I don't know if it's even possible. > > And if this should not be fixed in org-mode, do you know were it should? > It could be an Emacs bug? Or maybe the problem is in my system? > > Regards, > > --Ignacio > > > Emacs : GNU Emacs 29.0.50 (build 19, x86_64-pc-linux-gnu, GTK+ Version > 3.24.20, cairo version 1.16.0) > of 2022-03-29 > Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ > /home/ignacio/repos/emacs/lisp/org/)
Re: A question/bug report(?)
On 30/03/2022 12:14, Pedro Andres Aranda Gutierrez wrote:
Thanks for answering :-) I'm currently solving the issue with
#+BEGIN_export LaTeX
\begin{verbatim}[commandchars=\\\{\}]
student@juju:~$ \textbf{sudo bootstrap-juju.sh}
\end{verbatim}
#+END_export
What I was wondering is whether we could have something like:
#+ATTR_LATEX :raw t :attributes [commandchars=\\\{\}]
#+BEGIN_verbatim
student@juju:~$ \textbf{sudo bootstrap-juju.sh}
#+END_verbatim
I think, it is better to add :attributes parameter support to
#+begin_example block. It may be added to org, for a while you can use a
custom derived backend. See info "(org) Advanced Export Configuration"
https://orgmode.org/manual/Advanced-Export-Configuration.html
You need to define an example-block filter, current implementation is
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ox-latex.el#n1853
I never tried it but perhaps it is possible to customize the listings
LaTeX package for automatic highlighting of text after shell prompt. In
Org #+begin_src blocks may use lstlisting environment.
[BUG] org-element-map doco should refer to org-element-parse-buffer [9.5.2 (9.5.2-gfbff08 @ /home/phil/.emacs.d/elpa/org-9.5.2/)]
The documentation for function `org-element-parse-buffer' helpfully directs the user to that of function `org-element-map', but the documentation for the latter makes no mention of `org-element-parse-buffer'. It contains lengthy and helpful explanations of what to do with its `data' parameter, but no hint as to how to obtain that data. Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2021-08-28 Package: Org mode version 9.5.2 (9.5.2-gfbff08 @ /home/phil/.emacs.d/elpa/org-9.5.2/)
[BUG] org-compile-prefix-format doco is incomplete [9.5.2 (9.5.2-gfbff08 @ /home/phil/.emacs.d/elpa/org-9.5.2/)]
Function org-compile-prefix-format in file org-agenda.el (line 6917 in Org 9.5.2) does not properly document parameter `key'. Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2021-08-28 Package: Org mode version 9.5.2 (9.5.2-gfbff08 @ /home/phil/.emacs.d/elpa/org-9.5.2/)
