Re: archiving speed [was Re: Tips on maintaining history in Org Mode]
It is for me. However, this all depends on how you configure things. In my case, I have a standard structure for my org files. I have a different org file for each 'topic' and each org file has headings for * Tasks * Notes * Resources * Comms * General and each of those headings has a property list with an ARCHIVE property which looks like %s_archive:: i.e. %s_archive::* Tasks, so when I archive a tree/subtree is is placed under the heading according to the ARCHIVE property for the tree it comes from. almost all data I enter into org files comes via a capture template. All captured data initially goes into a refile.org file and then I refile to the appropriate topic org file each morning. For completed tasks, I will usually marked them with an ARCHIVE tag soon after they have been completed and then every 6 months or so, I will archive into an archive file (where heading hierarchies are retained). This is most common with completed tasks. I have a custom agenda which shows tasks broken up into "Completed", "In Progress", "Next" and "Backlog". I will archive the DONE items so that the "Completed" list in the agenda does ot grow too large. Every 12 months I move the archive files to an archive folder where they are renamed to include the year in the filename. I don't find archiving terribly slow. this is mainly because few of my org files are particularly large (because they are broken up into topics) and because I move older archives out into an archive directory after 12 months. It is very rare that I need to go digging around in archive files (either current or older year archives). Of course this could all change down the track. My org files are slowly getting larger and I expect at some point, I will hit a tipping point where things become slow. So far, even with the larger files (around 5Mb) performance is fine. I also don't put 'everything' in the org file. If I have another file of data, I will just link to that from the org file rather than have that data actually reside in the org file. SO for example, my org-mode.org file has a lot of links to interesting messages from the org list, but the messages themselves are all in my mu4e maildir folders. My main point was that because configuration like mine exist, simply appending archived items to the archive file simply would not work. I like having my archive records in a similar 'shape' to my normal org files because when I do need to dig into the archive, I don't want to have to go through the whole file looking for something. I generally know if I'm looking for an old task, note, general entry or comms record and it is handly to know I only have to look in that section of the file. This is one of the big challenges for org mode. Because it is so flexible and people take advantage of that flexibility, what may appear like a simple way to solve an issue often ends up being far more complex than it initially seemed. If, for exmaple, you could not archive based on heading, date, etc, just appending entries would probably work fine. However, as the archviing policy might be more complex, org needs to examine/parse the archive file to work out where to insert the archived entry. Tim Samuel Wales writes: > what is the current status of hierarchy in archive files? surely they > don't deal with updating categories and updating hierarchy structure > [sounds brittle and syncy]? i'm thinking it isn't hierarchical at > present, except when you have a doneified task with children? > > > On 8/11/21, Tim Cross wrote: >> I think the problem with just using append to file is that it won't >> preserve the shape of the file. For example, if I had a file with >> >> * Notes >> ** Note 1 >>blah blah >> ** Note 2 blah blah >> >> * Tasks >> ** DONE task 1 >> ** TODO Task 2 >> >> and I decide to archive note 1 and task 1, I would like them to both appear >> under the same headings and with the same level. If the process just uses >> append to file, I can have this for the first archiving i.e. >> >> * Noes >> ** Note 1 >> >> * Tasks >> ** DONE task 1 >> >> but then later, I decide to archive note 2, if append file is used, I will >> end up with >> >> * Notes >> ** Note 1 >> >> * Taks >> ** DONE task 1 >> >> * Notes >> ** Note 2 >> >> which is not what I want. I want >> >> * Notes >> ** Note 1 >> ** Note 2 >> >> * Tasks >> ** DONE Task 1 >> >> So, if we want to preserve hierarchies in our archive files and not have >> everything jumbled up together, the system has to parse the file. If you >> are also using something like Categories, then even more work needs to be >> odne to update the category lists. >> >> What I tend to do is mark items with the ARCHIVE tag and leave them in the >> file and then every few months, move archived data to archive files. It >> can still get slow, but I don't do it often, so it isn't too much of a >> hassle. >> >> >> On Thu, 12 Aug 2021 at 08:23, Samuel Wales wrote: >> >>> thanks for the clarification. are you sayin
Re: archiving speed [was Re: Tips on maintaining history in Org Mode]
what is the current status of hierarchy in archive files? surely they don't deal with updating categories and updating hierarchy structure [sounds brittle and syncy]? i'm thinking it isn't hierarchical at present, except when you have a doneified task with children? On 8/11/21, Tim Cross wrote: > I think the problem with just using append to file is that it won't > preserve the shape of the file. For example, if I had a file with > > * Notes > ** Note 1 >blah blah > ** Note 2 blah blah > > * Tasks > ** DONE task 1 > ** TODO Task 2 > > and I decide to archive note 1 and task 1, I would like them to both appear > under the same headings and with the same level. If the process just uses > append to file, I can have this for the first archiving i.e. > > * Noes > ** Note 1 > > * Tasks > ** DONE task 1 > > but then later, I decide to archive note 2, if append file is used, I will > end up with > > * Notes > ** Note 1 > > * Taks > ** DONE task 1 > > * Notes > ** Note 2 > > which is not what I want. I want > > * Notes > ** Note 1 > ** Note 2 > > * Tasks > ** DONE Task 1 > > So, if we want to preserve hierarchies in our archive files and not have > everything jumbled up together, the system has to parse the file. If you > are also using something like Categories, then even more work needs to be > odne to update the category lists. > > What I tend to do is mark items with the ARCHIVE tag and leave them in the > file and then every few months, move archived data to archive files. It > can still get slow, but I don't do it often, so it isn't too much of a > hassle. > > > On Thu, 12 Aug 2021 at 08:23, Samuel Wales wrote: > >> thanks for the clarification. are you saying that, for every archived >> entry, it calculates teh category property, using the original org >> file, in order to add a category property to just one archived entry? >> >> that would certainly slow down more and more, but it sends me back to >> my question about whether append to file would work. >> i.e. build the single entry in a temporary buffer then write that >> region to a file on disk. >> >> On 8/10/21, Ihor Radchenko wrote: >> > Samuel Wales writes: >> > >> >> i should clarify. bulk archiving slows down even with /nonexistent/ >> >> (have not tried empty) archives. as part of normal and expected >> >> operation, bulk creates the archive for the first entry, and then >> >> subsequent entries are added. those get slower and slower. >> > >> > That's what I suspected. I also see this and my suggestion helped >> > archiving speed in my case. >> > >> >> i use (olpath category itags). i will try (file time) when i can, if >> >> that still applies. my brain needs to be more operational. >> > >> > When you use category, every time you modify the original file (not the >> > archive!), Org mode re-calculates *all* the categories in the original >> > Org file. It happens for every single archived heading. If your >> > original >> > Org file is large, re-calculations make things extremely slow. >> > >> > Best, >> > Ihor >> > >> >> >> -- >> The Kafka Pandemic >> >> Please learn what misopathy is. >> >> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html >> >> > > -- > regards, > > Tim > > -- > Tim Cross > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: archiving speed [was Re: Tips on maintaining history in Org Mode]
thank you. i will give up on archiving categories if needed to make archiving be practical. will ahfe to try it as soon as i can. On 8/11/21, Ihor Radchenko wrote: > Samuel Wales writes: > >> thanks for the clarification. are you saying that, for every archived >> entry, it calculates teh category property, using the original org >> file, in order to add a category property to just one archived entry? > > Nope. It does not just calculate category for the archived entry, but > re-calculates all the category properties in the original Org file > (updating category cache). > >> that would certainly slow down more and more, but it sends me back to >> my question about whether append to file would work. >> i.e. build the single entry in a temporary buffer then write that >> region to a file on disk. > > Appending can indeed work if your archive location is at the end of the > file. However, it is not necessary the performance bottleneck. Certainly > not when the archive file is small. > > Best, > Ihor > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: archiving speed [was Re: Tips on maintaining history in Org Mode]
I think the problem with just using append to file is that it won't preserve the shape of the file. For example, if I had a file with * Notes ** Note 1 blah blah ** Note 2 blah blah * Tasks ** DONE task 1 ** TODO Task 2 and I decide to archive note 1 and task 1, I would like them to both appear under the same headings and with the same level. If the process just uses append to file, I can have this for the first archiving i.e. * Noes ** Note 1 * Tasks ** DONE task 1 but then later, I decide to archive note 2, if append file is used, I will end up with * Notes ** Note 1 * Taks ** DONE task 1 * Notes ** Note 2 which is not what I want. I want * Notes ** Note 1 ** Note 2 * Tasks ** DONE Task 1 So, if we want to preserve hierarchies in our archive files and not have everything jumbled up together, the system has to parse the file. If you are also using something like Categories, then even more work needs to be odne to update the category lists. What I tend to do is mark items with the ARCHIVE tag and leave them in the file and then every few months, move archived data to archive files. It can still get slow, but I don't do it often, so it isn't too much of a hassle. On Thu, 12 Aug 2021 at 08:23, Samuel Wales wrote: > thanks for the clarification. are you saying that, for every archived > entry, it calculates teh category property, using the original org > file, in order to add a category property to just one archived entry? > > that would certainly slow down more and more, but it sends me back to > my question about whether append to file would work. > i.e. build the single entry in a temporary buffer then write that > region to a file on disk. > > On 8/10/21, Ihor Radchenko wrote: > > Samuel Wales writes: > > > >> i should clarify. bulk archiving slows down even with /nonexistent/ > >> (have not tried empty) archives. as part of normal and expected > >> operation, bulk creates the archive for the first entry, and then > >> subsequent entries are added. those get slower and slower. > > > > That's what I suspected. I also see this and my suggestion helped > > archiving speed in my case. > > > >> i use (olpath category itags). i will try (file time) when i can, if > >> that still applies. my brain needs to be more operational. > > > > When you use category, every time you modify the original file (not the > > archive!), Org mode re-calculates *all* the categories in the original > > Org file. It happens for every single archived heading. If your original > > Org file is large, re-calculations make things extremely slow. > > > > Best, > > Ihor > > > > > -- > The Kafka Pandemic > > Please learn what misopathy is. > > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > > -- regards, Tim -- Tim Cross
Re: archiving speed [was Re: Tips on maintaining history in Org Mode]
Samuel Wales writes: > thanks for the clarification. are you saying that, for every archived > entry, it calculates teh category property, using the original org > file, in order to add a category property to just one archived entry? Nope. It does not just calculate category for the archived entry, but re-calculates all the category properties in the original Org file (updating category cache). > that would certainly slow down more and more, but it sends me back to > my question about whether append to file would work. > i.e. build the single entry in a temporary buffer then write that > region to a file on disk. Appending can indeed work if your archive location is at the end of the file. However, it is not necessary the performance bottleneck. Certainly not when the archive file is small. Best, Ihor
Re: archiving speed [was Re: Tips on maintaining history in Org Mode]
thanks for the clarification. are you saying that, for every archived entry, it calculates teh category property, using the original org file, in order to add a category property to just one archived entry? that would certainly slow down more and more, but it sends me back to my question about whether append to file would work. i.e. build the single entry in a temporary buffer then write that region to a file on disk. On 8/10/21, Ihor Radchenko wrote: > Samuel Wales writes: > >> i should clarify. bulk archiving slows down even with /nonexistent/ >> (have not tried empty) archives. as part of normal and expected >> operation, bulk creates the archive for the first entry, and then >> subsequent entries are added. those get slower and slower. > > That's what I suspected. I also see this and my suggestion helped > archiving speed in my case. > >> i use (olpath category itags). i will try (file time) when i can, if >> that still applies. my brain needs to be more operational. > > When you use category, every time you modify the original file (not the > archive!), Org mode re-calculates *all* the categories in the original > Org file. It happens for every single archived heading. If your original > Org file is large, re-calculations make things extremely slow. > > Best, > Ihor > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Bug: Small documentation errors [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/jorge/.emacs.d/elpa/27.0/develop/org-plus-contrib-20200406/)]
>From d3c62edf7a713278432ebe1c72e4545b8a2b84e2 Mon Sep 17 00:00:00 2001
From: "Jorge P. de Morais Neto"
Date: Wed, 11 Aug 2021 18:43:21 -0300
Subject: [PATCH] * doc/org-manual.org (Drawers): Clarify M-TAB
Provide example of completion over drawer keywords. Also clarify the
footnote by qualifying "windows" as "graphical".
---
doc/org-manual.org | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index d34d33561..467644453 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -1214,7 +1214,22 @@ Org mode uses this special drawer for storing properties (see
[[*Properties and Columns]]). You cannot use it for anything else.
Completion over drawer keywords is also possible using
-{{{kbd(M-TAB)}}}[fn:16].
+{{{kbd(M-TAB)}}}[fn:16]. For example, if the buffer contains
+
+#+begin_example
+:foo:
+:end:
+
+:f★
+#+end_example
+
+#+texinfo: @noindent
+(where ★ indicates the location of point) then {{{kbd(M-TAB)}}} will
+complete the line as
+
+#+begin_example
+:foo:★
+#+end_example
Visibility cycling (see [[*Visibility Cycling]]) on the headline hides and
shows the entry, but keep the drawer collapsed to a single line. In
@@ -21500,8 +21515,8 @@ variable ~org-M-RET-may-split-line~.
[fn:15] See ~org-list-use-circular-motion~ for a cyclic behavior.
-[fn:16] Many desktops intercept {{{kbd(M-TAB)}}} to switch windows.
-Use {{{kbd(C-M-i)}}} or {{{kbd(ESC TAB)}}} instead.
+[fn:16] Many desktops intercept {{{kbd(M-TAB)}}} to switch graphical
+windows. Use {{{kbd(C-M-i)}}} or {{{kbd(ESC TAB)}}} instead.
[fn:17] To insert a vertical bar into a table field, use =\vert= or,
inside a word =abc\vert{}def=.
--
2.32.0
Hello,
Em [2021-08-11 qua 22:50:36+0200], Nicolas Goaziou escreveu:
>> Sorry for insisting, but can someone give me an example of what the
>> manual means by "Completion over drawer keywords"?
>
> :foo:
> :end:
>
> :f|
>
> With point at |, M-TAB will complete the line as
>
> :foo:
Then how about the attached patch? Note that I used a black star to
indicate the position of point---the convention in the Elisp manual.
Also, I provided a ~+#+texinfo: @noindent~ directive so the continuation
would not be indented, because it is not a new paragraph. Please tell
whether that made sense---I know little about Texinfo and typography.
Also tell whether I am making good use of time---mine and yours. I have
OCD and I often nitpick about details of little relevance; feedback
about that is always welcome.
Regards
--
- Disinformation flourishes because many people care about injustice
but very few check the facts. Ask me about
- I am Brazilian. I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.
Re: org-attach-sync uses directory-empty-p (new in Emacs 28)
Maxim Nikulin writes: > On 11/08/2021 03:52, Marco Wahl wrote: >>> Kyle Meyer writes: >>> In 61e083732 (org-attach: Possibly delete empty attach directory, 2021-07-09), you added a call to directory-empty-p. This function was introduced in Emacs's 0806075520 (Add directory-empty-p and new argument COUNT for directory-files-*, 2020-11-02) and hasn't yet made it into a release. Could you update org-attach-sync to avoid using directory-empty-p (e.g., by inlining it or by adding a compatibility alias)? >> Starting from Arthur's suggestion and Kyle's hint to the >> compatibility >> alias I put org-directory-empty-p into org-compat.el. So there is >> org-directory-empty-p now which provides the functionality of >> directory-empty-p from Emacs 28 for smaller version Emacsen. > > Unfortunately current code causes a compiler warning at least when > Emacs-25.2 is used: > > Compiling single /home/ubuntu/org-mode/lisp/org-compat.el... > > In end of data: > org-compat.el:1255:1:Warning: the function ‘directory-empty-p’ is not > known to > be defined. Thanks. How make the compiler happy? What about adding a declare-function for directory-empty-p? Suggestion for org-compat.el: #+begin_src emacs-lisp ;;; Emacs < 28.1 compatibility (if (version< emacs-version "28") (defun org-directory-empty-p (dir) "Return t if DIR names an existing directory containing no other files." (and (file-directory-p dir) (null (directory-files dir nil directory-files-no-dot-files-regexp t (declare-function directory-empty-p "files" (dir)) ; <-- NEW LINE TO MAKE THE COMPILER HAPPY. (defalias 'org-directory-empty-p #'directory-empty-p)) #+end_src Could you please check the compile with this modification? Best regards, -- Marco
Re: Bug: Small documentation errors [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/jorge/.emacs.d/elpa/27.0/develop/org-plus-contrib-20200406/)]
Hello, Jorge P. de Morais Neto writes: > I prepared the patch above to improve the organization of the respective > manual section. Applied. Thank you. >> ** [[info:org#Drawers]] >> >> I don't understand the sentence >> >>Completion over drawer keywords is also possible using ‘M-’ >> >> Could give me a simple example of drawer keyword completion? > > Sorry for insisting, but can someone give me an example of what the > manual means by "Completion over drawer keywords"? :foo: :end: :f| With point at |, M-TAB will complete the line as :foo: > And in this kind of situation, did I do well by attaching the patch to a > normal reply in the thread, or should I have started a new thread with > an appropriate subject line? If so, then please give me details so I do > it correctly next time. I think what you did is correct. But the other option would not be the end of the world either. Regards, -- Nicolas Goaziou
Re: [PATCH] ox: Italian smart quotes
Hello, Davide Peressoni via "General discussions about Org-mode." writes: > From 97a45353d19be98bcf0d94da0d902a025408fa3a Mon Sep 17 00:00:00 2001 > From: DPDmancul > Date: Wed, 11 Aug 2021 18:21:55 +0200 > Subject: [PATCH] ox: Italian smart quotes > > * ox.el (org-export-smart-quotes-alist): Added support for italian > smart quotes. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: Bug: Small documentation errors [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/jorge/.emacs.d/elpa/27.0/develop/org-plus-contrib-20200406/)]
>From 474192b67077b3a7bfaa8e9ff152b1a9ac7524f3 Mon Sep 17 00:00:00 2001
From: "Jorge P. de Morais Neto"
Date: Wed, 11 Aug 2021 17:13:06 -0300
Subject: [PATCH] * doc/org-manual.org (Tracking TODO state changes): move
sentence
The sentence was misplaced, interrupting the train of thought. I also
did not understand the need for disabling paragraph indentation, so I
removed the directive.
---
doc/org-manual.org | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 977ef80b9..d34d33561 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -4205,10 +4205,6 @@ example, with the setting
'((sequence "TODO(t)" "WAIT(w@/!)" "|" "DONE(d!)" "CANCELED(c@)")))
#+end_src
-#+texinfo: @noindent
-To record a timestamp without a note for TODO keywords configured with
-=@=, just type {{{kbd(C-c C-c)}}} to enter a blank note when prompted.
-
#+vindex: org-log-done
You not only define global TODO keywords and fast access keys, but
also request that a time is recorded when the entry is set to =DONE=,
@@ -4228,6 +4224,9 @@ to a buffer:
: #+TODO: TODO(t) WAIT(w@/!) | DONE(d!) CANCELED(c@)
+To record a timestamp without a note for TODO keywords configured with
+=@=, just type {{{kbd(C-c C-c)}}} to enter a blank note when prompted.
+
#+cindex: @samp{LOGGING}, property
In order to define logging settings that are local to a subtree or
a single item, define a =LOGGING= property in this entry. Any
--
2.32.0
Hi. I continue below:
Em [2020-04-12 dom 10:45:44-0300], Jorge P. de Morais Neto escreveu:
> ** [info:org#Tracking TODO state changes]
>
> The following sentence is misplaced, interrupting the previous train of
> thought:
>
> To record a timestamp without a note for TODO keywords configured
> with `@', just type `C-c C-c' to enter a blank note when prompted.
I prepared the patch above to improve the organization of the respective
manual section.
> ** [[info:org#Drawers]]
>
> I don't understand the sentence
>
>Completion over drawer keywords is also possible using ‘M-’
>
> Could give me a simple example of drawer keyword completion?
Sorry for insisting, but can someone give me an example of what the
manual means by "Completion over drawer keywords"?
And in this kind of situation, did I do well by attaching the patch to a
normal reply in the thread, or should I have started a new thread with
an appropriate subject line? If so, then please give me details so I do
it correctly next time.
Regards
--
- Disinformation flourishes because many people care about injustice
but very few check the facts. Ask me about
- I am Brazilian. I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org
[PATCH] org-tools/index.org: Add go-org to list of Org-mode parsers (Worg)
This adds the Org mode parser written in Go to the list of Org-mode parsers. I'm sending a patch for Worg for the first time, I hope this is the correct way to do so. -- Regards, Bhavin Gandhi (bhavin192) | https://geeksocket.in From 12b0f792ff75c7ea2e4dfe24dc54921e4caa24b0 Mon Sep 17 00:00:00 2001 From: Bhavin Gandhi Date: Wed, 11 Aug 2021 23:53:25 +0530 Subject: [PATCH] org-tools/index.org: Add go-org to list of Org-mode parsers --- org-tools/index.org | 1 + 1 file changed, 1 insertion(+) diff --git a/org-tools/index.org b/org-tools/index.org index fbbdd8c8..87e7e665 100644 --- a/org-tools/index.org +++ b/org-tools/index.org @@ -40,6 +40,7 @@ This page lists external tools useful for handling Org files. | [[https://github.com/ixmatus/orgmode-parse][orgmode-parse]] | ? | | | | [[https://hackage.haskell.org/package/org-mode][org-mode]]| Haskell | | | | [[https://github.com/PoiScript/orgize][orgize]] | Rust| | | +| [[https://github.com/niklasfasching/go-org][go-org]] | Go | Niklas Fasching | | * Org-mode exporters -- 2.31.1
[PATCH] ox: Italian smart quotes
>From 97a45353d19be98bcf0d94da0d902a025408fa3a Mon Sep 17 00:00:00 2001
From: DPDmancul
Date: Wed, 11 Aug 2021 18:21:55 +0200
Subject: [PATCH] ox: Italian smart quotes
* ox.el (org-export-smart-quotes-alist): Added support for italian smart quotes.
---
lisp/ox.el | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lisp/ox.el b/lisp/ox.el
index eb12b68d7..5fe894569 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5476,6 +5476,12 @@ transcoding it."
(secondary-closing
:utf-8 "‘" :html "‘" :latex "\\grq{}" :texinfo "@quoteleft{}")
(apostrophe :utf-8 "’" :html "’"))
+ ("it"
+ (primary-opening :utf-8 "“" :html "“" :latex "``" :texinfo "``")
+ (primary-closing :utf-8 "”" :html "”" :latex "''" :texinfo "''")
+ (secondary-opening :utf-8 "‘" :html "‘" :latex "`" :texinfo "`")
+ (secondary-closing :utf-8 "’" :html "’" :latex "'" :texinfo "'")
+ (apostrophe :utf-8 "’" :html "’"))
("no"
;; https://nn.wikipedia.org/wiki/Sitatteikn
(primary-opening
--
2.32.0
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
"Bruce D'Arcus" writes: > Here's a recent subthread on this question: > > https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00233.html > > At the end of that discussion, my argument against using citations for > cross-references: > > 1. Cross-references are not citations, neither conceptually, nor in > software implementations. In LaTeX, MS Word, Libre office, InDesign, > etc, cross-references are handled differently than citations. There, > they are typed internal links. You can get a sense of how this works > in this tutorial for Word, which includes a list of cross-reference > types, and so hints at the range of things people need to internally > reference: > > https://www.customguide.com/word/how-to-cross-reference-in-word > > 2. As John and Joost noted on that thread, because they're different, > they raise a range of implementation questions, most notably for me > what org-cite processors are supposed to do with these citations that > are not citations. As it is now, the user would just get errors and/or > unexpected output. This is also the case with org-ref links, if you haven't installed or loaded org-ref. > > On Wed, Aug 11, 2021 at 1:28 AM Tom Gillespie wrote: > > ... > >> Actually, having written this now, I think that both solutions have >> their own use cases. Org cite is clearly about providing evidence for, >> or a scholarly reference for something, and critically it can embed >> some metadata about that reference in the document as a citation or >> perhaps as an excerpt (and extension of what org-ref does now when the >> cursor is over a reference?). Regular links do not provide any way to >> embed metadata within the document, they are purely pointers. > > Right, which is what a cross-reference is. > > It's just there needs to be some way to distinguish among types of > targets, I think. At the risk of repeating myself, I don't think this is true. There needs to be a way to distinguish among styles of cross-references, just like there is for citations, and for the same reason: different contexts require different styles. In citations, you might want to see the year, author, number, or some combination of those, and there are different styles for those that all use the same key. In cross-references, you might want to see a figure/table number, and these may be styled differently than an equation. You might also want the page number a label is on, or the name of a section. In MS Word, it is even possible to use the caption of a figure or table. These are just different styles to use on a label. As I have thought about this more, the line between citations and cross-references has blurred. In org-ref, they were handled the same way, with org-links (although each link had its own export function). For both cites and refs, the links are just pointers, and in both cases it is possible for them to point to things within the same document. Even in LaTeX, when we submit a manuscript, the citation references are embedded in a standalone tex file, so every link is to an internal location. The line blurs even further if you use something like org-bibtex, with entries in the same document. Then, you can make a cross-reference to a heading, or a citation reference to a reference entry. > >> I think it would be a mistake to use up equation/eq and table/tbl or >> figure/fig prefixes for references that are internal to org, because it >> implicitly >> limits/collides with the #+link: keyword. > > Is there a workaround for this somehow, or an alternative that gets > the same thing in the end? > > Bruce -- 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
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
That'd be my preferred solution, with (notwithstanding name overlap with org-ref) an org-ref-insert entry point. On Wed, Aug 11, 2021, 12:10 PM Timothy wrote: > Hi Bruce, John, > > Regarding the issues with overloading [cite:@] syntax, would it be too > much to > introduce [ref:@] which would function identically, but deal with > references? > > All the best, > *Timothy* >
Re: citations: rx problems with emacs-26.3
On 11/08/2021 16:33, Nicolas Goaziou wrote: Maxim Nikulin writes: There are a couple of issues with "make single" for emacs-25.2: All fixed. Thank you. Thank you, Nicolas. It seems org-cite can be cleanly loaded or compiled by Emacs-25 and Emacs-26 now.
Re: org-attach-sync uses directory-empty-p (new in Emacs 28)
On 11/08/2021 03:52, Marco Wahl wrote: Kyle Meyer writes: In 61e083732 (org-attach: Possibly delete empty attach directory, 2021-07-09), you added a call to directory-empty-p. This function was introduced in Emacs's 0806075520 (Add directory-empty-p and new argument COUNT for directory-files-*, 2020-11-02) and hasn't yet made it into a release. Could you update org-attach-sync to avoid using directory-empty-p (e.g., by inlining it or by adding a compatibility alias)? Starting from Arthur's suggestion and Kyle's hint to the compatibility alias I put org-directory-empty-p into org-compat.el. So there is org-directory-empty-p now which provides the functionality of directory-empty-p from Emacs 28 for smaller version Emacsen. Unfortunately current code causes a compiler warning at least when Emacs-25.2 is used: Compiling single /home/ubuntu/org-mode/lisp/org-compat.el... In end of data: org-compat.el:1255:1:Warning: the function ‘directory-empty-p’ is not known to be defined.
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
Hi Bruce, John, Regarding the issues with overloading [cite:@] syntax, would it be too much to introduce [ref:@] which would function identically, but deal with references? All the best, *Timothy*
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
On Wed, Aug 11, 2021 at 10:56 AM John Kitchin wrote: > This is a bad idea to me. It is only a fuzzy link (what you call a typed > internal link) if no one has defined it as an external link. As soon as that > happens, then you will lose the export behavior defined for fuzzy links, and > get the behavior defined by the export function. The syntax for these is the > same (I guess a fuzzy link must be wrapped in [[ ]], but an external link may > also be wrapped that way). I don't see a way to differentiate these. I guess this is a key question then; sounds like maybe internal links are too loosely defined? BTW, I was using the language from the org-mode manual to avoid confusion. https://orgmode.org/manual/Internal-Links.html >> 2. extend citations, per your idea here, which to me means the >> org-cite code would need to be revised and expanded to handle both >> cross-references and citations, but do so distinctly. > > I don't think so. You only have to extend them where you want to have the > capability. org-cite can stay a citation only body of code, and if you want > cross-references too you just use my processors, or write one that does what > you want. Except now, org-cite and all the extant processors assume a citation-reference key corresponds to a bibliographic (mostly either bibtex or csl json) entry, which identifies an external source. Surely that has implications for compatibility if adding cross-referencing, unless existing code is changed to account for that? With your suggestion, for example, I presume org-cite-insert would be used to insert and edit cross-references, rather than org-insert-link or org-insert-cross-reference? Aside from whether that makes sense from a UX perspective, those references wouldn't be found unless a UI explicitly accounted for them. And an activate processor that wasn't updated would treat them as bad citations. Maybe the changes would be small; IDK. Hopefully Nicolas can weigh in on this. > You don't have to. Your processors should fail gracefully in any case, > because you just cannot control what people will do with the styles. The issue for me is less what you are proposing to do with styles (which in my case I construct from org-cite-supported styles), than with citation-reference. Per above, a citation-reference is just not a cross-reference. IDK; perhaps if this path makes sense in the end, it might be cleaner to add a citation-cross-reference element, or maybe even better to just have a parallel cross-reference object that borrows some of the design of org-cite? > The biggest issue with 1 is I don't think it is possible to differentiate > internal typed links from external links because they use the same syntax. It > would be very difficult to support and troubleshoot a scenario where the same > syntax shows different behavior depending on whether an external link is > defined or not. Finally, it is so close to what org-ref already does, I think > it is too tricky to differentiate [[ref:label]] from [[ref/:label]], etc. > > Maybe these links would look different enough (as external links) that it > would be really clear you were not using org-ref. > > ref/:@label > ref/eq:@label > ref/page:@label > ref/name:@label > ref/c:@label > ref/C:@label > > However, this doesn't support using prefix/suffix text, which is one of the > main reasons the cite syntax came to be. OK. That would be another requirement that tips the balance to citation, or something very similar. Bruce
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
On Wed, Aug 11, 2021 at 10:32 AM Bruce D'Arcus wrote: > On Wed, Aug 11, 2021 at 9:53 AM John Kitchin > wrote: > > > > #+CAPTION: This is the caption for the next figure link (or table) > > > #+NAME: fig:SED-HR4049 > > > > > > [[./img/a.jpg]] > > > > > > Or some other metadata on the target? > > > > I don't think metadata on the target helps with the cases described > > above, you can reference a label in different ways at different times to > > get different meanings. > > OK, this clarifies a key piece then. > > I agree then: target metadata alone isn't enough. > > So I see two options: > > 1. per my original response, allow optional typed internal links; e.g.: > > [[fig/foo:file]] > This is a bad idea to me. It is only a fuzzy link (what you call a typed internal link) if no one has defined it as an external link. As soon as that happens, then you will lose the export behavior defined for fuzzy links, and get the behavior defined by the export function. The syntax for these is the same (I guess a fuzzy link must be wrapped in [[ ]], but an external link may also be wrapped that way). I don't see a way to differentiate these. > > To be clear, with this idea, I'm suggesting an alignment between > external links (which already have similar types) and internal (which > do not). > > IUC, org-ref is using *external* link types (not internal links) to > make these distinctions? > Yes, org-ref uses external links, defined by org-set-link-parameters. > > 2. extend citations, per your idea here, which to me means the > org-cite code would need to be revised and expanded to handle both > cross-references and citations, but do so distinctly. > I don't think so. You only have to extend them where you want to have the capability. org-cite can stay a citation only body of code, and if you want cross-references too you just use my processors, or write one that does what you want. > > E.g. an export processor like oc-csl would need to handle these > cross-references in that code, but pass the citations per se to the > citeproc-el backend, which should not need to worry about > cross-references. > Again, not necessarily, this is handled in the export processor, and it can differentiate which citations are sent to oc-csl and which are handled differently based on the style. > > Likewise, as a front-end developer, I don't want to deal with > cross-references at all, so I should be able to ignore them in my > insert and follow processors, in the same way you would need to be > able to include support for them. > You don't have to. Your processors should fail gracefully in any case, because you just cannot control what people will do with the styles. > > And activate processors would need to be updated to distinguish them > somehow. > Right now this just looks like (when (org-ref-cite-ref-p reference) ...) My activate processor just runs a bunch of functions and those functions can do nothing if needed. > Right? > > It seems to me 1 is the easier path, both practically and > conceptually, unless I'm still missing something (which is certainly > possible). > The biggest issue with 1 is I don't think it is possible to differentiate internal typed links from external links because they use the same syntax. It would be very difficult to support and troubleshoot a scenario where the same syntax shows different behavior depending on whether an external link is defined or not. Finally, it is so close to what org-ref already does, I think it is too tricky to differentiate [[ref:label]] from [[ref/:label]], etc. Maybe these links would look different enough (as external links) that it would be really clear you were not using org-ref. ref/:@label ref/eq:@label ref/page:@label ref/name:@label ref/c:@label ref/C:@label However, this doesn't support using prefix/suffix text, which is one of the main reasons the cite syntax came to be. > Bruce >
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
On Wed, Aug 11, 2021 at 9:53 AM John Kitchin wrote: > > #+CAPTION: This is the caption for the next figure link (or table) > > #+NAME: fig:SED-HR4049 > > > > [[./img/a.jpg]] > > > > Or some other metadata on the target? > > I don't think metadata on the target helps with the cases described > above, you can reference a label in different ways at different times to > get different meanings. OK, this clarifies a key piece then. I agree then: target metadata alone isn't enough. So I see two options: 1. per my original response, allow optional typed internal links; e.g.: [[fig/foo:file]] To be clear, with this idea, I'm suggesting an alignment between external links (which already have similar types) and internal (which do not). IUC, org-ref is using *external* link types (not internal links) to make these distinctions? 2. extend citations, per your idea here, which to me means the org-cite code would need to be revised and expanded to handle both cross-references and citations, but do so distinctly. E.g. an export processor like oc-csl would need to handle these cross-references in that code, but pass the citations per se to the citeproc-el backend, which should not need to worry about cross-references. Likewise, as a front-end developer, I don't want to deal with cross-references at all, so I should be able to ignore them in my insert and follow processors, in the same way you would need to be able to include support for them. And activate processors would need to be updated to distinguish them somehow. Right? It seems to me 1 is the easier path, both practically and conceptually, unless I'm still missing something (which is certainly possible). Bruce
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
"Bruce D'Arcus" writes:
> On Wed, Aug 11, 2021 at 7:13 AM Bruce D'Arcus wrote:
>
>> Is there a workaround for this somehow, or an alternative that gets
>> the same thing in the end?
>
> Like, if not typing the link, type the target?
>
> From this example from org-mode manual, the "fig" in the name keyword
> could provide that type?
The "fig" part is only useful imo, for prefix text, eg. If I write "see
\cref{fig:SED-HR4049}" in text, it will get exported in LaTeX as
something like "see Figure 1", where the cleveref package inferred that
the Figure prefix should go in front of the number.
Otherwise, "see \ref{fig:SED-HR4049}" would just export to "see 1",
which is not what you want to see. You can manually add prefix text of
course, like "see Figure \ref{fig:SED-HR4049}".
However, if I am in a long document (like a book), I may want to refer
to a page number, e.g. "See pg. \pageref{fig:SED-HR4049}" to indicate to
the reader where to find some information. In this case the fig prefix
of the label is not important.
With sections, you may want \ref{sec-intro} to get the number of the
section, or \nameref{sec-intro} to get the name of the section. Both
cases use the same label.
>
> #+CAPTION: This is the caption for the next figure link (or table)
> #+NAME: fig:SED-HR4049
>
> [[./img/a.jpg]]
>
> Or some other metadata on the target?
I don't think metadata on the target helps with the cases described
above, you can reference a label in different ways at different times to
get different meanings.
>
> Bruce
>
> https://orgmode.org/manual/Images.html
> https://orgmode.org/manual/Internal-Links.html
--
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
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
"Bruce D'Arcus" writes:
> Hi John,
>
> On Tue, Aug 10, 2021 at 8:58 PM John Kitchin wrote:
>
>> ... I would like what I call an orthogonal approach for cross-references,
>> orthogonal in the sense that it can coexist with org-ref, but not require
>> org-ref if you don't use it. The built in internal links like [[label]] lack
>> the flexibility I need (I think), e.g. to differentiate a typical reference
>> from an equation reference (these map to \ref{label} and \eqref{label} in
>> latex for example), and there are other references that are relevant in latex
>> also like \pageref{label}, \cref{label} etc.
>
> Granting the current "lack of flexibility" of internal links, what
> about extending them to allow an optional type; like:
>
> [[eq:label]]
> [[table:label]]
Those look like regular org links, and are handled differently from [[label]]
which is called a fuzzy link if the links are defined. Interestingly, if
the org-links are not defined, they are still fuzzy links, but that is
going to be super confusing because the syntax is so similar. In any
case, this is substituting using one syntax for another purpose for
another syntax.
No extension is needed for regular links, it is already a feature of
org-links which is used heavily in org-ref already does via ref:label,
eqref:label, etc. But to use them, you would have to install org-ref,
and it would come with helm and ivy, which many people do not like. I
don't want to redefine these links because some people (like me) will
have to have both packages installed for legacy documents, and the link
behavior is what ever is loaded last.
It is not necessary to differentiate figures and tables that way, imo, and you
can use different kinds of references to the same label anyway. E.g.
\ref{tab-1} (in LaTeX) would refer to the table number, whereas
\pageref{tab-1} would refer to the page number it is on. Obviously, that
has less meaning for html where there is a single page.
>
> ... etc?
>
> It could work based on similar logic as citation styles, namely that
> content preceding some delimiter (in the examples above, the hyphen)
> would be an optional link type. As you say, it could even have a
> similar style/variant structure as citations.
>
> Perhaps a handful such link types could be reserved, for obvious org
> link targets (like tables, equations, figures, etc), but it would be
> flexible beyond that.
>
> Would that not work?
I don't think this would work. org-ref already defines most or all of
these links. Maybe we could use new names like ref/:label ref/eq:label,
etc though. They seem to be legal names. It still seems like there is a
lot of opportunity for mixing exports from org-ref and org-ref-cite this
way though, because the syntax is so similar. I want as clear a
separation of these packages as can be had.
>
> Because if it could, that would seem to be a better solution, both for
> cross-references, and for citations.
>
> I do grant there may be a challenge with legacy documents adding such
> an optional type, but perhaps there's a solution to that problem?
>
> Bruce
--
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
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
On Wed, Aug 11, 2021 at 7:13 AM Bruce D'Arcus wrote: > Is there a workaround for this somehow, or an alternative that gets > the same thing in the end? Like, if not typing the link, type the target? >From this example from org-mode manual, the "fig" in the name keyword could provide that type? #+CAPTION: This is the caption for the next figure link (or table) #+NAME: fig:SED-HR4049 [[./img/a.jpg]] Or some other metadata on the target? Bruce https://orgmode.org/manual/Images.html https://orgmode.org/manual/Internal-Links.html
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
Here's a recent subthread on this question: https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00233.html At the end of that discussion, my argument against using citations for cross-references: 1. Cross-references are not citations, neither conceptually, nor in software implementations. In LaTeX, MS Word, Libre office, InDesign, etc, cross-references are handled differently than citations. There, they are typed internal links. You can get a sense of how this works in this tutorial for Word, which includes a list of cross-reference types, and so hints at the range of things people need to internally reference: https://www.customguide.com/word/how-to-cross-reference-in-word 2. As John and Joost noted on that thread, because they're different, they raise a range of implementation questions, most notably for me what org-cite processors are supposed to do with these citations that are not citations. As it is now, the user would just get errors and/or unexpected output. On Wed, Aug 11, 2021 at 1:28 AM Tom Gillespie wrote: ... > Actually, having written this now, I think that both solutions have > their own use cases. Org cite is clearly about providing evidence for, > or a scholarly reference for something, and critically it can embed > some metadata about that reference in the document as a citation or > perhaps as an excerpt (and extension of what org-ref does now when the > cursor is over a reference?). Regular links do not provide any way to > embed metadata within the document, they are purely pointers. Right, which is what a cross-reference is. It's just there needs to be some way to distinguish among types of targets, I think. > I think it would be a mistake to use up equation/eq and table/tbl or > figure/fig prefixes for references that are internal to org, because it > implicitly > limits/collides with the #+link: keyword. Is there a workaround for this somehow, or an alternative that gets the same thing in the end? Bruce
Re: org-indent-indentation-per-level may be broken
Correction, the following is not the case: > because when I set [org-indent-indentation-per-level] to e.g. 5, I > would expect the amount of indentation when I run org-indent-mode to > increase appropriately, but it doesn't, it's the same as with the > default value of 2. I got confused when testing the different variations, I was expecting the indentation change to happen in the wrong place. Sorry for that! So to be clear: setting org-indent-indentation-per-level to 0 is broken and leads to the aforementioned error. Setting it to a value >0 behaves correctly, as in, the indentation of the heading levels changes accordingly. Cheers, David
Re: [org-mode] make citation object available to org-cite-make-insert-processor SELECT-STYLE?
Hello, "Bruce D'Arcus" writes: > So the idea is to present a preview of the style/variant output when > selecting the style. > > Like: > > / (Doe, 2019) > > ... or maybe even multiple columns: > > / (Doe, 2019) \citep > > I'm thinking the best way to build this UI is to iterate through > org-cite-support-styles, and run at least the default export processes > to create that preview annotation, > > As my thinking has evolved (and there's been a lot of discussion on > this the past week), I see two options: > > 1. Generate the previews from the citations at point. This was the > idea that promoted the suggestion here, since I can't get access to > that citation data if I use org-cite-make-insert-processor. > > 2. Instead, have a standardized example record just for the preview. > With this approach, the citation context isn't relevant. > > As to your question, do any style UIs currently allow you to select a > style on a new citation before selecting the keys? I added a citation argument to select-style. Let me know if it works for you. Regards, -- Nicolas Goaziou
Re: Library of Babel usage of other programming languages than elisp
Hello Arne!
Thanks for that.
Do you happen to have an example, in which you are passing arguments to a
procedure?
Regards,
Zelphir
On 8/10/21 7:49 AM, Dr. Arne Babenhauserheide wrote:
> Zelphir Kaltstahl writes:
>
>> I have repeatedly tried to use another programming language than elisp for
>> writing source blocks in org-mode, which I intended to use as functions
>> inside
>> org-mode spreadsheets. So far without success.
> I’m using scheme in org-mode during export (though not it tables) and
> that works.
>
> call:
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=ccc9148e78a4#L27
>
> begin_src:
> https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=ccc9148e78a4#L137
>
> #+call: generate-char-jetzt()
>
> #+name: generate-char-jetzt
> #+begin_src scheme :exports none :results output raw :prologue "(import (srfi
> srfi-1)(ice-9 match)(ice-9 receive))(set! *random-state*
> (random-state-from-platform))\n" :tangle chargen.scm :noweb yes :var
> kernantriebe=tabelle-grundantriebe :var hautfarbe=tabelle-hautfarbe :var
> haarfarbe=tabelle-haarfarbe :var augenfarbe=tabelle-augenfarbe :var
> darstellung1=tabelle-darstellung1 :var darstellung2=tabelle-darstellung2 :var
> kleidung_oben_maenner=tabelle-kleidung-jetzt-oben-maenner :var
> kleidung_unten_maenner=tabelle-kleidung-jetzt-unten-maenner :var
> kleidung_oben_frauen=tabelle-kleidung-jetzt-oben-frauen :var
> kleidung_unten_frauen=tabelle-kleidung-jetzt-unten-frauen :var
> kleidung_oben_frauen=tabelle-kleidung-jetzt-oben-frauen :var
> kleidung_unten_frauen=tabelle-kleidung-jetzt-unten-frauen :var
> namen=tabelle-namen-fantasy-jetzt :var sex=tabelle-sexualitaet :var
> stichwort=tabelle-stichwort-jetztzeit
> (let ()
> {{{chargen-setup}}}
> {{{chargen-generic}}}
> {{{chargen-colors}}}
> {{{chargen-specifics-jetzt}}}
> {{{chargen-print-char}}}
> (chargen-print-char)
> )
> #+end_src
>
> #+begin_src scheme :noweb-ref chargen-specifics-jetzt
> (define first-names
> (map first
> (map string-split-space
> (map third
> (remove (λ(x)(not (equal? geschlecht (fourth x namen)
> (define last-names (map (λ (x) (string-join (cdr x))) (map
> string-split-space (map third namen
> (define names (apply append (map (λ (fi) (map (λ(la) (string-join (list
> fi la))) last-names)) first-names)))
> ;; (define worte (list->d6alist (second (apply zip zweiworte
>
> #+end_src
>
> Best wishes,
> Arne
--
repositories: https://notabug.org/ZelphirKaltstahl
Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items
Hello, Anders Johansson writes: > org-duration-from-minutes was called with canonical = t, but without > providing a corresponding format only using the canonical units. This > broke if the user’s org-duration-format used other than the canonical > units. I think a proper fix would be to change `org-duration-from-minutes' so it removes any unknown unit from what is provided from fmt or `org-duration-format', and defaults to (special . h:mm) if nothing is left. WDYT? Regards, -- Nicolas Goaziou
Re: citations: rx problems with emacs-26.3
Hello, Maxim Nikulin writes: > Nice. Perhaps `org-cite-biblatex-export-citation' should be fixed in > a similar way. There is no error yet but compiled file is > significantly blown up: > > -rw-rw-r-- 1 ubuntu ubuntu 13383 Aug 9 02:17 lisp/oc-biblatex.el > -rw-rw-r-- 1 ubuntu ubuntu 48906 Aug 9 17:06 lisp/oc-biblatex.elc > > There are a couple of issues with "make single" for emacs-25.2: > > Compiling single /home/ubuntu/org-mode/lisp/oc-basic.el... > > In end of data: > oc-basic.el:772:1:Warning: the function ‘buffer-hash’ is not known to be > defined. > Compiling single /home/ubuntu/org-mode/lisp/oc-biblatex.el... > Compiling single /home/ubuntu/org-mode/lisp/oc-csl.el... > > In toplevel form: > oc-csl.el:90:1:Error: Cannot open load file: No such file or > directory, org-cite > Makefile:59: recipe for target 'oc-csl.elc' failed > make[2]: [oc-csl.elc] Error 1 (ignored) All fixed. Thank you. Regards, -- Nicolas Goaziou
Re: citations: rx problems with emacs-26.3
Hello, Maxim Nikulin writes: > On 08/08/2021 03:27, Nicolas Goaziou wrote: >> Maxim Nikulin writes: >> >>> It seems, rx e.g. in emacs-26.3 does not support all features used in >>> oc.el and oc-csl.el. Loading an org file using git master, I get >>> a warning >>> Eager macro-expansion failure: (error "rx form ‘regexp’ requires args satisfying ‘stringp’") >> Thanks. Could you send the patch again with a proper commit message, >> using git format-patch? > > With the attached patches I do not see warnings any more while org is > loading. On the other hand I am not an org-cite user, Applied. Thank you. > so I am not sure that nothing is broken by these patches. I'll trust the test suite on this. Regards, -- Nicolas Goaziou
org-indent-indentation-per-level may be broken
Hi all, I'd like to use visual-line-mode to soft-wrap lines in Org files, while keeping continuation lines in list items properly indented: - long line that goes on to the edge of the screen and soft wraps like I want it to Instead of this: - long line that goes on to the edge of the screen and soft wraps like I *don't* want it to I figured it should be possible to achieve this with org-indent-mode. However, that mode also adds visual pre-indentation for each heading level, which I'd rather avoid, I'd like the content under the headings to start flush with the left margin. So the overall result should look like this: * Heading - long line that goes on to the edge of the screen and soft wraps like I want it to Not like this: * Heading - long line that goes on to the edge of the screen and soft wraps like I want it to I thought I could achieve this by setting org-indent-indentation-per-level to 0, and historically, people seem to have been able to use it for this purpose [1] (if I understand the comment correctly). [1]: https://www.reddit.com/r/emacs/comments/97naje/what_is_everyones_org_mode_indentation_preferences/e4a6qqt?utm_source=share&utm_medium=web2x&context=3 However, when I set the option to 0 and start org-indent-mode, I currently get the following error: Debugger entered--Lisp error: (wrong-type-argument wholenump -1) make-string(-1 42) org-indent--compute-prefixes() org-indent-mode(toggle) funcall-interactively(org-indent-mode toggle) call-interactively(org-indent-mode record nil) command-execute(org-indent-mode record) execute-extended-command(nil "org-indent-mode" "org-indent-m") funcall-interactively(execute-extended-command nil "org-indent-mode" "org-indent-m") call-interactively(execute-extended-command nil nil) command-execute(execute-extended-command) So it seems like the logic that computes the actual indentation based on org-indent-indentation-per-level is broken? And maybe in more than one way, because when I set it to e.g. 5, I would expect the amount of indentation when I run org-indent-mode to increase appropriately, but it doesn't, it's the same as with the default value of 2. FWIW, I can avoid the error and get the effect that I was originally looking for by applying the following patch: --- a/org-indent.el2021-08-11 09:30:45.0 +0200 +++ b/org-indent.el2021-08-11 10:45:13.0 +0200 @@ -130,8 +130,9 @@ (make-vector org-indent--deepest-level nil)) (dotimes (n org-indent--deepest-level) (let ((indentation (if (<= n 1) 0 + (max 0 (* (1- org-indent-indentation-per-level) -(1- n) +(1- n)) ;; Headlines line prefixes. (let ((heading-prefix (make-string indentation ?*))) (aset org-indent--heading-line-prefixes @@ -146,13 +147,14 @@ (substring heading-prefix 1))) (t (org-add-props heading-prefix nil 'face 'org-indent) ;; Text line prefixes. + (if (> org-indent-indentation-per-level 0) (aset org-indent--text-line-prefixes n (org-add-props (concat (make-string (+ n indentation) ?\s) (and (> n 0) (char-to-string org-indent-boundary-char))) -nil 'face 'org-indent) +nil 'face 'org-indent)) (defsubst org-indent-remove-properties (beg end) "Remove indentations between BEG and END." But that's just a workaround for my particular case, setting org-indent-indentation-per-level to values greater than 2 still has no discernible effect after these changes. Here are the contents of the init.el file I'm testing this with: (setq org-indent-indentation-per-level 0 org-adapt-indentation nil debug-on-error t) (global-visual-line-mode 1) And here's my version info: GNU Emacs 27.2 (build 1, aarch64-apple-darwin20.3.0, Carbon Version 164 AppKit 2022.3) of 2021-06-11 Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpa @ /Users/david/.emacs.d/elpa/org-20210809/) (Please let me know if I should provide some more!) Best, David
