Re: org-persist-write:index takes minutes to run

Karthik Chikmagalur writes: > It's definitely better than the version of org-persist on main right > now. Emacs blocks intermittently over the ~3 seconds it takes to > preview 600 fragments in my test file, but it's not completely blocked > for 30 seconds like before. Emacs does not block when

Re: org-persist-write:index takes minutes to run

>I feel that it is too long and weird, so I restart my Emacs daemon, and the >results do not change. Just moments ago, I test it in other way. I stay the buffer view in the end of my org file, where there are many fragments. When I execute (my-org-latex-preview-benchmark), it only takes 0.5s-1s,

Re: org-persist-write:index takes minutes to run

Karthik Chikmagalur writes: >>> 1. When running `save-buffers-kill-emacs', the time is down from several >>> minutes to about 10 seconds -- still undesirably long but not egregious. >>> This is the profile org-persist-delay-kill-emacs.eld. >> >> Ok. What about write time distribution now? > > Sor

Re: org-persist-write:index takes minutes to run

> I tried to find the reason in my LaTeX header uasge. > If I ban the usage of #+LATEX_HEADER: \usepackage{mathpazo}, the test > time reduced to 3.5s. (I love this font set) > If I ban the fontenc + mathpazo, it remains 3.5s. > If I ban the lmodorn + fontenc + mathpazo, it reduces to 1.9s. This is

Re: org-persist-write:index takes minutes to run

I tried to find the reason in my LaTeX header uasge. If I ban the usage of #+LATEX_HEADER: \usepackage{mathpazo}, the test time reduced to 3.5s. (I love this font set) If I ban the fontenc + mathpazo, it remains 3.5s. If I ban the lmodorn + fontenc + mathpazo, it reduces to 1.9s. Other packages li

Re: org-persist-write:index takes minutes to run

the result of health-check is as follows. I don't know why "Caching with org-persist" is ON. The value of `org-latex-preview-cache` is exactly "temp" now. -- Your LaTeX preview process Precompile with latex -> LaTeX Compile with pdflatex -> Convert to SVG with dvisvgm pdflatex

Re: org-persist-write:index takes minutes to run

> > Could you run this code, then run M-x my-org-latex-preview-benchmark > > on your file and report the time? (You should avoid the > > precompilation first by previewing a single fragment first.) > > Ok, I test several times, in an org file with about 700 fragments. I > test first in my current

Re: org-persist-write:index takes minutes to run

I am not kidding you in fact.  In each test, I execute #+begin_src elisp (org-latex-preview-clear-cache) (setq org-latex-preview-cache 'temp) #+end_src and compile \(\alpha\), after the precompilation hint vanishes, I execute (my-org-latex-preview-benchmark), and the result is always around 5.5s.

Re: org-persist-write:index takes minutes to run

> I am not kidding you in fact.  > In each test, I execute > #+begin_src elisp > (org-latex-preview-clear-cache) > (setq org-latex-preview-cache 'temp) > #+end_src > > and compile \(\alpha\), after the precompilation hint vanishes, I > execute (my-org-latex-preview-benchmark), and the result is al

Re: org-persist-write:index takes minutes to run

Could you run this code, then run M-x my-org-latex-preview-benchmark on your file and report the time? (You should avoid the precompilation first by previewing a single fragment first.) Ok, I test several times, in an org file with about 700 fragments. I test first in my current workspace (with

Re: org-persist-write:index takes minutes to run

> The overall current performance is quite satisfactory. I describe in > two cases as Karthik's classification. > > 1. When running org-latex-preview-all inside an org file (about 700 > fragments), Emacs is not unresponsive in comparison to the past, and > the fragments rendering is much more fast

Re: org-persist-write:index takes minutes to run

黄煜 writes: > 2. When running save-buffer-kill-emacs, the time has been reduced from about > 5 minutes to 2-3s (turning off org-roam-autosync-mode). For my current needs, > this speed is more than satisfactory. However, according to previous > statement last year, this speed would rapidly decre

Re: org-persist-write:index takes minutes to run

Thanks for your latest diff! The overall current performance is quite satisfactory. I describe in two cases as Karthik's classification. 1. When running org-latex-preview-all inside an org file (about 700 fragments), Emacs is not unresponsive in comparison to the past, and the fragments renderin

Re: org-persist-write:index takes minutes to run

Karthik Chikmagalur writes: >> What if you try the attached diff? > > Two cases, profiles for both are attached: > > 1. When running `save-buffers-kill-emacs', the time is down from several > minutes to about 10 seconds -- still undesirably long but not egregious. > This is the profile org-persis

