Re: What is `org-html-prefer-user-labels' setting

Sébastien Gendre writes: > In ox-html.el, their is a custom that I can't understand : > `org-html-prefer-user-labels' > > I have read its doc string, but I still don't understand it. > > Can someone explain it ? Thank you very much. Export usually gene

Re: [FR] Org export: expanding links to included files (was: [BUG] Export backend cross-references are broken [9.7.30 (release_9.7.30 @ /home/user/org-mode-git/lisp/)])

Samuel Wales writes: > could the duplicate issue, at least, be fixed by adding the feature of > allowing id links? What do you mean by "duplicate issue"? -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at

Re: [FR] Org export: expanding links to included files (was: [BUG] Export backend cross-references are broken [9.7.30 (release_9.7.30 @ /home/user/org-mode-git/lisp/)])

could the duplicate issue, at least, be fixed by adding the feature of allowing id links? On Sun, Jul 20, 2025 at 5:27 AM Ihor Radchenko wrote: > > Louis Vigneras writes: > > > Following yantar92’s suggestion on the matrix channel, I am reporting > > here what appears to be a bug. > > > > I have

[FR] Org export: expanding links to included files (was: [BUG] Export backend cross-references are broken [9.7.30 (release_9.7.30 @ /home/user/org-mode-git/lisp/)])

Louis Vigneras writes: > Following yantar92’s suggestion on the matrix channel, I am reporting > here what appears to be a bug. > > I have an index.org file with the following: > #+include: chapter-1.org > #+include: chapter-2.org > > In chapter-1.org I have the following: > * Heading > [[file:c

Re: [PATCH] ox-md.el: Respect `:html-prefer-user-labels' for target type

Ihor Radchenko writes: > Thanks for the patch, but I think it only partially solves the problem. > You addressed targets, but not radio-targets and named references. > I think that it will be more appropriate to call `org-html--reference' > directly rather than trying to repeat its logic. Same fo

[BUG] Export backend cross-references are broken [9.7.30 (release_9.7.30 @ /home/user/org-mode-git/lisp/)]

Hi, Following yantar92’s suggestion on the matrix channel, I am reporting here what appears to be a bug. I have an index.org file with the following: ``` #+include: chapter-1.org #+include: chapter-2.org ``` In chapter-1.org I have the following: ``` * Heading [[file:chapter-2.org::*Heading

What is `org-html-prefer-user-labels' setting

Hello, In ox-html.el, their is a custom that I can't understand : `org-html-prefer-user-labels' I have read its doc string, but I still don't understand it. Can someone explain it ? Thank you very much. Best regards --- Gendre Sébastien signature.asc Description: PGP signature

Re: [PATCH] ox-md.el: Respect `:html-prefer-user-labels' for target type

Markus Huber-Liebl writes: > Subject: [PATCH] ox-md.el: Respect `:html-prefer-user-labels' for target type > > * lisp/ox-md.el (org-md-link): Use `raw-path' as reference for > targets to match behaviour of `org-html-target'. > > `org-md-link' always called

[PATCH] ox-md.el: Respect `:html-prefer-user-labels' for target type

>From 341d7237b2b274c6f7d8da379f58ecb3ccb5d215 Mon Sep 17 00:00:00 2001 From: Markus Huber-Liebl Date: Tue, 6 May 2025 23:25:40 +0200 Subject: [PATCH] ox-md.el: Respect `:html-prefer-user-labels' for target type * lisp/ox-md.el (org-md-link): Use `raw-path' as reference for tar

Re: [BUG] ‘org-element-at-point’ warning when opening a link in agenda with a mouse [9.7.11 (9.7.11-6a5d0e @ c:/Users/User/.emacs.d/elpa/org-9.7.11/)]

Cool! Thanks!

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: >> May you try >> https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch? >> Is encryption speed satisfactory then? >> > > This branch improved the speed of org-crypt. It's not merged yet. Is > anything missing? You may start a new thread to discuss the

Re: [BUG] ‘org-element-at-point’ warning when opening a link in agenda with a mouse [9.7.11 (9.7.11-6a5d0e @ c:/Users/User/.emacs.d/elpa/org-9.7.11/)]

Nikolay Kudryavtsev writes: > Recently I reworked some of my task workflows and now I have an agenda > view that's all web links. Opening those with mouse is pretty natural. > > But every time I do, I get this warning: > > Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org

