[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs-orgmode Digest, Vol 217, Issue 20
|
From: |
pessoa |
|
Subject: |
Re: Emacs-orgmode Digest, Vol 217, Issue 20 |
|
Date: |
Tue, 19 Mar 2024 12:00:25 +0800 |
|
User-agent: |
Cyrus-JMAP/3.11.0-alpha0-300-gdee1775a43-fm-20240315.001-gdee1775a |
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
> **********************************************
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Emacs-orgmode Digest, Vol 217, Issue 20,
pessoa <=