Re: org-persist-write:index takes minutes to run

Ihor, I mistakenly replied only to you instead of the list just now. Let me know if I should resend that email to the list. Karthik Ihor Radchenko writes: > Karthik Chikmagalur writes: > >>> My guess is 7999433067 or 2a620113c1, but need to confirm. >> >> Yes it's one of those two, I'm not s

Re: org-persist-write:index takes minutes to run

Karthik Chikmagalur writes: > I mistakenly replied only to you instead of the list just now. Let me > know if I should resend that email to the list. Please do.

Re: org-persist-write:index takes minutes to run

Karthik Chikmagalur writes: >> My guess is 7999433067 or 2a620113c1, but need to confirm. > > Yes it's one of those two, I'm not sure which of the two it is as I > haven't had the time to reset the branch and test each one. What if you try the attached diff? diff --git a/lisp/org-persist.el b/l

Re: org-persist-write:index takes minutes to run

>> Do you know which commit introduced the slowdown? >> ... > > My guess is 7999433067 or 2a620113c1, but need to confirm. Yes it's one of those two, I'm not sure which of the two it is as I haven't had the time to reset the branch and test each one. Karthik

Re: org-persist-write:index takes minutes to run

Ihor Radchenko writes: > Do you know which commit introduced the slowdown? > ... My guess is 7999433067 or 2a620113c1, but need to confirm. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at

Re: org-persist-write:index takes minutes to run

Karthik Chikmagalur writes: > I can confirm that this slowdown currently also happens when generating > LaTeX previews, when we cache them for the first time with > `org-persist-register'. It's less of an issue because most Org files > contain fewer than 800 LaTeX fragments, but it still locks u

Re: org-persist-write:index takes minutes to run

Karthik Chikmagalur writes: > I'm attaching a profiler profile for one of these calls to > `save-buffers-kill-emacs'. Judging from the profile, most of the time is spent writing data. > This is probably relevant: I am on Tecosaur's fork of Org mode, > > https://code.tecosaur.net/tec/org-mode >

Re: org-persist-write slowing down kill-buffer