Re: [BUG] Unable to insert inline or anonymous footnotes unless indented [9.7.11 (9.7.11-6a5d0e @ /home/user/.emacs.d/elpa/org-9.7.11/)]

Suhail Singh writes: > Additionally, and seemingly related, fontlocking for unindented > anonymous and inlined footnotes is also broken. This can be observed > via emacs -q and opening a file with the following contents: > > #+begin_example > ** 9.7.11, 9.6.15 > [fn::This footnote has not fontlo

Re: [BUG] Unable to insert inline or anonymous footnotes unless indented [9.7.11 (9.7.11-6a5d0e @ /home/user/.emacs.d/elpa/org-9.7.11/)]

line (unlike a footnote reference). > Given that, the expectation with the above settings is for > org-footnote-new to insert an inlined footnote at point (which is at the > beginning of a line). > > However, what's observed is a user-error "Cannot insert a footnote > her

Re: [BUG][PATCH] org-babel: Shared list structure causes spurious changes in user options [9.8-pre (release_9.7.10-127-g07dd3b @ /usr/local/share/emacs/site-lisp/org/)]

Nick Dokos writes: > Subject: [PATCH] org-babel: Avoid changing user options by not sharing list > structure > > * lisp/ob-core.el (org-babel-get-src-block-info): Use `copy-tree' > when using `org-babel-default-header-args*' variables to prepare the > `info

[BUG] ‘org-element-at-point’ warning when opening a link in agenda with a mouse [9.7.11 (9.7.11-6a5d0e @ c:/Users/User/.emacs.d/elpa/org-9.7.11/)]

also checks for org-agenda-mode, but that I decided to leave to the maintainers, because maybe there are some things that escaped my understanding. Thanks. Emacs  : GNU Emacs 29.4 (build 1, x86_64-w64-mingw32)  of 2024-07-06 Package: Org mode version 9.7.11 (9.7.11-6a5d0e @ c:/Users/User/.em

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

> > 3931 76% - org-encrypt-entries > > 3931 76% - org-scan-tags > > May you try > https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch? > Is encryption speed satisfactory then? > This branch improved the speed of org-crypt. It's not merged yet. Is

Re: [BUG] Unable to insert inline or anonymous footnotes unless indented [9.7.11 (9.7.11-6a5d0e @ /home/user/.emacs.d/elpa/org-9.7.11/)]

Suhail Singh writes: > Additionally, and seemingly related, fontlocking for unindented > anonymous and inlined footnotes is also broken. This can be observed > via emacs -q and opening a file with the following contents: Correction: opening a file that _contains the contents of the following ex

[BUG] Unable to insert inline or anonymous footnotes unless indented [9.7.11 (9.7.11-6a5d0e @ /home/user/.emacs.d/elpa/org-9.7.11/)]

ike a footnote reference). Given that, the expectation with the above settings is for org-footnote-new to insert an inlined footnote at point (which is at the beginning of a line). However, what's observed is a user-error "Cannot insert a footnote here" when point is at the

[BUG][PATCH] org-babel: Shared list structure causes spurious changes in user options [9.8-pre (release_9.7.10-127-g07dd3b @ /usr/local/share/emacs/site-lisp/org/)]

list. This is a simplified reproducer of the problem, as discovered by user @lyndhurst on SE Emacs. See https://emacs.stackexchange.com/questions/82261/set-org-babel-source-block-parameters-dynamically for more details. Starting with `emacs -Q', open the foll

Re: [BUG] Org element cache error in indirect buffer [9.6.15 (release_9.6.15 @ c:/Users/User/Downloads/emacs-master-x86_64-full/share/emacs/30.0.50/lisp/org/)]

Ihor Radchenko writes: >> I am also experiencing, in indirect buffers, the inability to unfold >> org-headings, and problems where rearranging them leaves sub-headings >> behind, which may be related > > Please upgrade to Org 9.7 and let us know if you stop seeing problems > with indirect buffers

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: >> There is no such thing as "inline block" in Org syntax. > > I meant "inline task", sorry. I remembered "display: inline-block" from CSS… > I don't think we need support for encrypted #+BEGIN_…/#+END… blocks. I did not mean this. >> > ** this is an

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

