On Mon, Mar 18, 2024, at 12:00 AM, emacs-orgmode-requ...@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-requ...@gnu.org > > You can reach the person managing the list at > emacs-orgmode-ow...@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 <rudiwillalwayslove...@gmail.com> > To: Ihor Radchenko <yanta...@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+6cs5xol1kqyru3r...@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 <yanta...@posteo.net> wrote: > >> Rudi C <rudiwillalwayslove...@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 <dam...@cassou.me> > To: Ihor Radchenko <yanta...@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....@cassou.me> > Content-Type: text/plain > > Ihor Radchenko <yanta...@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 <will...@williamdenton.org> > To: Ihor Radchenko <yanta...@posteo.net> > Cc: Bruno Cardoso <cardoso...@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 > <yanta...@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 <yanta...@posteo.net> > To: William Denton <will...@williamdenton.org> > Cc: Bruno Cardoso <cardoso...@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 <will...@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...@gmail.com> > To: Ihor Radchenko <yanta...@posteo.net> > Cc: William Denton <will...@williamdenton.org>, Emacs Org mode mailing > list <emacs-orgmode@gnu.org> > Subject: Re: Things got very slow: profiler output > Message-ID: <8734sqapx9....@gmail.com> > Content-Type: text/plain; charset="utf-8" > > > On 2024-03-16, 15:56 +0000, Ihor Radchenko <yanta...@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 <yanta...@posteo.net> > To: Bruno Cardoso <cardoso...@gmail.com> > Cc: William Denton <will...@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...@gmail.com> writes: > >> On 2024-03-16, 15:56 +0000, Ihor Radchenko <yanta...@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" <m...@ricklupton.name> > To: "Ihor Radchenko" <yanta...@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-1e3f4281d...@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.but...@umanitoba.ca> > To: Ihor Radchenko <yanta...@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....@t14.reltub.ca> > Content-Type: text/plain; charset="iso-8859-1" > > On Sat, Mar 16 2024, Leo Butler <leo.but...@umanitoba.ca> wrote: > >> On Fri, Mar 15 2024, Ihor Radchenko <yanta...@posteo.net> wrote: >> >>> Leo Butler <leo.but...@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.mi...@icloud.com> > To: emacs-orgmode@gnu.org > Subject: Re: Table column formula with remote reference > Message-ID: <4d9a12e2-330b-412c-a770-629cb8dc3...@icloud.com> > Content-Type: text/plain; charset=utf-8 > > >> On 14 Mar 2024, at 9:40 PM, Fraga, Eric <e.fr...@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.mi...@icloud.com> > To: emacs-orgmode@gnu.org > Subject: Re: Table column formula with remote reference > Message-ID: <0e2bec9e-15b2-4fcb-9890-6bad6b8b7...@icloud.com> > Content-Type: text/plain; charset=utf-8 > > >> On 15 Mar 2024, at 2:58 AM, Ihor Radchenko <yanta...@posteo.net> wrote: >> >> Wu Ming <wu.mi...@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 <paag...@gmail.com> > To: Ihor Radchenko <yanta...@posteo.net> > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: > <CAO48Bk88aV3ovpuouuDN3Bj=cgpswddemmrekfcpfuq8hop...@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 <yanta...@posteo.net> wrote: > >> Pedro Andres Aranda Gutierrez <paag...@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 <maniku...@gmail.com> > To: Pedro Andres Aranda Gutierrez <paag...@gmail.com> > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: <5d4a72db-8be5-472b-917b-a45d888a8...@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 <m...@excalamus.com> > To: "Ihor Radchenko" <yanta...@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.8617018692679870...@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 <rudiwillalwayslove...@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+qvc...@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 <yanta...@posteo.net> > To: Leo Butler <leo.but...@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.but...@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 <yanta...@posteo.net> > To: Pedro Andres Aranda Gutierrez <paag...@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 <paag...@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 <yanta...@posteo.net> > To: Rick Lupton <m...@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" <m...@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/sj0pr10mb548885b715c9875726f70f61f3...@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 <paag...@gmail.com> > To: Ihor Radchenko <yanta...@posteo.net> > Cc: emacs-orgmode@gnu.org > Subject: Re: Reproducible work with natively compiled Emacs > Message-ID: <f8beb7d3-7c9f-4cd2-a86e-48ac4f604...@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 <yanta...@posteo.net> escribió: >> >> Pedro Andres Aranda Gutierrez <paag...@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 <yanta...@posteo.net> > To: Matt <m...@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 <m...@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.vermeu...@posteo.net> > To: Ihor Radchenko <yanta...@posteo.net> > Cc: Damien Cassou <dam...@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: <36ffb8b8c967b1adea9ead9a0fa35...@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...@gmail.com> > To: Ihor Radchenko <yanta...@posteo.net> > Cc: William Denton <will...@williamdenton.org>, Emacs Org mode mailing > list <emacs-orgmode@gnu.org> > Subject: Re: Things got very slow: profiler output > Message-ID: <871q89nh8m....@gmail.com> > Content-Type: text/plain > > > > On 2024-03-16, 21:14 +0000, Ihor Radchenko <yanta...@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 <yanta...@posteo.net> > To: Rudi C <rudiwillalwayslove...@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 <rudiwillalwayslove...@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.but...@umanitoba.ca> > To: Ihor Radchenko <yanta...@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....@t14.reltub.ca> > Content-Type: text/plain; charset="iso-8859-1" > > On Sun, Mar 17 2024, Ihor Radchenko <yanta...@posteo.net> wrote: > >> Leo Butler <leo.but...@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 <m...@excalamus.com> > To: "Ihor Radchenko" <yanta...@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.167671948872676...@excalamus.com> > Content-Type: text/plain; charset="UTF-8" > > > ---- On Sun, 17 Mar 2024 11:31:00 +0100 Ihor Radchenko wrote --- > > Matt m...@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 <yanta...@posteo.net> > To: Wu Ming <wu.mi...@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.mi...@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 <yanta...@posteo.net> > To: Bruno Cardoso <cardoso...@gmail.com> > Cc: William Denton <will...@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...@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 <yanta...@posteo.net> > To: Pedro Andres Aranda Gutierrez <paag...@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 <paag...@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 <yanta...@posteo.net> > To: Gerard Vermeulen <gerard.vermeu...@posteo.net> > Cc: Damien Cassou <dam...@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.vermeu...@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 <yanta...@posteo.net> > To: Leo Butler <leo.but...@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.but...@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 <yanta...@posteo.net> > To: Matt <m...@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 <m...@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 > **********************************************