Ihor Radchenko writes: > Karthik Chikmagalur writes: > >> - My org-persist-dir is 627MB in size. > > What is your (length org-persist--index) ? > > Also, it does not look like your `org-element-ast-map' is compiled. More information has been requested, but none provided within over a month. Clo

Re: org-persist-write slowing down kill-buffer

Karthik Chikmagalur writes: > I've been noticing that kill-buffer blocks Emacs for a noticeable > period when killing org buffers. Here are elp results obtained by > instrumenting org-persist-* and kill-buffer: > > | Function name | Call count | Elapsed time | Average > time

Re: org-persist asking for temp-file encoding every time

On 06-04-2024 14:44, Ihor Radchenko wrote: You need to redirect where Emacs looks for Org mode: (add-to-list 'load-path "/path/to/org-mode/lisp") Somewhere early in your init.el. Thank you for the hint. It seems to be working without the issue in the development version. Brian

Re: org-persist asking for temp-file encoding every time

Brian Elmegaard writes: > On 20-03-2024 10:14, Ihor Radchenko wrote: >> org-persist forces encoding in Org 9.7-pre (development version). >> May you try it and let us know if your problem is still present there? >> > I have been looking into this, but it is not clear to me how to override > emac

Re: org-persist asking for temp-file encoding every time

On 20-03-2024 10:14, Ihor Radchenko wrote: org-persist forces encoding in Org 9.7-pre (development version). May you try it and let us know if your problem is still present there? I have been looking into this, but it is not clear to me how to override emacs' builtin org-mode, and run another v

Re: org-persist asking for temp-file encoding every time

Brian Elmegaard writes: > I am experiencing a small issue with an org-file. > Every time I close it I am prompted with: > Select coding system (default utf-8): > when org-mode is saving a *Temp file*. > > In the *Messages* buffer it says: > org-persist: Writing to > "c:/Users/user/AppData/Roami

Re: org-persist - not wanted.

Colin Baxter writes: > I find a file called "gc-lock.eld" has been deposited un-requested and > un-wanted in ~/.emacs.d/org-persist. > > I had thought I had disabled org-persist with the following > > --8<---cut here---start->8--- > (setq org-persist-disable-wh

Re: org-persist - not wanted.

> Colin Baxter writes: > I find a file called "gc-lock.eld" has been deposited un-requested > and un-wanted in ~/.emacs.d/org-persist. > I had thought I had disabled org-persist with the following > (setq org-persist-disable-when-emacs-Q t) (defun > me/advice--org-persis

Re: org-persist-write slow when pp-use-max-width is t

Michael Eliachevitch writes: > I submitted a bug report where I attached the index file and a minimal > example file which benchmarks running pp on it, with which I could reproduce > my issue from emacs -Q: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58687 > > Let's see what the emacs dev

Re: org-persist files in /tmp

On Sun, Dec 25, 2022 at 09:30:00AM +, Ihor Radchenko wrote: > writes: > > >> Another idea is to avoid caching of parse result for small files. > > > > I haven't been following along very closely, but seeing the > > involved complexities, I'd appreciate a knob to disable caching > > altogether

Re: org-persist files in /tmp

Max Nikulin writes: > If you demonstrate that e.g., when working with encrypted files, their > sensitive content leaks to the cache then it will raise the severity of > the issue. Nothing related to encrypted files is ever written by org-persist. Some edge cases might exist for org-crypt, but

Re: org-persist files in /tmp

writes: >> Another idea is to avoid caching of parse result for small files. > > I haven't been following along very closely, but seeing the > involved complexities, I'd appreciate a knob to disable caching > altogether. org-element-cache-persistent > My usage of Org hasn't triggered any slowdo

Re: org-persist files in /tmp

Max Nikulin writes: > Ihor, I do not like that after your latest changes temporary directory > became world readable. This is the only sane way for emacs -Q, AFAIK. And the cache will now only exist while Emacs is running (for -Q cmd arg). Removed unconditionally upon exiting. -- Ihor Radchen

Re: org-persist files in /tmp

Greg Minshall writes: >> Do we need to care about cleaning up /tmp? > > my two cents is that maybe one should not care so much about cleaning up > /tmp, but i think it's worthwhile trying not to clutter it up too much. I improved things a tiny bit more. Now, whatever is created by emacs -Q will

Re: org-persist files in /tmp

On Fri, Dec 23, 2022 at 09:12:52PM +0700, Max Nikulin wrote: [...] > If you demonstrate that e.g., when working with encrypted files, their > sensitive content leaks to the cache then it will raise the severity of the > issue. Of course, the always appreciated option is to provide a patch that >

Re: org-persist files in /tmp

On 23/12/2022 13:35, to...@tuxteam.de wrote: On Thu, Dec 22, 2022 at 11:07:52PM +0700, Max Nikulin wrote: Another idea is to avoid caching of parse result for small files. I haven't been following along very closely, but seeing the involved complexities, I'd appreciate a knob to disable cachin

Re: org-persist files in /tmp

On Thu, Dec 22, 2022 at 11:07:52PM +0700, Max Nikulin wrote: > On 22/12/2022 22:45, Tim Cross wrote: > > Could some of the issues people are concerned about regarding use of > > /tmp be avoided if instead the temporary files were put into ~/.cache? [...] > Another idea is to avoid caching of pars

Re: org-persist files in /tmp

On 22/12/2022 22:45, Tim Cross wrote: Could some of the issues people are concerned about regarding use of /tmp be avoided if instead the temporary files were put into ~/.cache? There is no ~/.cache on Windows, the fallback is ~/.emacs.d. org-persist files in ~/.emacs.d was the original source

Re: org-persist files in /tmp

Max Nikulin writes: > On 22/12/2022 19:34, Ruijie Yu wrote: >> One possible approach to this is to have all org-persist related >> temporary directories into an overall "$TMPDIR/org-persist" directory. > > Predictable name in a "world" writable directory generally is not a good > idea. Multipl

Re: org-persist files in /tmp

On 22/12/2022 19:34, Ruijie Yu wrote: One possible approach to this is to have all org-persist related temporary directories into an overall "$TMPDIR/org-persist" directory. Predictable name in a "world" writable directory generally is not a good idea. Multiple users may try to run Org on the

Re: org-persist files in /tmp

Greg Minshall writes: > hi, Ihor, > >> Do we need to care about cleaning up /tmp? > > my two cents is that maybe one should not care so much about cleaning up > /tmp, but i think it's worthwhile trying not to clutter it up too much. > > cheers, Greg One possible approach to this is to have all

Re: org-persist files in /tmp

Ihor Radchenko writes: > "Fraga, Eric" writes: > >> for some reason, I am now getting many (tens) directories of the form >> org-persist-NN in /tmp. These seem to include an index file and a >> cache type sub-directory structure. Why are these there and does >> anything clean them up? >>

Re: org-persist files in /tmp

hi, Ihor, > Do we need to care about cleaning up /tmp? my two cents is that maybe one should not care so much about cleaning up /tmp, but i think it's worthwhile trying not to clutter it up too much. cheers, Greg

Re: org-persist files in /tmp

William Denton writes: >> You should _not_ see something like >> >> ((:container >> ((index "2.7")) >> :persist-file "d0/5078fe-5e31-4ddb-95a0-93ceae58df0c" :associated nil >> :expiry never :last-access 1671637032.483552 :last-access-hr >> "2022-12-21T18:37:12+0300")) >> >> as the only conten

Re: org-persist files in /tmp

On 21 December 2022, Ihor Radchenko wrote: Could be. If so, it may indicate some issue with logic. The index should not be written if the only entry inside index file is index version itself. You should _not_ see something like ((:container ((index "2.7")) :persist-file "d0/5078fe-5e31-4ddb-

Re: org-persist files in /tmp

"Fraga, Eric" writes: > On Wednesday, 21 Dec 2022 at 15:06, Ihor Radchenko wrote: >> If you run something like make test or emacs -Q + org, it is expected. >> These are throwaway directories used by org-persist for emacs -Q. > > I am not explicitly running either of those (at the moment). > > I w

Re: org-persist files in /tmp

On Wednesday, 21 Dec 2022 at 15:06, Ihor Radchenko wrote: > If you run something like make test or emacs -Q + org, it is expected. > These are throwaway directories used by org-persist for emacs -Q. I am not explicitly running either of those (at the moment). I wonder if this is somehow related t

Re: org-persist files in /tmp

"Fraga, Eric" writes: > for some reason, I am now getting many (tens) directories of the form > org-persist-NN in /tmp. These seem to include an index file and a > cache type sub-directory structure. Why are these there and does > anything clean them up? > > I have nothing related to org-pe

Re: org-persist-write slow when pp-use-max-width is t

pp-max-width has been introduced in Emacs 29. The fact that pp becomes too slow is likely something to be fixed before the next Emacs release. Good catch and I agree. I compile emacs from the master branch and probably discovered in the emacs-news which I check between upgrades and I probabl

Re: org-persist-write slow when pp-use-max-width is t

Michael Eliachevitch writes: > I was wondering why kill-emacs emacs takes over a minute and after some > profiling I found out that the call to org-persist-write-all takes long when > pp-use-max-width is set to t and pp-max-width is also set (in my case to t, > the window-width), which enables

Re: org-persist-gc and tramp

> Off topic: Did you report the issue to evil devs? Not yet. Needed to understand what is going on. > alternative workaround could be setting org-fold-core-style to > 'overlays. Yes! This fixes the issue, and is consistent with my observations in the other thread (I will respond with more there)

Re: org-persist-gc and tramp

Tom Gillespie writes: > I was running a version from back in december due to the evil > search issues I was having. Off topic: Did you report the issue to evil devs? Note that an alternative workaround could be setting org-fold-core-style to 'overlays. Best, Ihor

Re: org-persist-gc and tramp

> Can you confirm that you are using the latest version of Org? I was running a version from back in december due to the evil search issues I was having. Updating to the latest version resolves indeed resolves the org-persist issue. Thanks! Tom

Re: org-persist-gc and tramp

Tom Gillespie writes: > While debugging an unrelated issue I noticed that > tramp was initiating a new connection every time > save-buffers-kill-emacs ran. I eventually tracked it > down to org-persist-gc running on kill-emacs-hook. > ... > I see a couple potential fixes. > - skip gc for remote f

Re: org-persist uses Emacs 28+ buffer-local-boundp

Kyle Meyer writes: > Could you update org-persist-write:elisp to be compatible with older > Emacs versions (e.g., by inlining the short definition and adding a > comment about why buffer-local-boundp isn't used)? Done in 0cb076020. Thanks for the heads up! Best, Ihor

Re: org-persist cache for remote files

Lele Gaifax writes: > Hi Ihor, > > I had some trouble testing your patches, and the outcome is still unclear to > me: apparently (again, cannot be sure this is not caused by "improper" > application of the patches) the new version of org-persist, with default value > for o-p-remote-files (100),

Re: org-persist cache for remote files

Hi Ihor, I had some trouble testing your patches, and the outcome is still unclear to me: apparently (again, cannot be sure this is not caused by "improper" application of the patches) the new version of org-persist, with default value for o-p-remote-files (100), removes any remote file from the p

Re: org-persist cache for remote files

Lele Gaifax writes: > I couldn't test yet, but I saw a couple of other glitches, sorry for not > noticing first. Thanks for the proof reading. I updated the patch accordingly. Best, Ihor >From 557e7cec6dd22b09468b82650feed2020f97d781 Mon Sep 17 00:00:00 2001 Message-Id: <557e7cec6dd22b09468b82

Re: org-persist cache for remote files

Lele Gaifax writes: >> + :group 'org-persist >> + :type '(choice (const :tag "Never" nil) >> + (const :tag "Always" t) >> + (number :tag "Keep note more than X files") > > Now that you explained the meaning, maybe better to be explicit here, > mentioning "X remot

Re: org-persist cache for remote files

Ihor Radchenko writes: > Lele Gaifax writes: > >> In the meanwhile, here below some notes: > > Thanks! See the updated patch. Great, you're so fast! :-) I couldn't test yet, but I saw a couple of other glitches, sorry for not noticing first. > ... > +(defcustom org-persist-remote-files 100

Re: org-persist cache for remote files

Lele Gaifax writes: > In the meanwhile, here below some notes: Thanks! See the updated patch. Best, Ihor >From 92878fab54c26800562409f3c686f065b7523a61 Mon Sep 17 00:00:00 2001 Message-Id: <92878fab54c26800562409f3c686f065b7523a61.1639838789.git.yanta...@gmail.com> From: Ihor Radchenko Date:

Re: org-persist cache for remote files

Ihor Radchenko writes: > Lele Gaifax writes: > >>> Maybe we should better make this a user option? >> >> Yes, that's what I had in mind: when (say) org-persist-do-not-auto-gc-remotes >> is enabled, the cleanup procedure would ignore remote Org documents and a new >> explicit (interactive) org-pe

Re: org-persist cache for remote files

Lele Gaifax writes: >> Maybe we should better make this a user option? > > Yes, that's what I had in mind: when (say) org-persist-do-not-auto-gc-remotes > is enabled, the cleanup procedure would ignore remote Org documents and a new > explicit (interactive) org-persist-gc-remotes would take care

Re: org-persist cache for remote files

Ihor Radchenko writes: > Lele Gaifax writes: > >> I wonder if there is some mechanism I could use to either prevent caching >> of non-local documents or to avoid the check on existence in the >> org-persist-gc. > > I can easily make a change that always garbage-collect non-local > documents with

Re: org-persist

Hi, Ihor Radchenko writes: >> I had originally set org-element-use-cache to nil because I remember >> reading somewhere that the nil setting would help prevent emacs from >> hanging in org-mode. > > The cache code has been refactored. I tried my best to fix all the bugs > causing the hangs and

Re: org-persist warning when archiving

> Ihor Radchenko writes: > Colin Baxter 😺 writes: >> Hi Ihor, >> >> My ECM is as follows. I'm using GNU-Linux and emacs-28.0.60. > Thanks! I was able to reproduce on my system. Should be fixed on > main via 9f87b1cc3. Yes, I can confirm the problem is fixed for me.

Re: org-persist warning when archiving

Colin Baxter 😺 writes: > Hi Ihor, > > My ECM is as follows. I'm using GNU-Linux and emacs-28.0.60. Thanks! I was able to reproduce on my system. Should be fixed on main via 9f87b1cc3. Best, Ihor

Re: org-persist warning when archiving

Hi Ihor, My ECM is as follows. I'm using GNU-Linux and emacs-28.0.60. 1. Delete any existing org-persist directory. 2. mkdir ~/a 3. emacs -Q 4. Evaluate path to latest org-mode. I enter (add-to-list 'load-path (expand-file-name "~/path/to/git/org-mode/lisp")) in the scratch buffer and do C-

Re: org-persist warning when archiving

Colin Baxter 😺 writes: > I have now discovered what is causing the org-persist warnings. It is > because my org-agenda files have local variables present. If I remove > the local variables, the warnings disappear. Do you mean file-local? Can you provide a minimal Org file example? I also have f

Re: org-persist warning when archiving

I have now discovered what is causing the org-persist warnings. It is because my org-agenda files have local variables present. If I remove the local variables, the warnings disappear. Best wishes, Colin.

Re: org-persist warning when archiving

> Ihor Radchenko writes: > Colin Baxter 😺 writes: >> Ok, I now applied your patch and remade org-mode. Unfortunately, >> I don't see any change. I still get the warning on all the >> archive commands: org-agenda-archive-default, org-agenda-archive >> and org-agenda-archiv

Re: org-persist warning when archiving

Colin Baxter 😺 writes: > Ok, I now applied your patch and remade org-mode. Unfortunately, I don't > see any change. I still get the warning on all the archive commands: > org-agenda-archive-default, org-agenda-archive and > org-agenda-archive-default-with-confirmation. I've appended the warning >

Re: org-persist warning when archiving

Hi Ihor, > Ihor Radchenko writes: > Colin Baxter 😺 writes: >> I'm running Org mode version 9.5 (release_9.5-178-gcf8906) on >> emacs-28.0.60. Unfortunately, I could not apply your patch >> ('patch would not apply') using either 'git apply /path/to/patch' >> or 'git a /pa

Re: org-persist warning when archiving

Colin Baxter 😺 writes: > I'm running Org mode version 9.5 (release_9.5-178-gcf8906) on > emacs-28.0.60. Unfortunately, I could not apply your patch ('patch would > not apply') using either 'git apply /path/to/patch' or 'git a > /path/to/patch'. Oops. Try the updated patch. The old one was based

Re: org-persist warning when archiving

Hi Thor, > Ihor Radchenko writes: > Colin Baxter 😺 writes: >> > Hello, Whenever I archive a DONE item via 'C-c C-x C-a' I get >> the > warning: >> >> > Warning (emacs): org-element--cache: Unregistered buffer > >> modifications detected. Resetting. >> >> > T

Re: org-persist warning when archiving

Colin Baxter 😺 writes: > > Hello, Whenever I archive a DONE item via 'C-c C-x C-a' I get the > > warning: > > > Warning (emacs): org-element--cache: Unregistered buffer > > modifications detected. Resetting. > > > The archiving is successful, but I keep getting the warning and

Re: org-persist warning when archiving

> Colin Baxter 😺 writes: > Hello, Whenever I archive a DONE item via 'C-c C-x C-a' I get the > warning: > Warning (emacs): org-element--cache: Unregistered buffer > modifications detected. Resetting. > The archiving is successful, but I keep getting the warning and >

Re: org-persist - bug report

Thanks. Worked for me

Re: org-persist - bug report

On 21/10/2021 23:03, Ihor Radchenko wrote: It was malformed add-hook call. Fixed in 5315773e8. Thank you, Ihor. I do not see problems I have noticed today anymore.

Re: org-persist - bug report

> Ihor Radchenko writes: > It was malformed add-hook call. Fixed in 5315773e8. Great! I've pulled org-mode and I can confirm I no longer see my org-persist errors. Excellent. I'm looking at the vc-diff buffer and it's amazing that such a small omission has such a major effect. Best wish

Re: org-persist - bug report

It was malformed add-hook call. Fixed in 5315773e8.

Re: org-persist - bug report

Ihor Radchenko writes: > ... There is no problem on Emacs 28, but I can see the error > using Emacs 26.3. I used the following command line from inside the Git > folder to run Emacs (debug.org is the provided minimal file): > > emacs -Q -L ./lisp -l org /tmp/debug.org > > Interestingly, the foll

Re: org-persist - bug report

Colin Baxter 😺 writes: > > M-x org-lint > > > Debugger entered--Lisp error: (error "Variable binding depth > > exceeds max-specpdl-size") ... org-filename-concat > > I can reproduce that. Then emacs just hangs. I have the latest org-mode. Thanks for another confirmation. I tried har

Re: org-persist - bug report

> Max Nikulin writes: > On 21/10/2021 02:04, Colin Baxter 😺 wrote: >> >> The max-specpdl-size error has happened again when I tried to add >> a note to an agenda item. Emacs hung and had to be killed. The >> debugger buffer was empty and the only other information given

Re: org-persist - bug report

On 21/10/2021 02:04, Colin Baxter 😺 wrote: The max-specpdl-size error has happened again when I tried to add a note to an agenda item. Emacs hung and had to be killed. The debugger buffer was empty and the only other information given was the message: mapc: Lisp nesting exceeds `max-lisp-eval-d