> There is no such thing as "inline block" in Org syntax. I meant "inline task", sorry. I remembered "display: inline-block" from CSS… I don't think we need support for encrypted #+BEGIN_…/#+END… blocks. Fixing the org-crypt + inline task bugs seems low priority since it's an uncommon case and th

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: > I found minor but unrelated issues, e.g. if you have an empty section like > this: > > * abc2:crypt: > * def > > … if you rename the abc2 header, e.g. to abc, it will ask the > encryption passwo

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

The 3 small problems mentioned above are fixed, thanks. Encryption is faster, and safer now. The part about communicating the encryption status (communicating „this is actually encrypted on disk even when you're seeing it unencrypted“) can be improved later if others find the current behaviour conf

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: > But org-crypt still feels strange. For instance, I decrypt a header, > add a space somewhere else and save. It's saved, but the header is > still visibly unencrypted in Emacs; that's unexpected, because > org-crypt-use-before-save-magic promised to „automatically encrypt

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

In that branch, I don't see the previously mentioned bugs; thanks. But org-crypt still feels strange. For instance, I decrypt a header, add a space somewhere else and save. It's saved, but the header is still visibly unencrypted in Emacs; that's unexpected, because org-crypt-use-before-save-magic

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: > I see it's trying to decrypt things (therefore it asks for the > password). It shouldn't, since I didn't modify any encrypted section. > I said „it asked me for an encryption password“ because the GPG prompt > confusingly uses the word „encryption“ („Passphrase for symme

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

> > With that code I see something strange: I opened a file which had > > encrypted :crypt: sections (never unencrypted), and after adding a > > space somewhere else and saving, it asked me for an encryption > > password. It shouldn't, since all sections are encrypted. > > I also see „org-crypt: Re

Re: [BUG] Org element cache error in indirect buffer [9.6.15 (release_9.6.15 @ c:/Users/User/Downloads/emacs-master-x86_64-full/share/emacs/30.0.50/lisp/org/)]

Matthew Clarke writes: > When using an indirect buffer I get the warning > ... > Warning (org-element-cache): org-element--cache: Org parser error in > PIBBSS.org<2>::488418. Resetting. > ... > I am also experiencing, in indirect buffers, the inability to unfold > org-headings, and problems where

[BUG] Org element cache error in indirect buffer [9.6.15 (release_9.6.15 @ c:/Users/User/Downloads/emacs-master-x86_64-full/share/emacs/30.0.50/lisp/org/)]

adings, and problems where rearranging them leaves sub-headings behind, which may be related Best wishes, Matthew Clarke Emacs : GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) Package: Org mode version 9.6.15 (release_9.6.15 @ c:/Users/User/Downloads/emacs-master-x86_64-full/share/emacs/30.0.50

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: >> May you try >> https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch? >> Is encryption speed satisfactory then? > > With that code I see something strange: I opened a file which had > encrypted :crypt: sections (never unencrypted), and after adding

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

> May you try > https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch? > Is encryption speed satisfactory then? With that code I see something strange: I opened a file which had encrypted :crypt: sections (never unencrypted), and after adding a space somewhere else and saving,

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: >> Does it also happen when you use the latest Org mode version? >> > > Yes, with today's build. It happens with an 11 Mb Org file which has > 19721 headers (some of them reach level 13). > Here I enabled the profiler, added a space, saved (1 time only), and > reported CPU

Re: org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

> > For instance, I don't use it because it adds around 5 seconds to each > > saving of a large file. If it were instantaneous I would enable it. > > With it disabled, this explains why I often find unencrypted sections > > at the end of the day… I have to rely on myself to reencrypt them > > again

Re: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options)

> > In addition, „leaving some encrypted sections unencrypted for a short > > amount of time, and closing and reopening the buffer during that time“ > > isn't a bug, it's a possible user behaviour that we can't control. But > > org-crypt can mention that that

Re: Please document the caching and its user options

Rudolf Adamkovič writes: > Ihor Radchenko writes: > >> Fixed, on bugfix. >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ffb2675f > > FYI: A typo, 's/has/hash/'. > > (Optionally, also 's/anyway //'.) Thanks! Fixed https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?

Re: Please document the caching and its user options

Ihor Radchenko writes: > Fixed, on bugfix. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ffb2675f FYI: A typo, 's/has/hash/'. (Optionally, also 's/anyway //'.) Rudy -- "The whole science is nothing more than a refinement of everyday thinking." --- Albert Einstein, 1879-1

