* Re: Emacs-orgmode Digest, Vol 217, Issue 20
[not found] <mailman.49.1710691207.14853.emacs-orgmode@gnu.org>
@ 2024-03-19 4:00 ` pessoa
0 siblings, 0 replies; only message in thread
From: pessoa @ 2024-03-19 4:00 UTC (permalink / raw)
To: emacs-orgmode
On Mon, Mar 18, 2024, at 12:00 AM, emacs-orgmode-request@gnu.org wrote:
> Send Emacs-orgmode mailing list submissions to
> emacs-orgmode@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/emacs-orgmode
> or, via email, send a message with subject or body 'help' to
> emacs-orgmode-request@gnu.org
>
> You can reach the person managing the list at
> emacs-orgmode-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Emacs-orgmode digest..."
>
>
> Today's Topics:
>
> 1. Re: Forcing tab-width to be 8 makes using Python source
> blocks very difficult (Rudi C)
> 2. Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing
> non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]
> (Damien Cassou)
> 3. Re: Things got very slow: profiler output (William Denton)
> 4. Re: Things got very slow: profiler output (Ihor Radchenko)
> 5. Re: Things got very slow: profiler output (Bruno Cardoso)
> 6. Re: Things got very slow: profiler output (Ihor Radchenko)
> 7. Re: [PATCH] Allow external libraries (org-roam) to supply
> org-id locations (Rick Lupton)
> 8. Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink (Leo Butler)
> 9. Re: Table column formula with remote reference (Wu Ming)
> 10. Re: Table column formula with remote reference (Wu Ming)
> 11. Re: Reproducible work with natively compiled Emacs
> (Pedro Andres Aranda Gutierrez)
> 12. Re: Reproducible work with natively compiled Emacs (Max Nikulin)
> 13. How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> (Matt)
> 14. How do I link to a specific line in an org-babel block? (Rudi C)
> 15. Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink (Ihor Radchenko)
> 16. Re: Reproducible work with natively compiled Emacs
> (Ihor Radchenko)
> 17. Re: [PATCH] Allow external libraries (org-roam) to supply
> org-id locations (Ihor Radchenko)
> 18. Re: Reproducible work with natively compiled Emacs
> (Pedro Andres Aranda Gutierrez)
> 19. Re: How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> (Ihor Radchenko)
> 20. Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing
> non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]
> (Gerard Vermeulen)
> 21. Re: Things got very slow: profiler output (Bruno Cardoso)
> 22. Re: How do I link to a specific line in an org-babel block?
> (Ihor Radchenko)
> 23. Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink (Leo Butler)
> 24. Re: How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> (Matt)
> 25. Re: Table column formula with remote reference (Ihor Radchenko)
> 26. Re: Things got very slow: profiler output (Ihor Radchenko)
> 27. Re: Reproducible work with natively compiled Emacs
> (Ihor Radchenko)
> 28. Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing
> non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]
> (Ihor Radchenko)
> 29. Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink (Ihor Radchenko)
> 30. Re: How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> (Ihor Radchenko)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 16 Mar 2024 21:09:07 +0330
> From: Rudi C <rudiwillalwaysloveyou@gmail.com>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Forcing tab-width to be 8 makes using Python source
> blocks very difficult
> Message-ID:
> <CAE9z9A1MquSYBq9JaY=UHHw5MG+DwDW+6CS5xOL1kqyRU3rsUA@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks, I don't have any problems now, so we can consider this closed.
>
> On Sat, Mar 16, 2024 at 2:32 PM Ihor Radchenko <yantar92@posteo.net> wrote:
>
>> Rudi C <rudiwillalwaysloveyou@gmail.com> writes:
>>
>> > ... runs `evil-shift-right`, which
>> > indents the selected region by the `evil-shift-width` amount.
>> > `evil-shift-width` is set based on `tab-width`.
>>
>> Are you sure?
>> I am looking at
>> https://github.com/emacs-evil/evil/blob/master/evil-vars.el#L175
>> and it appears that `evil-shift-width' has nothing to do with
>> `tab-width'. It is a customization with default value of 4.
>>
>> Also, do note that `evil-shift-width' in python code blocks may break
>> things when the code block itself is also indented. Org mode normally
>> discards this common indentation and takes care about distinguishing
>> (and not merging!) the tabs belonging to the code itself and the
>> tabs/spaces that are used to indent the whole code block:
>>
>> This whole code block is indented
>> #+begin_src python
>> def foo():
>> if True:
>> return 1;
>> #+end_src
>>
>> Indentation in Org mode blocks can be tricky and generic editing
>> commands may not cut it. Org mode itself does the indentation using the
>> code block's major mode in a separate buffer in order to keep things
>> consistent.
>>
>> > ... I solved this specific
>> > problem by overriding `evil-shift-width` using a timer in an org-mode
>> hook.
>> > The delay introduced by the timer was necessary, as something kept
>> > overriding my settings. Perhaps the magic machinery that sets `tab-width`
>> > in the source blocks can also set `evil-shift-width`. The best-case
>> > scenario would be to have a list of variables that need to be set from
>> > their major-mode buffer in the source blocks.
>>
>> Why not simply setting `evil-shift-width' to 4?
>>
>> >> May you please provide a detailed example where 8 spaces causes issues?
>> >
>> > My lists are still indenting with 2 spaces, so I am not actually seeing 8
>> > spaces. I have no idea why that is, but I very much like the 2-space
>> > indentation.
>> >
>> > ```
>> > - a
>> > - b
>> > ```
>> >
>> > I see 4 spaces in numerical lists, which again, I have no idea about:
>> >
>> > ```
>> > 1. hi
>> > 2. hi
>> > 3. hi
>> > ```
>>
>> Org mode aligns child sub-lists with parent item text. So, "-" is right
>> below "a" and "2." is right below "hi". List depth is not defined by the
>> absolute number of spaces/tabs.
>> See https://orgmode.org/manual/Plain-Lists.html
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20240316/c1555726/attachment.htm>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 16 Mar 2024 19:30:20 +0100
> From: Damien Cassou <damien@cassou.me>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing
> non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]
> Message-ID: <8734sq58sj.fsf@cassou.me>
> Content-Type: text/plain
>
> Ihor Radchenko <yantar92@posteo.net> writes:
>> Yes. You can add
>> #+property: header-args:text :eval no
>> on top of your Org file or add
>> (setq org-babel-default-header-args:text '((:eval . "no")))
>> to your config.
>
> org is amazing!
>
> Thank you very much for all your work.
>
> --
> Damien Cassou
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 16 Mar 2024 18:39:16 +0000
> From: William Denton <william@williamdenton.org>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: Bruno Cardoso <cardoso.bc@gmail.com>, Emacs Org mode mailing list
> <emacs-orgmode@gnu.org>
> Subject: Re: Things got very slow: profiler output
> Message-ID:
> <Thw2P_bFDxJukQTh_Fg125jTlrb4zmciJVc-5xswHWAgORE_DaK-ej0d2Yhi88VLJ0y5-i6IapzOx3fB2l5mrJ1CsbEmCRXA2Dtab6gQnG8=@williamdenton.org>
>
> Content-Type: text/plain; charset=utf-8
>
> On Saturday, March 16th, 2024 at 11:56, Ihor Radchenko
> <yantar92@posteo.net> wrote:
>
>> > > What if you try the following version of `org-activate-folds'?
>> > > ...
>> >
>> > It makes almost no difference.
>>
>> Ok.
>> Then, what about the latest main?
>
> I tried it, and I'm sorry to say all the same problems keep happening.
>
> I tried the test you mentioned here:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2024-03/msg00362.html
>
> I loaded up my big Org file and moved around a while. I got:
>
> Function Name Call Count Elapsed Time
> Average Time
> org-fold-core--property-symbol-get-create 33325 0.0058796690
> 1.764...e-07
>
> I don't know if that's helpful.
>
> For me all this is triggered by my work-diary.org file, which has fair
> bit of fontification in it: headings, 1200 clock entries, links, and so
> on. It had a big clockable at the bottom, which gave me the "Stack
> overflow in regexp matcher" I mentioned last month:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00347.html
>
> I moved the clocktable to another file and the error stopped. But now
> it's back. I've been adding to work-diary.org in the meantime, so
> perhaps the problem was triggered by going over some limit, and I got
> it down under that limit, but now it's back over. Bruno's problem is
> triggered by a large file---but surely many people here have large
> files in Org, so why aren't they seeing this? Frustrating.
>
> I turned on debugging and will the regex overflow stack trace below in
> case it's helpful. (This is beyond my debugging skills, so I'm just
> pasting in anything I've got now.)
>
> To be clear: all these problems happen when I use the latest Org
> development source. Using the Org in the current Emacs development
> tree (I'm on 30.0.50), there's no problem. The Emacs source doesn't
> have the commit I identified earlier as being where my problems
> started. I'm toggling between versions by commenting this on or off:
>
> (use-package org
> ;; :pin manual
> ;; :load-path "/usr/local/src/org-mode/lisp"
>
> Ihor and Bruno, might it help if we did a video call and shared screens
> to see problems live? My Lisp is limited but I'll help how I can.
>
>
> Thanks,
>
> Bill
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada
>
> Debugger entered--Lisp error: (error "Stack overflow in regexp
> matcher")
> re-search-forward("^[
> \11]*\\(\\\\begin{\\([a-zA-Z0-9\\*]+\\)\\(?:.\\|\n\\)+?\\\\end{\\2}\\)\\|\\([^$]\\|^\\)\\(\\$[^
> \11\15\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|\\([^$]\\|^\\)\\(\\(\\$\\([^
> \11\n,;.$][^$\n\15]*?\\(\n[^$\n\15]*?\\)\\{0,2\\}[^
> \11\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)\\|\\\\(\\(?:.\\|\n\\)*?\\\\)\\|\\\\\\[\\(?:.\\|\n\\)*?\\\\\\]\\|\\$\\$\\(?:.\\|\n\\)*?\\$\\$"
> nil t)
> org-do-latex-and-related(#<marker at 770 in work-diary.org>)
> font-lock-fontify-keywords-region(522 #<marker at 770 in
> work-diary.org> nil)
> font-lock-default-fontify-region(522 #<marker at 770 in
> work-diary.org> nil)
> font-lock-fontify-region(522 #<marker at 770 in work-diary.org>)
> #f(compiled-function (beg end) #<bytecode -0x356cca3983ed8d0>)(522
> #<marker at 770 in work-diary.org>)
> font-lock-ensure(522 #<marker at 770 in work-diary.org>)
> org-table-align()
> org-table-map-tables(org-table-align t)
> org-mode()
> set-auto-mode-0(org-mode nil)
> set-auto-mode--apply-alist((("\\.yml$" . yaml-mode)
> ("\\.\\(r\\(?:ng\\|ss\\)\\|s\\(?:ch\\|vg\\)\\|x\\(?:ml\\|s\\(?:d\\|lt\\)\\)\\)\\'"
> . nxml-mode) ("\\.[pP][dD][fF]\\'" . pdf-view-mode) ("README\\.md\\'" .
> gfm-mode)
> ("\\(?:\\(?:\\.\\(?:b\\(?:\\(?:abel\\|ower\\)rc\\)\\|json\\(?:ld\\)?\\)\\|composer\\.lock\\)\\'\\)"
> . json-mode) ("\\.hva\\'" . LaTeX-mode) ("\\.tsv\\'" . tsv-mode)
> ("\\.[Cc][Ss][Vv]\\'" . csv-mode) ("\\.[Ss][Aa][Ss]\\'" . SAS-mode)
> ("\\.Sout\\'" . S-transcript-mode) ("\\.[Ss]t\\'" . S-transcript-mode)
> ("\\.Rd\\'" . Rd-mode) ("DESCRIPTION\\'" . conf-colon-mode)
> ("/Makevars\\(\\.win\\)?\\'" . makefile-mode) ("\\.[Rr]out\\'" .
> ess-r-transcript-mode) ("CITATION\\'" . ess-r-mode) ("NAMESPACE\\'" .
> ess-r-mode) ("\\.[rR]profile\\'" . ess-r-mode) ("\\.[rR]\\'" .
> ess-r-mode) ("/R/.*\\.q\\'" . ess-r-mode) ("\\.[Jj][Aa][Gg]\\'" .
> ess-jags-mode) ("\\.[Bb][Mm][Dd]\\'" . ess-bugs-mode)
> ("\\.[Bb][Oo][Gg]\\'" . ess-bugs-mode) ("\\.[Bb][Uu][Gg]\\'" .
> ess-bugs-mode) ("/git-rebase-todo\\'" . git-rebase-mode)
> ("\\.\\(?:md\\|markdown\\|mkd\\|mdown\\|mkdn\\|mdwn\\)\\'" .
> markdown-mode) ("\\.\\(e?ya?\\|ra\\)ml\\'" . yaml-mode)
> ("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" .
> elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil
> jka-compr) ("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr)
> ("\\.lz\\'" nil jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" nil
> jka-compr) ("\\.Z\\'" nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode)
> ("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gemspec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Brew\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'"
> . ruby-mode) ("\\.re?st\\'" . rst-mode)
> ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . conf-mode) ("\\.py[iw]?\\'" .
> python-mode) ("\\.m\\'" . octave-maybe-mode) ("\\.less\\'" .
> less-css-mode) ("\\.scss\\'" . scss-mode) ("\\.cs\\'" . csharp-mode)
> ("\\.awk\\'" . awk-mode) ("\\.\\(u?lpc\\|pike\\|pmod\\(\\.in\\)?\\)\\'"
> . pike-mode) ("\\.idl\\'" . idl-mode) ("\\.java\\'" . java-mode) ...)
> nil nil)
> set-auto-mode()
> normal-mode(t)
> after-find-file(nil t)
> find-file-noselect-1(#<buffer work-diary.org>
> "~/york/shared/work-diaries/work-diary.org" nil nil
> "~/york/shared/work-diaries/work-diary-2023-2024.org" (10223630 66310))
>
> find-file-noselect("/home/wdenton/york/shared/work-diaries/work-diary.org")
> org-clock-load()
> run-hooks(change-major-mode-after-body-hook text-mode-hook
> outline-mode-hook org-mode-hook)
> apply(run-hooks change-major-mode-after-body-hook (text-mode-hook
> outline-mode-hook org-mode-hook))
> run-mode-hooks(org-mode-hook)
> org-mode()
> set-auto-mode-0(org-mode nil)
> set-auto-mode--apply-alist((("\\.yml$" . yaml-mode)
> ("\\.\\(r\\(?:ng\\|ss\\)\\|s\\(?:ch\\|vg\\)\\|x\\(?:ml\\|s\\(?:d\\|lt\\)\\)\\)\\'"
> . nxml-mode) ("\\.[pP][dD][fF]\\'" . pdf-view-mode) ("README\\.md\\'" .
> gfm-mode)
> ("\\(?:\\(?:\\.\\(?:b\\(?:\\(?:abel\\|ower\\)rc\\)\\|json\\(?:ld\\)?\\)\\|composer\\.lock\\)\\'\\)"
> . json-mode) ("\\.hva\\'" . LaTeX-mode) ("\\.tsv\\'" . tsv-mode)
> ("\\.[Cc][Ss][Vv]\\'" . csv-mode) ("\\.[Ss][Aa][Ss]\\'" . SAS-mode)
> ("\\.Sout\\'" . S-transcript-mode) ("\\.[Ss]t\\'" . S-transcript-mode)
> ("\\.Rd\\'" . Rd-mode) ("DESCRIPTION\\'" . conf-colon-mode)
> ("/Makevars\\(\\.win\\)?\\'" . makefile-mode) ("\\.[Rr]out\\'" .
> ess-r-transcript-mode) ("CITATION\\'" . ess-r-mode) ("NAMESPACE\\'" .
> ess-r-mode) ("\\.[rR]profile\\'" . ess-r-mode) ("\\.[rR]\\'" .
> ess-r-mode) ("/R/.*\\.q\\'" . ess-r-mode) ("\\.[Jj][Aa][Gg]\\'" .
> ess-jags-mode) ("\\.[Bb][Mm][Dd]\\'" . ess-bugs-mode)
> ("\\.[Bb][Oo][Gg]\\'" . ess-bugs-mode) ("\\.[Bb][Uu][Gg]\\'" .
> ess-bugs-mode) ("/git-rebase-todo\\'" . git-rebase-mode)
> ("\\.\\(?:md\\|markdown\\|mkd\\|mdown\\|mkdn\\|mdwn\\)\\'" .
> markdown-mode) ("\\.\\(e?ya?\\|ra\\)ml\\'" . yaml-mode)
> ("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" .
> elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil
> jka-compr) ("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr)
> ("\\.lz\\'" nil jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" nil
> jka-compr) ("\\.Z\\'" nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode)
> ("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gemspec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Brew\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'"
> . ruby-mode) ("\\.re?st\\'" . rst-mode)
> ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . conf-mode) ("\\.py[iw]?\\'" .
> python-mode) ("\\.m\\'" . octave-maybe-mode) ("\\.less\\'" .
> less-css-mode) ("\\.scss\\'" . scss-mode) ("\\.cs\\'" . csharp-mode)
> ("\\.awk\\'" . awk-mode) ("\\.\\(u?lpc\\|pike\\|pmod\\(\\.in\\)?\\)\\'"
> . pike-mode) ("\\.idl\\'" . idl-mode) ("\\.java\\'" . java-mode) ...)
> nil nil)
> set-auto-mode()
> normal-mode(t)
> after-find-file(nil nil)
> find-file-noselect-1(#<buffer init.org> "~/.emacs.d/init.org" :nowarn
> nil "~/.emacs.d/init.org" (9704630 66310))
> find-file-noselect("/home/wdenton/.emacs.d/init.org" :nowarn)
> desktop-restore-file-buffer("/home/wdenton/.emacs.d/init.org"
> "init.org" nil)
> desktop-create-buffer(208 "/home/wdenton/.emacs.d/init.org"
> "init.org" org-mode (font-lock-mode visual-line-mode
> prettify-symbols-mode corfu-mode anzu-mode yas-minor-mode
> undo-tree-mode git-gutter-mode wrap-region-mode flyspell-mode
> org-appear-mode org-superstar-mode mixed-pitch-mode org-indent-mode)
> 3969 (nil nil) nil nil ((tab-width . 8) (indent-tabs-mode)
> (buffer-display-time 26101 53586 2647 436000)
> (buffer-file-coding-system . utf-8-unix) (truncate-lines)) ((mark-ring
> nil)))
> eval-buffer(#<buffer *load*> nil
> "/home/wdenton/.emacs.d/.emacs.desktop" nil t) ; Reading at buffer
> position 6154
> load-with-code-conversion("/home/wdenton/.emacs.d/.emacs.desktop"
> "/home/wdenton/.emacs.d/.emacs.desktop" t t)
> load("/home/wdenton/.emacs.d/.emacs.desktop" t t t)
> desktop-read()
> #f(compiled-function () #<bytecode 0x16157c4861c754ea>)()
> run-hooks(after-init-hook delayed-warnings-hook)
> command-line()
> normal-top-level()
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 16 Mar 2024 18:56:18 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: William Denton <william@williamdenton.org>
> Cc: Bruno Cardoso <cardoso.bc@gmail.com>, Emacs Org mode mailing list
> <emacs-orgmode@gnu.org>
> Subject: Re: Things got very slow: profiler output
> Message-ID: <871q8ahup9.fsf@localhost>
> Content-Type: text/plain
>
> William Denton <william@williamdenton.org> writes:
>
>>> Then, what about the latest main?
>>
>> I tried it, and I'm sorry to say all the same problems keep happening.
>>
>> I tried the test you mentioned here:
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2024-03/msg00362.html
>>
>> I loaded up my big Org file and moved around a while. I got:
>>
>> Function Name Call Count Elapsed Time Average Time
>> org-fold-core--property-symbol-get-create 33325 0.0058796690 1.764...e-07
>>
>> I don't know if that's helpful.
>
> You are getting similar numbers with me.
> I suspect that your problem is different from Bruno's.
>
>> For me all this is triggered by my work-diary.org file, which has fair bit of fontification in it: headings, 1200 clock entries, links, and so on. It had a big clockable at the bottom, which gave me the "Stack overflow in regexp matcher" I mentioned last month:
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00347.html
>
> Did you try setting org-highlight-latex-and-related to nil?
>
>> Ihor and Bruno, might it help if we did a video call and shared screens to see problems live? My Lisp is limited but I'll help how I can.
>
> We may. Although I suspect that something peculiar in your Org file is
> making the Emacs regexp engine choke. I am wondering what happens when
> you try the default value of org-highlight-latex-and-related.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 16 Mar 2024 17:21:22 -0300
> From: Bruno Cardoso <cardoso.bc@gmail.com>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: William Denton <william@williamdenton.org>, Emacs Org mode mailing
> list <emacs-orgmode@gnu.org>
> Subject: Re: Things got very slow: profiler output
> Message-ID: <8734sqapx9.fsf@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> On 2024-03-16, 15:56 +0000, Ihor Radchenko <yantar92@posteo.net> wrote:
>
>> Ok.
>> Then, what about the latest main?
>
> Updated and tested again on Emacs -Q.
>
> org-fold-core--property-symbol-get-create 145790 0.5319647139
> 3.648...e-06
>
> GNU Emacs 29.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.40,
> cairo version 1.18.0)
> Org mode version 9.7-pre (release_9.6.21-1289-gae50b9)
>
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: 20240316_profiler-org.txt
> URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20240316/e153c630/attachment.txt>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 16 Mar 2024 21:14:33 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Bruno Cardoso <cardoso.bc@gmail.com>
> Cc: William Denton <william@williamdenton.org>, Emacs Org mode mailing
> list <emacs-orgmode@gnu.org>
> Subject: Re: Things got very slow: profiler output
> Message-ID: <87wmq1hoau.fsf@localhost>
> Content-Type: text/plain
>
> Bruno Cardoso <cardoso.bc@gmail.com> writes:
>
>> On 2024-03-16, 15:56 +0000, Ihor Radchenko <yantar92@posteo.net> wrote:
>>
>>> Ok.
>>> Then, what about the latest main?
>>
>> Updated and tested again on Emacs -Q.
>>
>> org-fold-core--property-symbol-get-create 145790 0.5319647139 3.648...e-06
>
> It is a few times faster. And the profiler shows no slowdown, AFAIU.
> Is the problem solved?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 16 Mar 2024 22:46:42 +0000
> From: "Rick Lupton" <mail@ricklupton.name>
> To: "Ihor Radchenko" <yantar92@posteo.net>
> Cc: "Y. E." <emacs-orgmode@gnu.org>
> Subject: Re: [PATCH] Allow external libraries (org-roam) to supply
> org-id locations
> Message-ID: <a123389c-8f86-4836-a4fe-1e3f4281d33b@app.fastmail.com>
> Content-Type: text/plain;charset=utf-8
>
> On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote:
>> I think that we can do it simpler. [...]
>> The idea is to use Emacs' advice machinery to allow third-party code
>> alter the functions stored in link parameters.
>
> I was avoiding this because I thought it was only recommended (in the
> elisp manual) to use advice directly by users, not in libraries (like,
> I assume, org-roam):
>
>> If you are writing code for release, for others to use, try to avoid including advice in it. If the function you want to advise has no hook to do the job, please talk with the Emacs developers about adding a suitable hook. Especially, Emacs’s own source files should not put advice on functions in Emacs. (There are currently a few exceptions to this convention, but we aim to correct them.) It is generally cleaner to create a new hook in foo, and make bar use the hook, than to have bar put advice in foo.
>
> (https://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Named-Functions.html)
>
> But I don't mind either way. I agree your approach is simpler if it's
> a reasonable way for a third party library like org-roam to extend the
> org id functions.
>
> Thanks,
> Rick
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 16 Mar 2024 23:24:07 +0000
> From: Leo Butler <Leo.Butler@umanitoba.ca>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: Org Mode List <emacs-orgmode@gnu.org>
> Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink
> Message-ID: <87sf0p69rd.fsf@t14.reltub.ca>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sat, Mar 16 2024, Leo Butler <Leo.Butler@umanitoba.ca> wrote:
>
>> On Fri, Mar 15 2024, Ihor Radchenko <yantar92@posteo.net> wrote:
>>
>>> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>>>
>>>>> Leo, may you improve the patch to avoid defining
>>>>> `org-beamer-frame-environment' when it is not used in all the frames?
>>>>
>>>> "all the" should be "any of" in that last sentence.
>>>
>>> Indeed.
>>>
>>>> How about the attached patch?
>>>> ...
>>>> +(defvar org-beamer--frame-environment-used nil
>>>> + "Nil unless `org-beamer-frame-environment' is used.
>>>> +See `org-beamer--frame-environment'.")
>>>
>>> I'd prefer to keep this information in the INFO channel.
>>> It will be more consistent.
>
> Apologies, I messed up the patch in the previous email.
>
> Attached is a patch that compiles cleanly and uses INFO.
>
> Leo
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch
> Type: text/x-diff
> Size: 2953 bytes
> Desc: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch
> URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20240316/43756cad/attachment.patch>
>
> ------------------------------
>
> Message: 9
> Date: Sun, 17 Mar 2024 10:29:37 +0800
> From: Wu Ming <wu.ming2@icloud.com>
> To: emacs-orgmode@gnu.org
> Subject: Re: Table column formula with remote reference
> Message-ID: <4D9A12E2-330B-412C-A770-629CB8DC3D1A@icloud.com>
> Content-Type: text/plain; charset=utf-8
>
>
>> On 14 Mar 2024, at 9:40 PM, Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>>
>> On Thursday, 14 Mar 2024 at 09:16, Wu Ming wrote:
>>> Unrelated, but appeared on the same trial, noticed a cell was
>>> mis-calculated. [...] This made me worry about reliability of simple
>>> biz calculations I am trying on Org spreadsheet for the first
>>> time. Please advise.
>>
>> I've not seen any problems with spreadsheet/table calculations in org and use it extensively. I don't use remote access generally however.
>>
>> In any case, one very nice feature of org tables is you can see exactly how and what it calculates when you ask it to. Turn on debugging by "C-c {" (org-table-toggle-formula-debugger) and you can see all the information you should need to identify what, if anything, is going wrong.
>>
>> Turn off debugging with the same key sequence.
>
> Thanks for the reference to formula debugger. In the heat of debugging
> an error as obvious, and worrying, as the one I saw forgot about it.
> Though I am still new to Emacs and Org so that’s not so surprising.
>
> I have one table retrieving data from two more. 18 columns x 7 rows
> total. I could have everything into one larger table but splitting
> makes them more readable I think. And possibly simplifies sharing end
> results. Haven’t tried Org export options yet. What is your
> organization system with tables?
>
>
> ------------------------------
>
> Message: 10
> Date: Sun, 17 Mar 2024 10:55:51 +0800
> From: Wu Ming <wu.ming2@icloud.com>
> To: emacs-orgmode@gnu.org
> Subject: Re: Table column formula with remote reference
> Message-ID: <0E2BEC9E-15B2-4FCB-9890-6BAD6B8B7546@icloud.com>
> Content-Type: text/plain; charset=utf-8
>
>
>> On 15 Mar 2024, at 2:58 AM, Ihor Radchenko <yantar92@posteo.net> wrote:
>>
>> Wu Ming <wu.ming2@icloud.com> writes:
>>
>>>> See "Remote references" subsection. It explains that in
>>>> remote(NAME,REF), REF is inside the remote table. Relative and current
>>>> column/row is ambiguous there.
>>>>
>>>> In contrast, @# and $# are special - they are replaced before
>>>> remote(...) is processed.
>>> ...
>>> I have some trouble at understanding your answer. Do you mean @# refers a row on the table where the formula belongs and @0 refers a row on the remote table? Was tempted to describe the former as “current” but remote table is also current when accessed. A better noun may be needed.
>>
>> Let me elaborate.
>>
>> When Org mode sees something like
>>
>> #+TBLFML: $1 = $2 + remote(A,@@#$1)
>>
>> 1. it goes to every cell in column 1 and remembers current column and
>> row numbers (original cell)
>>
>> 2. In the right side of the formula $2 + remote(A,@@#$1), Org replaces
>> all the instances of @# and $# with current column and row.
>> So, when we are calculating the value for @1$1, we get
>> $2 + remote(A,@1$1)
>>
>> 3. Org moves to table A and replaces remote(A,@1$1) with cell contents
>> of @1$1 inside table A. At this point, it is not allowed to have
>> relative references like $1 or $-1, because "current" column and row
>> are set inside remote table A - the original cell coordinates are not
>> available.
>>
>> 4. Org goes back to the original table, takes the updated formula
>> $2 + <remote value A@1$1>, and replaces relative reference $2
>> according to the current column - with the value stored in @1$2
>> column
>>
>> 5. Org passes the resulting expression <local value @1$2> + <remote
>> value A@1$1> to GNU cal and assigns the result as the value of the
>> current cell @1$1.
>>
>> 6. Repeat for @2..$1 cells.
>>
>> As you can see, @# and $# substitution always uses local cell
>> coordinates. Any other relative reference is not allowed inside
>> remote(...).
>>
>
> Very clear now. Thank you. But I was mostly confounded by references $0
> and #0 versus the @@# (and $$#) you just described the processing of.
> Don’t want to abuse your time. I can figure it out when needed. But if
> you feel inclined to unravel this little detail of the manual as well I
> would clearly appreciate the effort.
>
>>> This made me worry about reliability of simple biz calculations I am trying on Org spreadsheet for the first time. Please advise.
>>
>> Formula debugger is really helpful to understand the process.
>>
>>> Finally I moved columns but now column numbers in formulas don’t relate to column order on display. How to understand which column formula affect which column?
>>
>> Normally, if you use org-table-* commands, the formulas get updated when
>> you move the columns.
>
> One side effect of using remote formulas is re-organizing columns
> doesn’t update them automatically. I should find the balance of
> readability and formulas maintenance cost. But you may have suggested
> the solution below already with named columns.
>>
>> To make things more readable, you can also assign names to columns:
>>
>> | ! | | P1 | P2 | P3 | Tot | |
>> | | Maximum | 10 | 15 | 25 | 50 | 10.0 |
>>
>> Then, you can write $P1 = ... instead of $3 = ...
>> See "3.5.10 Advanced features" section of the manual.
>
> Clever. And we are at the “Advanced“ features already. Are
> advanced-advanced in the realm of Calc?
>
> Asking because was also wondering how to optimize parameters (“solver”)
> and deal with locales (“,” vs “.” separators). For the latter I could
> possibly ‘tr’ them before sharing the output. But will possibly mess
> the alignment. Happened while trialling groff’s tbl.
>
>
> ------------------------------
>
> Message: 11
> Date: Sun, 17 Mar 2024 07:13:08 +0100
> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Reproducible work with natively compiled Emacs
> Message-ID:
> <CAO48Bk88aV3ovpuouuDN3Bj=CgPSWddemmreKfcPFUq8HOpZiw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Ihor.
>
> In practice, I was not able to delete the .eln files from a make native.
>
> In order to have a more controlled environment, I delete them _before_
> I refresh my local org-mode/main directory, and then do a make native
> after refreshing my local copy.
>
> Same happened when testing modifications. When testing a modification
> I always make cleaneln; make native to test it
>
> Maybe I'm a bit too 'meticulous' but that's me ;-)
>
> Best, /PA
>
> On Sat, 16 Mar 2024 at 11:20, Ihor Radchenko <yantar92@posteo.net> wrote:
>
>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>>
>> >> Do I understand correctly that the reason you implemented cleaneln make
>> >> target is working around issues with make test/make repro?
>> >>
>> > Yes, that's one of the reasons. And, also because when I set
>> > native.comp-eln-cache-path,
>> > anything that is not part of the Emacs distribution gets compiled into
>> that
>> > directory. For example,
>> > the clone of org-mode main as well as the packages from
>> elpa/melpa/nungnu.
>>
>> Sorry, but I do not fully understand.
>> May you please explain in more details what kind of problems you
>> encountered in practice?
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>>
>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
> run
> a leader-deposed hook here, but we can't yet
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20240317/cd1e8e3b/attachment.htm>
>
> ------------------------------
>
> Message: 12
> Date: Sun, 17 Mar 2024 15:19:39 +0700
> From: Max Nikulin <manikulin@gmail.com>
> To: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Reproducible work with natively compiled Emacs
> Message-ID: <5d4a72db-8be5-472b-917b-a45d888a897d@gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 17/03/2024 13:13, Pedro Andres Aranda Gutierrez wrote:
>>
>> In practice, I was not able to delete the .eln files from a make native.
>>
>> In order to have a more controlled environment, I delete them _before_
>> I refresh my local org-mode/main directory, and then do a make native
>> after refreshing my local copy.
>>
>> Same happened when testing modifications. When testing a modification
>> I always make cleaneln; make native to test it
>
> In the past I read a couple of threads on native compilation on
> emacs-devel and maybe a couple of bug reports. My impression that the
> position of developers in response to requests to give more control on
> native compilation is "it should just work and users should not bother".
>
> Do you know a reproducible way leading to errors when .eln files are not
> removed?
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Sun, 17 Mar 2024 10:06:08 +0100
> From: Matt <matt@excalamus.com>
> To: "Ihor Radchenko" <yantar92@posteo.net>
> Cc: "emacs-orgmode" <emacs-orgmode@gnu.org>
> Subject: How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> Message-ID:
> <18e4ba944c6.1071dbb64659068.8617018692679870359@excalamus.com>
> Content-Type: text/plain; charset="UTF-8"
>
> ---- On Sat, 16 Mar 2024 11:11:38 +0100 Ihor Radchenko wrote ---
>
> > I notice that you changed the commit author and only referenced Aaron in
> > Submitted By: metadata.
> >
> > For future, we prefer keeping the original commit author in the "author"
> > field of the commits - this is important to keep track of the number of
> > changed lines for contributors without FSF copyright assignment.
>
> Thank you for letting me know this is an issue.
>
> First, would you like me to update the commit? If so, I will need
> guidance. The correct procedure to change the author after committing
> to remote is unclear to me. I would think it's something like sync my
> local copy with the latest remote version, update the author locally,
> and force push the change. I would then expect that the next time
> someone pulls, it would update their local with the author change. It
> would, however, cause a conflict, I think, for someone in the middle of
> making a change who has not synced with the forced push version and is
> trying to push their change.
>
> Second, I can update Worg with an explanation that it's important to
> credit authors using git's author field and how to do this. Unless I
> missed it, worg/org-contribute makes no mention of the author field.
> The version of git packaged by my distro is 2.41.0 and, AFAICT, has no
> -A flag for 'git' or 'git commit'. However, the following works on my
> machine and, I guess, is the long option form:
>
> git commit --author "Arthur Override <arthur-override's-email>"
>
> Third, this is at least the second time I've had issues working with a
> diff/patch. The reason I submitted the change the way I did is that I
> could not get 'git apply <the-change>' to work. I only got a useless
> error like "error: corrupt patch at line 10". It's not clear to me if
> this is an error on my end or if the patch is indeed ill-formatted.
> Can you confirm that the submitted patch is well-formatted?
>
> --
> Matt Trzcinski
> Emacs Org contributor (ob-shell)
> Learn more about Org mode at https://orgmode.org
> Support Org development at https://liberapay.com/org-mode
>
>
>
>
>
> ------------------------------
>
> Message: 14
> Date: Sun, 17 Mar 2024 12:35:46 +0330
> From: Rudi C <rudiwillalwaysloveyou@gmail.com>
> To: emacs-orgmode@gnu.org
> Subject: How do I link to a specific line in an org-babel block?
> Message-ID:
> <CAE9z9A3TBtczZ=1g+kDqx0djK_UBgQjMuTg_ri=dL84+qVCNFA@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> How do I link to a specific line in an org-babel block?
>
> I tried using [[file:.../my.org::search-term]] , but this only works for
> jumping to a heading, not an arbitrary line. (It does work for non-org
> files.)
>
> PS: Please use Reply to All.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20240317/609cb9b0/attachment.htm>
>
> ------------------------------
>
> Message: 15
> Date: Sun, 17 Mar 2024 09:53:54 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Leo Butler <Leo.Butler@umanitoba.ca>
> Cc: Org Mode List <emacs-orgmode@gnu.org>
> Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink
> Message-ID: <87r0g9yyj1.fsf@localhost>
> Content-Type: text/plain
>
> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>
>>>> I'd prefer to keep this information in the INFO channel.
>>>> It will be more consistent.
>>
>> Apologies, I messed up the patch in the previous email.
>>
>> Attached is a patch that compiles cleanly and uses INFO.
>
> Thanks!
>
>> + (frame (let ((selection
>> + (or (and fragilep
>> + (or (string-search "\\begin{frame}" contents)
>> + (string-search "\\end{frame}" contents))
>
> Please use `string-match-p'. `string-search' is not available in Emacs
> 27, which we still support.
>
>> + org-beamer-frame-environment)
>> + "frame")))
>> + (unless (string= selection "frame")
>> + (setq info (plist-put info :define-frame t)))
>
> Let's use "beamer" prefix to indicate that this plist entry is
> beamer backend-specific. Something like :beamer-define-frame.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 16
> Date: Sun, 17 Mar 2024 10:16:18 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Reproducible work with natively compiled Emacs
> Message-ID: <87msqxyxhp.fsf@localhost>
> Content-Type: text/plain
>
> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
>> In practice, I was not able to delete the .eln files from a make native.
>
> I am wondering why you wanted to run make native.
> When I added that target, it was mostly to test inconsistencies between
> make single and make native. However, AFAIU, there should be no
> inconsistencies in practice. So, maybe we can instead just delete make
> native target? Or is there any value in ahead of time native-compilation
> when working with Org git repo?
>
>> In order to have a more controlled environment, I delete them _before_
>> I refresh my local org-mode/main directory, and then do a make native
>> after refreshing my local copy.
>>
>> Same happened when testing modifications. When testing a modification
>> I always make cleaneln; make native to test it
>>
>> Maybe I'm a bit too 'meticulous' but that's me ;-)
>
> "more controlled environment" does not sound like a real concern caused
> by something breaking. I am joining Max's question on whether you
> encountered any real issue with native compilation.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 17
> Date: Sun, 17 Mar 2024 10:17:54 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Rick Lupton <mail@ricklupton.name>
> Cc: "Y. E." <emacs-orgmode@gnu.org>
> Subject: Re: [PATCH] Allow external libraries (org-roam) to supply
> org-id locations
> Message-ID: <87le6hyxf1.fsf@localhost>
> Content-Type: text/plain; charset=utf-8
>
> "Rick Lupton" <mail@ricklupton.name> writes:
>
>> On Wed, 13 Mar 2024, at 12:30 PM, Ihor Radchenko wrote:
>>> I think that we can do it simpler. [...]
>>> The idea is to use Emacs' advice machinery to allow third-party code
>>> alter the functions stored in link parameters.
>>
>> I was avoiding this because I thought it was only recommended (in the elisp manual) to use advice directly by users, not in libraries (like, I assume, org-roam):
>>
>>> If you are writing code for release, for others to use, try to avoid including advice in it. If the function you want to advise has no hook to do the job, please talk with the Emacs developers about adding a suitable hook. Especially, Emacs’s own source files should not put advice on functions in Emacs. (There are currently a few exceptions to this convention, but we aim to correct them.) It is generally cleaner to create a new hook in foo, and make bar use the hook, than to have bar put advice in foo.
>>
>> (https://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Named-Functions.html)
>
> This is absolutely right, but only when advising named functions. What
> we are talking about is advising the link property value. In my previous
> discussions with Emacs devs, I was told that it superior to use advice
> system when a library wants to modify a function stored as a value of a
> variable - see
> https://yhetil.org/emacs-devel/SJ0PR10MB548885B715C9875726F70F61F34FA@SJ0PR10MB5488.namprd10.prod.outlook.com/
>
>> But I don't mind either way. I agree your approach is simpler if it's a reasonable way for a third party library like org-roam to extend the org id functions.
>
> I added the setter on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d545ad606
>
> We may also want to document the `add-function' approach in the manual.
> Maybe in a new section "Modifying Hyperlink Types", right after "Adding
> Hyperlink Types".
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 18
> Date: Sun, 17 Mar 2024 11:30:45 +0100
> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Reproducible work with natively compiled Emacs
> Message-ID: <F8BEB7D3-7C9F-4CD2-A86E-48AC4F604F3D@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi
>
> Bluntly speaking, yes. There is this instance not too long ago where we
> had the slow down and I was trying to isolate the source. One of my
> possible suspects was that I might not have the right version of the
> eln file, because the creation timestamp was seeing with ls-l really
> made me doubt and I needed a state I could understand.
>
> Best,/PA
>
> Enviado desde mi iPhone
>
>> El 17 mar 2024, a las 11:16, Ihor Radchenko <yantar92@posteo.net> escribió:
>>
>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>>
>>> In practice, I was not able to delete the .eln files from a make native.
>>
>> I am wondering why you wanted to run make native.
>> When I added that target, it was mostly to test inconsistencies between
>> make single and make native. However, AFAIU, there should be no
>> inconsistencies in practice. So, maybe we can instead just delete make
>> native target? Or is there any value in ahead of time native-compilation
>> when working with Org git repo?
>>
>>> In order to have a more controlled environment, I delete them _before_
>>> I refresh my local org-mode/main directory, and then do a make native
>>> after refreshing my local copy.
>>>
>>> Same happened when testing modifications. When testing a modification
>>> I always make cleaneln; make native to test it
>>>
>>> Maybe I'm a bit too 'meticulous' but that's me ;-)
>>
>> "more controlled environment" does not sound like a real concern caused
>> by something breaking. I am joining Max's question on whether you
>> encountered any real issue with native compilation.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 19
> Date: Sun, 17 Mar 2024 10:31:00 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Matt <matt@excalamus.com>
> Cc: emacs-orgmode <emacs-orgmode@gnu.org>
> Subject: Re: How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> Message-ID: <87il1lywt7.fsf@localhost>
> Content-Type: text/plain
>
> Matt <matt@excalamus.com> writes:
>
>> > For future, we prefer keeping the original commit author in the "author"
>> > field of the commits - this is important to keep track of the number of
>> > changed lines for contributors without FSF copyright assignment.
>>
>> Thank you for letting me know this is an issue.
>>
>> First, would you like me to update the commit? If so, I will need guidance. The correct procedure to change the author after committing to remote is unclear to me. I would think it's something like sync my local copy with the latest remote version, update the author locally, and force push the change. I would then expect that the next time someone pulls, it would update their local with the author change. It would, however, cause a conflict, I think, for someone in the middle of making a change who has not synced with the forced push version and is trying to push their change.
>
> We should avoid force pushing unless something is terribly broken.
> What you may do instead is (1) revert the commit; (2) re-apply the
> commit version with the correct author attribution.
>
>> Second, I can update Worg with an explanation that it's important to credit authors using git's author field and how to do this. Unless I missed it, worg/org-contribute makes no mention of the author field. The version of git packaged by my distro is 2.41.0 and, AFAICT, has no -A flag for 'git' or 'git commit'. However, the following works on my machine and, I guess, is the long option form:
>>
>> git commit --author "Arthur Override <arthur-override's-email>"
>
> You are right. Looks like -A is just Magit shortcut.
>
> As for crediting authors, we may document it in
> https://orgmode.org/worg/org-maintenance.html#copyright
> Although, it is under "core maintainer" section. Maybe we can make a
> dedicated section for maintainers on how to deal with patch submissions.
>
>> Third, this is at least the second time I've had issues working with a diff/patch. The reason I submitted the change the way I did is that I could not get 'git apply <the-change>' to work. I only got a useless error like "error: corrupt patch at line 10". It's not clear to me if this is an error on my end or if the patch is indeed ill-formatted. Can you confirm that the submitted patch is well-formatted?
>
> There are several types of patches that may need to be applied
> differently. Plain "diff" patches can be applied using git apply, while
> maildir/.patch patches can be applied using git am.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 20
> Date: Sun, 17 Mar 2024 12:28:58 +0000
> From: Gerard Vermeulen <gerard.vermeulen@posteo.net>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: Damien Cassou <damien@cassou.me>, emacs-orgmode@gnu.org
> Subject: Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing
> non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]
> Message-ID: <36ffb8b8c967b1adea9ead9a0fa35f4a@posteo.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>
>
> On 16.03.2024 12:48, Ihor Radchenko wrote:
>
>> Yes. You can add
>>
>> #+property: header-args:text :eval no
>>
>> on top of your Org file or add
>>
>> (setq org-babel-default-header-args:text '((:eval . "no")))
>>
>> to your config.
>
> Is it possible to make org-lint recognize those settings?
>
> I have the kludge
>
> (defun org-babel-execute:text (_body _params)
> "NO-OP to silence warnings." nil)
>
> in my config to silence "Unknown source block language" warnings.
>
> Regards -- Gerard
>
>
>
>
> ------------------------------
>
> Message: 21
> Date: Sun, 17 Mar 2024 10:02:49 -0300
> From: Bruno Cardoso <cardoso.bc@gmail.com>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: William Denton <william@williamdenton.org>, Emacs Org mode mailing
> list <emacs-orgmode@gnu.org>
> Subject: Re: Things got very slow: profiler output
> Message-ID: <871q89nh8m.fsf@gmail.com>
> Content-Type: text/plain
>
>
>
> On 2024-03-16, 21:14 +0000, Ihor Radchenko <yantar92@posteo.net> wrote:
>>
>> It is a few times faster. And the profiler shows no slowdown, AFAIU.
>> Is the problem solved?
>>
>
> Hi Ihor. I accidentally cut out part of my last reply, sorry.
>
> Yes, it looks like the situation greatly improved on latest main. I
> guess the problem is solved on my side. Thank you very much!
>
> Best,
>
> Bruno.
>
>
>
>
> ------------------------------
>
> Message: 22
> Date: Sun, 17 Mar 2024 13:17:39 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Rudi C <rudiwillalwaysloveyou@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: How do I link to a specific line in an org-babel block?
> Message-ID: <87frwpyp3g.fsf@localhost>
> Content-Type: text/plain
>
> Rudi C <rudiwillalwaysloveyou@gmail.com> writes:
>
>> How do I link to a specific line in an org-babel block?
>
> a.org:
>
> #+begin_src emacs-lisp
> (message "Hello world!")
> (message "Hello other worlds!!!") ; (ref:greetworlds)
> #+end_src
>
> b:org
> [[./a.org::(greetworlds)]]
>
> See https://orgmode.org/manual/Literal-Examples.html
>
>> I tried using [[file:.../my.org::search-term]] , but this only works for
>> jumping to a heading, not an arbitrary line. (It does work for non-org
>> files.)
>
> That's because "search-term" is used for fuzzy search, which is limited
> to headings by default. You can customize
> `org-link-search-must-match-exact-headline' to change this.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 23
> Date: Sun, 17 Mar 2024 13:18:12 +0000
> From: Leo Butler <Leo.Butler@umanitoba.ca>
> To: Ihor Radchenko <yantar92@posteo.net>
> Cc: Org Mode List <emacs-orgmode@gnu.org>
> Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink
> Message-ID: <87cyrt3sks.fsf@t14.reltub.ca>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sun, Mar 17 2024, Ihor Radchenko <yantar92@posteo.net> wrote:
>
>> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>>
>>>>> I'd prefer to keep this information in the INFO channel.
>>>>> It will be more consistent.
>>>
>>> Apologies, I messed up the patch in the previous email.
>>>
>>> Attached is a patch that compiles cleanly and uses INFO.
>>
>> Thanks!
>>
>>> + (frame (let ((selection
>>> + (or (and fragilep
>>> + (or (string-search "\\begin{frame}" contents)
>>> + (string-search "\\end{frame}" contents))
>>
>> Please use `string-match-p'. `string-search' is not available in Emacs
>> 27, which we still support.
>
> Done.
>
>>
>>> + org-beamer-frame-environment)
>>> + "frame")))
>>> + (unless (string= selection "frame")
>>> + (setq info (plist-put info :define-frame t)))
>>
>> Let's use "beamer" prefix to indicate that this plist entry is
>> beamer backend-specific. Something like :beamer-define-frame.
>
> Done.
>
> Attached is the updated patch. In addition, I have written three
> regression tests that are attached in a separate patch.
>
> Leo
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch
> Type: text/x-diff
> Size: 2991 bytes
> Desc: 0001-lisp-ox-beamer.el-constrain-use-of-org-beamer-frame-.patch
> URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20240317/ece00220/attachment.patch>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0002-testing-lisp-test-ox-beamer.el-New-regression-tests-.patch
> Type: text/x-diff
> Size: 4841 bytes
> Desc: 0002-testing-lisp-test-ox-beamer.el-New-regression-tests-.patch
> URL:
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20240317/ece00220/attachment-0001.patch>
>
> ------------------------------
>
> Message: 24
> Date: Sun, 17 Mar 2024 14:42:29 +0100
> From: Matt <matt@excalamus.com>
> To: "Ihor Radchenko" <yantar92@posteo.net>
> Cc: "emacs-orgmode" <emacs-orgmode@gnu.org>
> Subject: Re: How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> Message-ID:
> <18e4ca6475b.dcb5ca35676861.167671948872676263@excalamus.com>
> Content-Type: text/plain; charset="UTF-8"
>
>
> ---- On Sun, 17 Mar 2024 11:31:00 +0100 Ihor Radchenko wrote ---
> > Matt matt@excalamus.com> writes:
> >
> > > First, would you like me to update the commit? If so, I will need
> guidance. The correct procedure to change the author after committing
> to remote is unclear to me. I would think it's something like sync my
> local copy with the latest remote version, update the author locally,
> and force push the change. I would then expect that the next time
> someone pulls, it would update their local with the author change. It
> would, however, cause a conflict, I think, for someone in the middle of
> making a change who has not synced with the forced push version and is
> trying to push their change.
> >
> > We should avoid force pushing unless something is terribly broken.
> > What you may do instead is (1) revert the commit; (2) re-apply the
> > commit version with the correct author attribution.
>
> Done.
>
> For the benefit of future me or anyone else who cares, I did:
>
> 1. git revert <hash-for-specific-commit-needing-modification>
> 2. make changes (e.g. emacs <file-needing-modification> followed by
> *type-type-type* or some incantation of 'git apply' or 'git am')
> 3. git commit --author "Arthur Author <arthur-author's-email>"
> 4. git push
>
> 'git revert', in this case, basically swaps the plus and minus signs in
> the diff for the specified commit and submits that as a new set of
> changes. After applying those changes, it's possible, in this case, to
> proceed with "what you should have done in the first place".
>
> > > Second, I can update Worg with an explanation that it's important
> to credit authors using git's author field and how to do this. Unless
> I missed it, worg/org-contribute makes no mention of the author field.
> The version of git packaged by my distro is 2.41.0 and, AFAICT, has no
> -A flag for 'git' or 'git commit'. However, the following works on my
> machine and, I guess, is the long option form:
> > >
> > > git commit --author "Arthur Override "
> >
> > You are right. Looks like -A is just Magit shortcut.
> >
> > As for crediting authors, we may document it in
> https://orgmode.org/worg/org-maintenance.html#copyright
> > Although, it is under "core maintainer" section. Maybe we can make a
> > dedicated section for maintainers on how to deal with patch
> submissions.
>
> I added a little section within copyright:
> https://git.sr.ht/~bzg/worg/commit/80152bee771b755aedfbe488497c5e4d0e7457c2
>
> --
> Matt Trzcinski
> Emacs Org contributor (ob-shell)
> Learn more about Org mode at https://orgmode.org
> Support Org development at https://liberapay.com/org-mode
>
>
>
>
>
> ------------------------------
>
> Message: 25
> Date: Sun, 17 Mar 2024 14:03:52 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Wu Ming <wu.ming2@icloud.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Table column formula with remote reference
> Message-ID: <87bk7dymyf.fsf@localhost>
> Content-Type: text/plain; charset=utf-8
>
> Wu Ming <wu.ming2@icloud.com> writes:
>
>> Very clear now. Thank you. But I was mostly confounded by references
>> $0 and #0 versus the @@# (and $$#) you just described the processing
>> of. Don’t want to abuse your time. I can figure it out when needed.
>> But if you feel inclined to unravel this little detail of the manual
>> as well I would clearly appreciate the effort.
>
> The main difference is that @# always refer to the original table, while
> $0 may refer to other tables as well.
>
> (Generally, reference expansion process is not well documented,
> unfortunately; it would be nice if somebody wrote a documentation
> explaining the process - things can get tricky in some edge cases)
>
>>> Normally, if you use org-table-* commands, the formulas get updated when
>>> you move the columns.
>>
>> One side effect of using remote formulas is re-organizing columns doesn’t update them automatically. I should find the balance of readability and formulas maintenance cost. But you may have suggested the solution below already with named columns.
>
> In theory, we might try to update such remote references at least in
> current buffer. Contributions welcome.
>
>>> To make things more readable, you can also assign names to columns:
>>>
>>> | ! | | P1 | P2 | P3 | Tot | |
>>> | | Maximum | 10 | 15 | 25 | 50 | 10.0 |
>>>
>>> Then, you can write $P1 = ... instead of $3 = ...
>>> See "3.5.10 Advanced features" section of the manual.
>>
>> Clever. And we are at the “Advanced“ features already. Are advanced-advanced in the realm of Calc?
>
>> Asking because was also wondering how to optimize parameters (“solver”) and deal with locales (“,” vs “.” separators). For the latter I could possibly ‘tr’ them before sharing the output. But will possibly mess the alignment. Happened while trialling groff’s tbl.
>
> AFAIK, GNU calc does not support comma as decimal point as _input_. For
> output, I am not sure.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 26
> Date: Sun, 17 Mar 2024 14:19:34 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Bruno Cardoso <cardoso.bc@gmail.com>
> Cc: William Denton <william@williamdenton.org>, Emacs Org mode mailing
> list <emacs-orgmode@gnu.org>
> Subject: Re: Things got very slow: profiler output
> Message-ID: <878r2hym89.fsf@localhost>
> Content-Type: text/plain
>
> Bruno Cardoso <cardoso.bc@gmail.com> writes:
>
>>> It is a few times faster. And the profiler shows no slowdown, AFAIU.
>>> Is the problem solved?
>>>
>>
>> Hi Ihor. I accidentally cut out part of my last reply, sorry.
>>
>> Yes, it looks like the situation greatly improved on latest main. I guess the problem is solved on my side. Thank you very much!
>
> Good to hear.
> Then, back to William's problem :)
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 27
> Date: Sun, 17 Mar 2024 14:26:51 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Reproducible work with natively compiled Emacs
> Message-ID: <875xxlylw4.fsf@localhost>
> Content-Type: text/plain
>
> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
>> Bluntly speaking, yes. There is this instance not too long ago where we had the slow down and I was trying to isolate the source. One of my possible suspects was that I might not have the right version of the eln file, because the creation timestamp was seeing with ls-l really made me doubt and I needed a state I could understand.
>
> Many things could cause it. For example, I sometimes get very bad
> slowdowns unless I do make bootstrap on my Emacs master build.
>
> I conclude that cleaning .eln files, especially outside the Org git repo
> folder, is not something we need. (until there is an evidence that we do
> need such a cleanup)
>
> I think that we can still keep make native exclusively for the purposes
> of testing native compilation in case if it behaves funnily.
>
> Canceled.
> I only committed the changes to make help output.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=67a8117ca
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 28
> Date: Sun, 17 Mar 2024 14:30:01 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Gerard Vermeulen <gerard.vermeulen@posteo.net>
> Cc: Damien Cassou <damien@cassou.me>, emacs-orgmode@gnu.org
> Subject: Re: [BUG] [PATCH] org-babel-execute-buffer: Prevent executing
> non-code blocks [9.6.20 ( @ /home/cassou/.emacs.d/lib/org/lisp/)]
> Message-ID: <8734spylqu.fsf@localhost>
> Content-Type: text/plain
>
> Gerard Vermeulen <gerard.vermeulen@posteo.net> writes:
>
>>> (setq org-babel-default-header-args:text '((:eval . "no")))
>>>
>>> to your config.
>>
>> Is it possible to make org-lint recognize those settings?
>>
>> I have the kludge
>>
>> (defun org-babel-execute:text (_body _params)
>> "NO-OP to silence warnings." nil)
>>
>> in my config to silence "Unknown source block language" warnings.
>
> You can hide all the warnings from a certain checker by pressing "i" in
> the org-lint report.
>
> If necessary, we may add some customizations to org-lint that will allow
> customizing which checkers to use.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 29
> Date: Sun, 17 Mar 2024 14:36:53 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Leo Butler <Leo.Butler@umanitoba.ca>
> Cc: Org Mode List <emacs-orgmode@gnu.org>
> Subject: Re: [BUG] Re: The orgframe construct in the Beamer exporter
> as a default needs a rethink
> Message-ID: <87zfuwylfe.fsf@localhost>
> Content-Type: text/plain
>
> Leo Butler <Leo.Butler@umanitoba.ca> writes:
>
>> Attached is the updated patch. In addition, I have written three
>> regression tests that are attached in a separate patch.
>
> Thanks!
> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=80615195c
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=46909a54e
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> ------------------------------
>
> Message: 30
> Date: Sun, 17 Mar 2024 14:38:29 +0000
> From: Ihor Radchenko <yantar92@posteo.net>
> To: Matt <matt@excalamus.com>
> Cc: emacs-orgmode <emacs-orgmode@gnu.org>
> Subject: Re: How to properly attribute authorship with Git (was Re:
> [PATCH] lisp/ob-shell.el: Also override explicit-shell-file-name)
> Message-ID: <87wmq0ylcq.fsf@localhost>
> Content-Type: text/plain
>
> Matt <matt@excalamus.com> writes:
>
>> > We should avoid force pushing unless something is terribly broken.
>> > What you may do instead is (1) revert the commit; (2) re-apply the
>> > commit version with the correct author attribution.
>>
>> Done.
>> ...
>> I added a little section within copyright: https://git.sr.ht/~bzg/worg/commit/80152bee771b755aedfbe488497c5e4d0e7457c2
>
> Thanks!
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
>
> End of Emacs-orgmode Digest, Vol 217, Issue 20
> **********************************************
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2024-03-19 4:01 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.49.1710691207.14853.emacs-orgmode@gnu.org>
2024-03-19 4:00 ` Emacs-orgmode Digest, Vol 217, Issue 20 pessoa
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).