Re: org-persist - bug report

Colin Baxter 😺 writes: > > (setq org-element--cache-self-verify 'backtrace) > > (setq org-element--cache-self-verify-frequency 1) > > I set the above in my ~/.emacs > > > If a warning appears, backtrace could be helpful. If not, it > > should be something to do with org-element-ca

Re: org-persist

Samuel Wales writes: > On 10/19/21, Ihor Radchenko wrote: >> enabled all the time in future. If you have specific reasons to avoid >> org-element-cache, may you share them? > > fwiw, long ago, i disabled org element cache due to buffer corruption. > perhaps that has been fixed and tested. I ho

Re: org-persist

On 10/19/21, Ihor Radchenko wrote: > enabled all the time in future. If you have specific reasons to avoid > org-element-cache, may you share them? fwiw, long ago, i disabled org element cache due to buffer corruption. perhaps that has been fixed and tested. also i presume this is all on main n

Re: org-persist - bug report

> Ihor Radchenko writes: > Colin Baxter 😺 writes: >> >> I just upgraded my org-mode to the latest version in >> >> git. Whenever I visited a certain org file, my Emacs became >> >> unusable. Any attempt to use M-x (execute-extended-command) >> >> resulted in max-specpdl-s

Re: org-persist - bug report

Colin Baxter 😺 writes: > >> I just upgraded my org-mode to the latest version in > >> git. Whenever I visited a certain org file, my Emacs became > >> unusable. Any attempt to use M-x (execute-extended-command) > >> resulted in max-specpdl-size errors as did using C-x C-c to exit

Re: org-persist - bug report

> Ihor Radchenko writes: > Alastair Burt writes: >> Hi there, >> >> I couldn't find an issue-tracking system for org-mode as they >> have for projects on github. So I'm emailing you directly. > Thanks! The bug reporting for Org mode is by email. You can send > e

Re: org-persist

Colin Baxter 😺 writes: > Ok, thanks - that works - I used ~/.emacs.d/org-persist/. It might be > worth mentioning that the user should not create the > org-persist-directory himself. I did this originally (mkdir > ~/.emacs.d/org-persist , touch ~/.emacs.d/org-persist/index ) > and got various par

Re: org-persist - bug report

Alastair Burt writes: > Hi there, > > I couldn't find an issue-tracking system for org-mode as they have for > projects on github. So I'm emailing you directly. Thanks! The bug reporting for Org mode is by email. You can send email to Org mailing list at emacs-orgmode@gnu.org (also, see "1.4 Fee

Re: org-persist

> Ihor Radchenko writes: > Colin Baxter 😺 writes: >> I may not have understood things fully, but it seems that the >> org-persist directory is set only by the >> org-persist-path. Unfortunately, the resulting org-persist >> directory in ~/.cache is no good for me since I

Re: org-persist

Colin Baxter 😺 writes: > I may not have understood things fully, but it seems that the > org-persist directory is set only by the > org-persist-path. Unfortunately, the resulting org-persist directory in > ~/.cache is no good for me since I daily clear out my ~/.cache using > bleachbit. I can't f

Re: org-persist

> Ihor Radchenko writes: r> Colin Baxter 😺 writes: >> Thank you. I cloned org-mode afresh and got the same warning >> during 'make' - I presume that too is now fixed. r> The warning should never appear now. I removed it completely. >> > Note that org-persist is enabled

Re: org-persist

Colin Baxter 😺 writes: > Thank you. I cloned org-mode afresh and got the same warning during > 'make' - I presume that too is now fixed. The warning should never appear now. I removed it completely. > > Note that org-persist is enabled by default together with > > org-element-cache. Y

Re: org-persist

> Ihor Radchenko writes: > Colin Baxter 😺 writes: >> After today's pull of org-mode I get the warning that org-persist >> cannot read its index. This is an entirely new warning (as of >> today) and I assume is the result of the recent commits in >> org-persist. >> Pl

Re: org-persist

Colin Baxter 😺 writes: > After today's pull of org-mode I get the warning that org-persist cannot > read its index. This is an entirely new warning (as of today) and I > assume is the result of the recent commits in org-persist. > Please, can this be corrected. The warning is irritating, especia

  1   2   >