Re: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options)

#x27;before-save-hook)) If we use `write-contents-functions' instead of `before-save-hook', there should be no such problem. > Or just a message in the style of „Encryption failed. Saving the file > may store unencrypted data in disk, and in backups and cache if > enabled“. >

Re: Please document the caching and its user options

> From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Date: Thu, 27 Jun 2024 10:11:46 + > > Eli Zaretskii writes: > > > . set your locale's codeset to something other than UTF-8 > > . type into *scratch*: > > > > (insert "* heading\n(") > > (org-mode) > > (hs-minor-mode) > > (hs-hide-all

org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options))

Daniel Clemente writes: > For instance, I don't use it because it adds around 5 seconds to each > saving of a large file. If it were instantaneous I would enable it. > With it disabled, this explains why I often find unencrypted sections > at the end of the day… I have to rely on myself to reencr

Re: Please document the caching and its user options

Eli Zaretskii writes: > . set your locale's codeset to something other than UTF-8 > . type into *scratch*: > > (insert "* heading\n(") > (org-mode) > (hs-minor-mode) > (hs-hide-all) > > . mark the region around these 4 sexps and type "M-x eval-region" > . observe the popup *Warning* windo

Re: Please document the caching and its user options

Here's one example where org-persistent (I think) triggers an annoying select-safe-coding-system popup because it is trying to cache something behind user's back: . set your locale's codeset to something other than UTF-8 . type into *scratch*: (insert "* heading\n(") (org-mode) (hs-minor-mode

Re: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options)

> > As for not typing the same password twice and not using > org-crypt-use-before-save-magic, we should somehow fix this. > (I am starting a new thread branch.) > „Not using org-crypt-use-before-save-magic“ is currently a user decision, not a bug. For instance, I don't us

org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options)

Daniel Clemente writes: > Sometimes org-crypt fails to reencrypt the data. E.g. if Emacs > crashes, or if you fail to type the same password twice, or of course > if you don't use (org-crypt-use-before-save-magic), etc. I do not think that there is anything left on disk if Emacs crashes. As for

Re: Please document the caching and its user options

> > A user has somefile.org which contains some headers marked with the > > "crypt" tag. Only those headers are encrypted. The org-element cache > > may now cache the whole file, including the encrypted headers (this is > > ok). Now the user temporarily decry

Re: Please document the caching and its user options

irst mentioned org-crypt because users of org-crypt may be > surprised if they see encrypted data stored unencrypted in disk, due > to this cache. No unencrypted data should be stored in the cache _on fs_. If it does get stored, it is a bug that should be reported. > A user has somefile.org

Re: Please document the caching and its user options

include sensitive data, unless the data is encrypted via `org-crypt'.") I first mentioned org-crypt because users of org-crypt may be surprised if they see encrypted data stored unencrypted in disk, due to this cache. A user has somefile.org which contains some headers marked with the &q

Re: Please document the caching and its user options

Eli Zaretskii writes: >> Eli Zaretskii writes: >> >> >> I was referring to some kind of global option that defines cache >> >> directory, data directory, etc. Something akin XDG. >> > >> > We already have xdg-cache-home (and a few others in xdg.el). Is that >> > what you meant? >> >> Yes, exc

Re: Please document the caching and its user options

Colin Baxter writes: > This what I cannot understand. If the user never uses latex preview why > cannot the latex preview cache be disabled? I don't want to go on and on > and become a bore - I've said my piece and I will be silent from now > on. I believe tha

Re: Please document the caching and its user options

d > by parser. The parser cache in particular can be disabled. But not > the latex preview cache. This what I cannot understand. If the user never uses latex preview why cannot the latex preview cache be disabled? I don't want to go on and on and become a bore - I've said m

Re: Please document the caching and its user options

Eli Zaretskii writes: > Let me clarify. In the scenario in which I found out about Org > caching, I didn't use latex-preview, not at all Sure. Org uses multiple caches. You encountered the one created by parser. The parser cache in particular can be disabled. But not the latex preview cache

Re: Please document the caching and its user options

an one kind of caching, I hope they will all be documented), but evidently the caching by Org happens (by default!) even if the user doesn't come anywhere near latex-preview.

Re: Please document the caching and its user options

Colin Baxter writes: > > 1. not reasonable in a sense that it has downsides compared to > > what we do now - save latex previews on disk 2. impossible in a > > sense that we do not have an existing toggle to store cached > > previews in memory. Such functionality would have to be

Re: Please document the caching and its user options

e significant changes in the >>> Org mode codebase. >> >> I understand all that, but if the user wants it, and insist on >> not caching any data, let them have what they want. > It is not about letting or not letting them. I would have to > impl

Re: Please document the caching and its user options

On Wed, Jun 19, 2024 at 12:06:42AM +0200, Rudolf Adamkovič wrote: > Ihor Radchenko writes: > > > Can we instead store them in memory? Yes, but (1) it will make Emacs RAM > > consumption grow constantly and more and more previews are generated; > > (2) it will require significant changes in the Or

Re: Please document the caching and its user options

Ihor Radchenko writes: > Can we instead store them in memory? Yes, but (1) it will make Emacs RAM > consumption grow constantly and more and more previews are generated; > (2) it will require significant changes in the Org mode codebase. And, (3) all previews would be lost every time one shuts d

Re: Please document the caching and its user options

> From: Ihor Radchenko > Cc: Eli Zaretskii , emacs-orgmode@gnu.org > Date: Tue, 18 Jun 2024 15:53:18 + > > Daniel Clemente writes: > > > What's the setting then to disable org-persist? I.e. to disable > > creating of files like ~/.cache/org-persist/gc-lock.eld > > Many people seem to want t

Re: Please document the caching and its user options

Eli Zaretskii writes: >> Can we instead store them in memory? Yes, but (1) it will make Emacs RAM >> consumption grow constantly and more and more previews are generated; >> (2) it will require significant changes in the Org mode codebase. > > I understand all that, but i

Re: Please document the caching and its user options

costly) > > Can we instead store them in memory? Yes, but (1) it will make Emacs RAM > consumption grow constantly and more and more previews are generated; > (2) it will require significant changes in the Org mode codebase. I understand all that, but if the user wants it, and in

Re: Please document the caching and its user options

Eli Zaretskii writes: >> It is impossible. We need to store files like latex previews >> somewhere. This somewhere is org-persist-directory now. > > Sorry, I don't understand: why do you need to store them as files? > Why not keep the previews in buffer(s)? In Org mode, in order to create latex

Re: Please document the caching and its user options

Daniel Clemente writes: >> Nope. "org-persist" directory is not only used by org-element. If some >> other parts of Org need to cache something, they can also store cache >> there. >> > What's the setting then to disable org-persist? I.e. to disable > creating of files like ~/.cache/org-persist/g

Re: Please document the caching and its user options

same files from different emacs instances? if the Org files include sensitive data?) If you use `org-crypt', note that the persisted cache may temporarily store unencrypted data after decrypting a header. Use `org-element-use-cache' instead to use a memory-only cache.") I mentio

Re: Please document the caching and its user options

storing files on disk". > For instance: > (defvar org-element-use-cache t > "Non-nil when Org parser should cache its results.") > From that description, it's not clear to a new user whether they're > creating files on disk (as caches often do) or not. D

Re: Please document the caching and its user options

ng xdg-cache-home and its fallbacks is a de-facto standard of solving this in Emacs, and it supports all the platforms. Even startup.el uses it (albeit by customized code, to avoid interfering with user customizations) when looking for init files and suchlikes. So I think you raise a problem tha

Re: Please document the caching and its user options

acs, for all possible kinds of cache/history data. > > Deleting files in a directory, recursively if needed, is already > available. is that what you meant? No. I mean a new user option like `clear-caches-on-exit' that will work across all the packages. Then, concerned users may set it

Re: Please document the caching and its user options

> > Please document the caching features of Org in the manual, including > > how to turn that off. (I also question the wisdom of turning this on > > by default without as much as a single request for confirmation from > > the user.) > Hmm. What aspect of caching do you

Re: Please document the caching and its user options

> From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org, emacs-de...@gnu.org, Michael Albinus > > Date: Sat, 15 Jun 2024 14:13:03 + > > CCing emacs-devel as I'd like to upgrade this discussion to Emacs-wide > context. > > Eli Zaretskii writes: > > >> ... I wanted to know what is being cached,

Re: Please document the caching and its user options

CCing emacs-devel as I'd like to upgrade this discussion to Emacs-wide context. Eli Zaretskii writes: >> ... I wanted to know what is being cached, why, and in what file/directory. >> > > ... >> Would it be possible for Emacs to define a framework for cache/var/data >> locations? Such framewor

Re: Please document the caching and its user options

Ihor Radchenko writes: >> The emacs-internal encoding is not binary. In almost all the cases it >> is indistinguishable from utf-8-unix. It differs where a buffer >> includes characters outside of the Unicode codespace. The usual >> practice in Emacs is that files holding internal data use >>

Re: Please document the caching and its user options

> From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Date: Sat, 15 Jun 2024 12:47:29 + > > Eli Zaretskii writes: > > >> I am not convinced that we have to do it. > > > > That's too bad. When a user finds out about this caching, how do you >

Re: Please document the caching and its user options

Eli Zaretskii writes: >> I am not convinced that we have to do it. > > That's too bad. When a user finds out about this caching, how do you > propose that he/she looks for the information about it? I wanted to > know what is being cached, why, and in what file/directo

Re: Please document the caching and its user options

The > > manual is currently completely silent about it. > > > > Next, please document the user options that control this caching, and > > especially those options which can be used to turn this caching off or > > direct it to a different place. > > I am not con

Re: Please document the caching and its user options

Eli Zaretskii writes: >> Hmm. What aspect of caching do you want us to document? > > First and foremost, that it exists, and is turned on by default. The > manual is currently completely silent about it. > > Next, please document the user options that control this cach

Publishing cache (was: Please document the caching and its user options)

Jens Lechtenboerger writes: > Jumping in here, I do not understand the publishing cache. Some of > my org documents are re-published every time, while others are only > re-published after changes. What is checked where? See "14.4 Triggering Publication" section of Org mode manual: Org

Re: Please document the caching and its user options

On 2024-06-14, Ihor Radchenko wrote: > Eli Zaretskii writes: > >> Please document the caching features of Org in the manual, including >> how to turn that off. (I also question the wisdom of turning this on >> by default without as much as a single request for confi

Re: Please document the caching and its user options

off the caching. > > > > Please document the caching features of Org in the manual, including > > how to turn that off. (I also question the wisdom of turning this on > > by default without as much as a single request for confirmation from > > the user.) > &

Re: Please document the caching and its user options

g this on > by default without as much as a single request for confirmation from > the user.) Hmm. What aspect of caching do you want us to document? FYI, Org mode has been doing various forms of caching since forever. Recently, we just employed a bit more regular API and introduced one more kind of

Re: [BUG] org-export: incorrect assignment of bind keywords [9.7.3 (9.7.3-2f1844 @ /home/user/.emacs.d/elpa/org-9.7.3/)]

"Suhail Singh" writes: > In Org 9.7.3, the variables bound using the =#+BIND= keyword have values that > are nested. E.g., when a string value is provided, the value actually gets > set > to a singleton list containing said string. This can be observed using the > snippet: > ... > #+RESULTS: b

Please document the caching and its user options

there's nothing in the manual about turning off the caching. Please document the caching features of Org in the manual, including how to turn that off. (I also question the wisdom of turning this on by default without as much as a single request for confirmation from the user.) Please als

[BUG] org-export: incorrect assignment of bind keywords [9.7.3 (9.7.3-2f1844 @ /home/user/.emacs.d/elpa/org-9.7.3/)]

variable var) val))) +(set (make-local-variable var) (car val (cl-defun org-export-copy-buffer (&key to-buffer drop-visibility drop-narrowing drop-contents base-commit: 3e4c89e55649f95cffbf70fcf64dcbc69760f96f -- 2.45.2 Emacs : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) Package: Org mode version 9.7.3 (9.7.3-2f1844 @ /home/user/.emacs.d/elpa/org-9.7.3/) -- Suhail

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Suhail Singh writes: > Ihor Radchenko writes: > >> Accidentally deleted newline here* Heading 2 > > Are there situations which result in such accidental newline deletions > that are likely to not be immediately caught if not prompted by the > checker? Or was the checker added preemptively? I h

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > Accidentally deleted newline here* Heading 2 Are there situations which result in such accidental newline deletions that are likely to not be immediately caught if not prompted by the checker? Or was the checker added preemptively? Perhaps the checker should simply be

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Suhail Singh writes: > On a related note, what specific situation(s) was this checker intended > to help the user in? I.e., what are the situations that could result in > misplaced headings? For example, * Heading 1 * Heading 2* Heading 3 * Heading 4 or * Heading Some te

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

. #+begin_src org :tangle /tmp/misplaced-heading-mre-3.org | Blah | Hello** world | | | | #+call: blah :var foo="hello** world" #+end_src On a related note, what specific situation(s) was this checker intended to help the user in? I.e., what are the situations

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > Oops. > I amended the fix now. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6c862699a It's better, but not quite there. For instance, tangle the block below into an org file and observe the reported warning. #+begin_src org :tangle /tmp/misplaced-h

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Suhail Singh writes: >> Fixed, on bugfix. >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b8497aa7f > > This doesn't seem fixed as of 9.7.3 (the MRE above still shows spurious > warning). It seems that org-at-block-p returns nil when point is within > the block. Oops. I amend

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > "Suhail Singh" writes: > >> When there is, say, an "example" result block that is indented (i.e., >> the entire block including the delimiters is indented) and it contains >> some asterisks in the middle, org-lint considers it to be a possible >> case of misplaced-headin

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

//git.sr.ht/~bzg/worg/commit/7f498b97 >> Further, the distant goal is to implement integration of org-lint into >> flycheck/flymake. And we do need user-level config for which checkers >> should be enabled for "full" org-lint check and for "quick" check on >> t

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

ome much more complicated as a result of it. > Further, the distant goal is to implement integration of org-lint into > flycheck/flymake. And we do need user-level config for which checkers > should be enabled for "full" org-lint check and for "quick" check on > the

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

ment. Further, the distant goal is to implement integration of org-lint into flycheck/flymake. And we do need user-level config for which checkers should be enabled for "full" org-lint check and for "quick" check on the fly then. -- Ihor Radchenko // yantar92, Org mode co

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > This would work, but it modifies the checker list destructively. Yes, as does org-lint-add-checker. In the same vein, org-lint-remove-checker is intended to be able to undo the "effect" of one or more org-lint-add-checker invocations. > What about introducing some kind

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Suhail Singh writes: > Ihor Radchenko writes: > >> There is currently no such way. Although, it would be nice to have such >> a feature. Patches welcome! > > See attached. Thanks! > +;;;###autoload > +(defun org-lint-remove-checker (name &rest names) > + "Remove checker(s) from linter. > +NAM

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > There is currently no such way. Although, it would be nice to have such > a feature. Patches welcome! See attached. >From 7d7a240d82202fcb3323453648dd2d8b78d22a6f Mon Sep 17 00:00:00 2001 From: Suhail Date: Wed, 5 Jun 2024 11:55:10 -0400 Subject: [PATCH] org-lint: Add

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

n, however, for languages in general wouldn't it be > better to consult something like the output of #'org-src-get-lang-mode > and see if that mode is either defined or can be loaded (depending on > whether or not we require the user to ensure whether the feature > representing

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

Ihor Radchenko writes: > Org mode has no idea which languages are intended to be executed, but > happen to not have their ob-lang.el backend loaded; and which > languages do not need execution. So, Org mode warns just in case. If the primary function of this check is to ensure that

Re: [BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

"Suhail Singh" writes: > When there is, say, an "example" result block that is indented (i.e., > the entire block including the delimiters is indented) and it contains > some asterisks in the middle, org-lint considers it to be a possible > case of misplaced-heading. Case in point: > > #+begin_s

Re: [BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

"Suhail Singh" writes: > Any code block in a language that isn't intended to be executed results in a > warning from 'suspicious-language-in-src-block checker. For instance: > > #+begin_src conf > [Unit] > Description=Blah > #+end_src > > In the above example, conf-mode exists and is used by

[BUG] org-lint: Spurious warning by 'suspicious-language-in-src-block [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

used by Org to provide syntax highlighting and yet, org-lint reports a warning. Emacs : GNU Emacs 29.3 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/) -- Suhail

[BUG] org-lint: Spurious warning from 'misplaced-heading lint-checker [9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/)]

cairo version 1.18.0) Package: Org mode version 9.7.2 (release_N/A-N/A-88dd2c @ /home/user/.emacs.d/elpa/org-9.7.2/) -- Suhail

  1   2   3   4   5   6   7   8   >