Re: PATCH allow explicit style= in #+cite_export: biblatex
Pedro Andres Aranda Gutierrez writes: > Oops, you are right. My local copy got a bit messed up. > > Here is a hopefully clean patch. I have tried it out on a local test-patch > branch of current main and it applied. Thanks! May you also add NEWS entry? Also, a few comments inline. > Subject: [PATCH] Allow biblatex package options natively Please, prefix the first line with oc-biblatex library name. > lisp/oc-biblatex.el: detect and allow biblatex package options > in key=val,key=val,... format.
Re: [PATCH] ob-lua: Support all types and multiple values in results
Rudolf Adamkovič writes:
> P.S. #1
>
> We still have an old bug where
>
> src_lua{return string.match("A {B} C", "%b{}")}
>
> is misjudged to be a table:
>
> org-babel-insert-result: Inline error: list result cannot be used
May you create a test for this with expected failure?
> P.S. #2
>
> I did not update any session-related code.
>
> Currently,
>
> #+BEGIN_SRC lua :session x
> print 1
> #+END_SRC
>
> gives
>
> ... Sessions currently not supported, work in progress
>
> This is also documented in the header
>
> ;; Requirements:
> ;; for session support, lua-mode is needed.
> ;; [...]
> ;; However, sessions are not yet working.
>
> This half-finished session support should be removed, IMHO.
+1
--
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>
Re: [PATCH] ob-lua: Support all types and multiple values in results
Rudolf Adamkovič writes: > * etc/ORG-NEWS > (New and changed options): Describe the new option > 'org-babel-lua-multiple-values-separator'. > (New features): Describe the main change, as per the title of this > commit message. Thanks! Applied, onto main, after removing redundant :version keyword from defcustom. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=252cc0be0 -- 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>
Re: FAILED test-ob-shell/bash-uses-assoc-arrays
Max Nikulin writes: > On 15/04/2024 23:46, Alexander Adolf wrote: >> FAILED test-ob-shell/bash-uses-assoc-arrays ((should (equal "two" >> (org-trim (org-babel-execute-src-block :form (equal "two" "three") >> :value nil :explanation (arrays-of-different-length 3 5 "two" "three" >> first-mismatch-at 1)) >> FAILED test-ob-shell/bash-uses-assoc-arrays-with-lists ((should >> (equal "20 cm" (org-trim (org-babel-execute-src-block :form (equal >> "20 cm" "50 dl") :value nil :explanation (array-elt 0 (different-atoms >> (50 "#x32" "?2") (53 "#x35" "?5" > > My guess is that GPLv2 BASH on macOS does not support associative > arrays. Perhaps these tests should be skipped if BASH_VERSION is not > fresh enough (not supplied by Apple). I guess so. Which bash versions should we cut off? -- 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>
Re: [PATCH] Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline
Max Nikulin writes: >> +shell-file-name > ... >> +(list shell-command-switch >> + (concat (file-local-name script-file) " " >> cmdline > > Using `shell-command-switch' unconditionally may lead to executing > /bin/sh instead of shell specified by `shell-file-name' for script files > having no shebang, see > > https://superuser.com/questions/502984/writing-shell-scripts-that-will-run-on-any-shell-using-multiple-shebang-lines Good point. > I believe, multiple arguments should be specified as '(1 a "b c"). Yes, but we do not, in general, know how to split them. > With shebang (as header arg or as part of the body) command should be > /path/to/script [ARGUMENT]... > when there is no shebang > /shell/executable /path/to/script [ARGUMENT]... Maybe instead of `process-file' we can simply use `shell-command'? -- 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>
Re: [BUG] Exporting to text fails when there are broken links
Pablo Aguado writes:
> #+NAME: source-broken-links-mark
> #+begin_src org
> ,#+OPTIONS: broken-links:mark
>
> ,* Some title
>
> ...
> 5. This [[{filename}test-nonexistent-file.org][link5]] is NOT exported
> correctly to text.
> #+end_src
>
> #+begin_src elisp :results output
> (org-src-to-text "source-broken-links-mark")
> #+end_src
>
> #+RESULTS:
> : [BROKEN LINK: {filename}test-nonexistent-file.org]
>
>
> NOTE THAT ONLY THE BROKEN LINK IS SHOWN HERE! BUT NOT THE REST OF THE TEXT.
Thanks for reporting!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d6353b283
--
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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Alexander Adolf writes: >>> + (let ((search (org-link-heading-search-string >>> raw))) >>> +(org-link-make-string >>> + (if (not (buffer-file-name)) search >>> + (format "file:%s::%s" (buffer-file-name) >>> search)) >>> + cleaned)) >> >> This will unconditionally generate file: links, even when the dynamic >> block only refers to headings in the same buffer. The clock tables do >> use internal links when appropriate (see `org-clock-get-table-data'). > > Um, actually it does exactly the same as `org-clock-get-table-data' > (from where I borrowed the code snippet): it generates file: links in > buffers visiting files, and local links in buffers not visiting any > file. > > Perhaps you were looking at a test case in which > `org-clock-get-table-data' gets called in an Org buffer that is not > visiting any file? Nope. I was writing a test case (the one I shared) and noticed that file: links are generated. Then, I misread what org-clock does. You don't need to do anything other than adjusting the test example I shared to use file: links. >> If you can, please add some more tests like mine checking >> `org-columns--clean-item'. >> [...] > > Thanks for the springboard hint to get started with adding tests, which > I'm happy to do, of course. > > Is there any way for me to run a specific subset of the tests only, for > instance "make test colview", or similar? make test BTEST_RE="test-org-colview/dblock" # the same, but do not re-compile Org mode make test-dirty BTEST_RE="test-org-colview/dblock" -- 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>
Re: Is there a way to set options *programatically* ?
Emmanuel Charpentier writes:
> I'd like to create a function able to set some options, namely
>
> - `#+options: tex:`{t|dvipng|imagemagick}
>
> - `#+export-file-name:`
>
> I have been unable to find a *documented* way to do that from `elacs-lisp`.
>
> I *think* that an `org` source block could place those options in the buffer,
> but I can't find a way to reliably trigger a "setup refreshment" of these
> options from `emacs-lisp`.
>
> Any ideas ?
You can set `org-export-with-latex' variable value - it is a counterpart
of tex: option. See 13.2 Export Settings section of the manual.
--
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>
Re: Can we add PLOT to org-element-multiple-keywords?
Jeff Trull writes: > I notice that multiple #+PLOT lines before a table will be coalesced and > handled as one. However, this is > accomplished through specific code in org-plot.el that does a reverse > search through the buffer for > additional lines. org-element has a built-in mechanism for this, > org-element-multiple-keywords. It seems > like it would be useful to add PLOT to it. Can that be done? If not, is > there a way to temporarily add it for > an exporter (i.e. after the export is launched but before the buffer is > parsed)? Yes, it can be done. However, in addition to changing the parser, we should also make use of the change in org-plot itself. I tried to do this, and noticed that `org-plot/gnuplot' promises to parse #+TABLE options _after_ the table as well. Affiliated keywords are of no help then. Further, I reviewed the two calls to `org-plot/collect-options' in org-table.el and noticed that the second call is no longer doing the right thing of scanning #+PLOT lines after the table - since commit ac3148ef8 (by Timothy): org-plot: Don't move point when plotting * lisp/org-plot.el (org-plot/gnuplot): Expanding the `save-excursion' block to include `org-plot/goto-nearest-table` prevents the current point from being moved, and doesn't affect the rest of the function. Timothy, may you please take a look? We may drop support for the #+PLOT lines after the table - they are not really documented in our manual. Though it will technically be a breaking change, so I am not 100% 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>
Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere
Max Nikulin writes: > There should be a way to align tags for a specific heading even when > `org-auto-align-tags' is nil. > >> - (org-align-tags) >> + (when org-auto-align-tags (org-align-tags)) I can convert org-align-tags into a command. > Instead of repetitive changes I would consider either checking > `org-auto-align-tags' inside `org-align-tags' or introducing a macro. It will not do much good: 1. If we check inside `org-align-tags', it will be a breaking API change and the command name will no longer be intuitive. 2. If we introduce a macro/function, it will be something like (org-align-tags-maybe) - not much different from (when org-auto-align-tags (org-align-tags)) -- 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>
Re: `org-emphasize' missing in the manual
Arash Esbati writes: > Thanks for your response. I'm not really familiar with Org development, > but I hope the attached change fits the bill. Please feel free to > adjust when necessary. Thanks! Applied, onto main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ff9d00c9c -- 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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Alexander Adolf writes: > Ihor Radchenko writes: > >> [...] >> Calling `org-columns--clean-item' is a must to create a valid table. > > True. > > Additionally, it would seem advisable to call `org-quote-vert' on the > data, too, as `org-columns--clean-item' does not take care of vertical > bars? This is done in a previous step in `org-columns--capture-view', > however, so that the vertical bars get converted to "\vert" before the > formatting function gets called. > > `org-link-heading-search-string', and `org-link-make-string' (both > called from the formatting function _after_ `org-columns--clean-item') > OTOH take care of the link's path and description parts being > appropriate for a link. It would make sense then to include `org-quote-vert' call into `org-columns--clean-item' then. > Kindly find updated patches below. I hope to have succeeded in > addressing all your comments; that was my intention at least. Thanks! > (defun org-columns--capture-view (maxlevel match skip-empty exclude-tags > format local) >"Get the column view of the current buffer. >... > +When LOCAL is non-nil, only capture headings in current subtree. When > +LINK is non-nil, item headlines will be linked to their origins. Looks like you removed the LINK parameter, but forgot to remove its description from the docstring. > +(let ((search (org-link-heading-search-string > raw))) > + (org-link-make-string > + (if (not (buffer-file-name)) search > + (format "file:%s::%s" (buffer-file-name) > search)) > + cleaned)) This will unconditionally generate file: links, even when the dynamic block only refers to headings in the same buffer. The clock tables do use internal links when appropriate (see `org-clock-get-table-data'). I am attaching a patch containing test case making sure that internal links are generated when appropriate. The test case is failing with the latest version of your patch. If you can, please add some more tests like mine checking `org-columns--clean-item'. >From 3961072d80883aef5da21d8d6ba10213778ff32f Mon Sep 17 00:00:00 2001 Message-ID: <3961072d80883aef5da21d8d6ba10213778ff32f.1713871396.git.yanta...@posteo.net> From: Ihor Radchenko Date: Tue, 23 Apr 2024 14:22:44 +0300 Subject: [PATCH] org-colview: Add test for the new :link parameter * testing/lisp/test-org-colview.el (test-org-colview/dblock): New test case. --- testing/lisp/test-org-colview.el | 12 1 file changed, 12 insertions(+) diff --git a/testing/lisp/test-org-colview.el b/testing/lisp/test-org-colview.el index 7f0aa763e..872a61753 100644 --- a/testing/lisp/test-org-colview.el +++ b/testing/lisp/test-org-colview.el @@ -1422,6 +1422,18 @@ (ert-deftest test-org-colview/dblock () "* H\n:PROPERTIES:\n:A: 1\n:END:\n#+BEGIN: columnview\n#+END:" (let ((org-columns-default-format "%ITEM %A")) (org-update-dblock)) (buffer-substring-no-properties (point) (point-max) + ;; Test `:link' parameter. + (should + (equal +"#+BEGIN: columnview +| ITEM | +|--| +| [[*H][H]]| +#+END:" +(org-test-with-temp-text +"* H\n#+BEGIN: columnview\n#+END:" + (let ((org-columns-default-format "%ITEM")) (org-update-dblock)) + (buffer-substring-no-properties (point) (point-max) ;; Test column widths. (should (equal -- 2.44.0 -- 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>
Re: [FR] Please add custom command variable to org-latex-footnote-refere
Alexander Gogl writes: > you mean like this? Not really, but I now squashed the previous patches manually. Applied, onto main, with amendments. I fixed some wording in the etc/NEWS entry, added description of %s%s to the docstring, and removed BEHAVIOR=t from the new option - all other similar options have BEHAVIOR=nil, so let's keep things consistent. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=46e13c3eb You are also listed as an Org contributor now. https://git.sr.ht/~bzg/worg/commit/ec8a1007 -- 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>
Re: [PATCH] Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline
Matt writes:
> Whether this is a solution, in part, depends on the perennial problem of
> shell blocks: knowing what's wrong means knowing what's right.
>
> The proposed solution assumes we intend to parse the characters following
> :cmdline as space delimited and grouped by quotes. However, AFAICT, the
> parsing issue makes this solution ambiguous.
>
> Thoughts?
Manually parsing the shell arguments is calling for trouble.
Especially when the arguments involve shell-specific escapes like
:cmdline 1\ 2\ 3
Since escape characters may vary from shell to shell, it is not a good
idea to parse the arguments on Elisp side. We should better leave this
job to the shell.
I propose the attached patch.
>From e0cf4161b4af05c513ba402ee9625851853c9465 Mon Sep 17 00:00:00 2001
Message-ID:
From: Ihor Radchenko
Date: Tue, 23 Apr 2024 13:22:22 +0300
Subject: [PATCH] ob-shell: Pass :cmdline arguments consistently regardless of
:shebang
* lisp/ob-shell.el (org-babel-sh-evaluate): When invoking script file
generated from the code block, consistently use
-c command line, even when
:shebang is header argument is provided. The previous approach with
call caused differences in how shell
parsed the provided command line arguments.
Reported-by: Max Nikulin
Link: https://orgmode.org/list/18f01342a2f.124ad27612732529.8693431365849276...@excalamus.com
---
lisp/ob-shell.el | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el
index 35d9e9376..30b3ea322 100644
--- a/lisp/ob-shell.el
+++ b/lisp/ob-shell.el
@@ -322,14 +322,12 @@ (defun org-babel-sh-evaluate (session body params stdin cmdline)
(with-temp-buffer
(with-connection-local-variables
(apply #'process-file
-(if shebang (file-local-name script-file)
- shell-file-name)
+shell-file-name
stdin-file
(current-buffer)
nil
-(if shebang (when cmdline (list cmdline))
- (list shell-command-switch
-(concat (file-local-name script-file) " " cmdline)
+(list shell-command-switch
+ (concat (file-local-name script-file) " " cmdline
(buffer-string
(session ; session evaluation
(if async
--
2.44.0
--
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>
Re: orgmode tables
Jude DaShiell writes: > Doesn't work here. Just makes the terminal beep. Using terminal Emacs? Be aware that terminals cannot emulate certain key bindings, including modifier + arrow keys. See https://orgmode.org/manual/TTY-Keys.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>
Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
Ihor Radchenko writes: > A gentle ping. This patch is still hanging in the air. Canceled. -- 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>
Re: Using search options in HTTP-style links
Joseph Turner writes: >> So, there is nothing stopping from creating an ad-hoc convention to >> parse URL locators in links to PDFs or org files or whatnot. > > I'll need to dig a little more to see what changes would need to be made > in order for org-store-link to store properly formatted search options > with http: or hyper: links. Currently, org-create-file-search-functions > is only used when creating a file: link. You can instead use :store link parameter. It takes precedence over everything else in `org-store-link'. >> However, the question about activating a major mode on web content is a >> question to Emacs developers. It should be considered carefully, because >> activating major modes may not be safe. > > hyperdrive.el activates a major mode with set-auto-mode when content is > loaded over the network. This behavior is on by default. Do you have > any advice about this? > > Should hyperdrive.el set untrusted-content to t? I was mostly talking about commands like eww - I simply recall a similar proposal being made about activating Org mode when the URL points to Org file. That proposal has been rejected on the grounds of security. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774 The case with hyperdrive.el is not the same. You may want to discuss it on emacs-devel. As for untrusted-content, there is no point using it now - it was specifically introduced for Org mode. It may or may not become a part of more general security framework in Emacs. -- 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>
Re: `org-emphasize' missing in the manual
Arash Esbati writes: > I wonder why the function `org-emphasize' is missing in the manual. I'm > not an versed Org user, but it seems that this command is the entry > point for users to mark up text. So I suggest to add it to > > 12.2 Emphasis and Monospace[1],[2] > > incl. the keybinding "C-c C-x C-f". Makes sense. Would you be interested to submit a patch? You will need to modify doc/org-manual.org file in Org repository. See https://orgmode.org/worg/org-contribute.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>
Re: [FR] Add C-u and C-u C-u prefix arguments to org-paste-subtree (was: Make org-paste-subtree more predictable and useful)
Samuel Wales writes: > so here i go again with new decription: i am taking an entry and putting a > whole other entry into the middle of it at the same level like this: > > === > * a new idea i had > regarding snicker snacks > * jabberwoky > some sophomoric comments on a poem > > more sophomoric comments > === > > becomes: > > === > * jabberwoky > some sophomoric comments on a poem > > * a new idea i had > regarding snicker snacks > > more sophomoric comments > === Just call org-yank with prefix argument (C-u C-y): Any prefix to this command will cause yank to be called directly with no special treatment. In particular, a simple C-u prefix will just plainly yank the text as it is. -- 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>
Re: PATCH allow explicit style= in #+cite_export: biblatex
Pedro Andres Aranda Gutierrez writes:
>> What about something like
>>
>> #+cite_export: biblatex backend=bibtex,bibstyle=numeric
>>
> Just tested on a work document. It generates
> \usepackage[backend=bibtex,bibstyle=numeric]{biblatex}
> which is a perfectly valid options string for biblatex and yes,
> the PDF is generated without errors ;-)
Not for me.
With your latest patch, I tried to export the following to latex
#+cite_export: biblatex backend=bibtex,bibstyle=numeric
#+bibliography: bib.bib
Test [cite:@takemoto2006dissolution]
#+print_bibliography:
bib.bib:
@article{takemoto2006dissolution,
title={Dissolution of stainless steels in molten lead-free solders},
author={Takemoto, Tadashi and Takemoto, Masaharu},
journal={Soldering \& surface mount technology},
volume={18},
number={3},
pages={24--30},
year={2006},
publisher={Emerald Group Publishing Limited}
}
I am getting
\usepackage[style=backend=bibtex,bibstyle=numeric]{biblatex}
>> > BTW, I was thinking that maybe "\\`[^=]+=" may be better than matching
>> > style= anywhere in the options string...
>> > Open to discuss it...
>>
>> May you elaborate what exactly will be improved?
>>
>
> IMHO, the current solution of prepending "style=" forces the option string
> to be
>
Re: [BUG] Some recent change broke :extend on headlines with background property [9.7-pre (release_9.6.26-1373-g5b0b7f @ /home/st/.config/emacs/.local/straight/build-30.0.50/org/)]
StrawberryTea writes: > Hello. When I run the following code in `emacs -Q`, the background color > of the headline is not extended to the end of the line as expected. This > is a regression from the previous behavior and is caused by a recent > change in Org mode. I do not know which commit caused this issue. > > (straight-use-package 'org) > > (require 'org) > (load-theme 'leuven t) > ... Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1ad03e77b -- 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>
Re: Trailing whitespace after export snippets without a transcoder
Max Nikulin writes:
>> I do not think that we need to handle this Org mode-wide (it will be
>> difficult and will likely cause breaking changes).
>
> I have not figured out why it may become a breaking changes and what
> backends need blank lines inside paragraph. I would make stripping empty
> lines default behavior with some option to disable this feature.
For example, consider an HTML exporter that aligns tags nicely and keeps
blank lines between markup blocks for readability. If we remove such
blank lines unconditionally, it will be problematic.
>> See the attached tentative fix.
>
> Since zero width spaces are part of Org syntax, they need special treatment.
They are not a part of Org syntax, and we currently do not handle them
specially. They still work as escape-character simply because Org syntax
defines markup boundaries using a closed set of whitespace characters -
(rx (any " \t")). So, any non-tab non-space whitespace will be an
equivalent of zero-width space for all practical purposes.
> 8<
> #+macro: empty (eval "")
>
> Some *bold*@@comment: *@@ text.
> @@comment: line@@
> More /italic/{{{empty}}} text.
> {{{empty}}}
> Last line.
> >8
>
> LaTeX export:
> 8<
> Some \textbf{bold}text.
> More \emph{italic} text.
>
> Last line.
> >8
>
> Notice visible space character disappeared after "bold".
I guess that I can change the condition to not include trailing space
from (rx whitespace eol) to (rx (any " \t|) eol).
See the attached updated version of the patch set.
> ... I am leaving up
> to you to decide if empty line appeared due to a macro is a bug or a
> feature. If I remember it correctly, your opinion is that a macro
> expanding to multiple paragraphs is a valid one.
Yes. I do believe that we should keep macros as dumb as possible, so
that people can use them in the most flexible ways, including breaking
paragraphs, if so desired.
A more annoying one is
First line
@@comment:foo@@
last line.
vs.
First line
@@comment:foo
@@last line.
where we encounter the peculiarity of Org syntax with trailing tabs and
spaces included as part of the object, but not newlines.
But I do not see any good way to address this problem without rewriting
half of Org mode.
>From 229a563dc38e1fdfd63be2dfebb1a9e9023e44b2 Mon Sep 17 00:00:00 2001
Message-ID: <229a563dc38e1fdfd63be2dfebb1a9e9023e44b2.1713812419.git.yanta...@posteo.net>
From: Ihor Radchenko
Date: Sun, 21 Apr 2024 15:37:18 +0300
Subject: [PATCH v2 1/2] org-export-data: Handle trailing spaces when
transcoder returns nil
* lisp/ox.el (org-export--keep-spaces): New helper function containing
logic about keeping spaces in place of removed object from
`org-export--prune-tree'. The logic is modified to keep spaces in the
case when previous plain-string object ends with a whitespace, but not
" " or "\t". This can happen, for example, when there is a trailing
zero-width space. We do want to keep spaces in such scenario.
(org-export-data): When transcoder returns nil, handle
trailing spaces after an object the same way `org-export--prune-tree'
does. Remove special handling of export snippets that unconditionally
keep their trailing spaces.
(org-export--prune-tree): Use the helper function.
Link: https://orgmode.org/list/87h6fwmgkm.fsf@localhost
---
lisp/ox.el | 67 ++
1 file changed, 42 insertions(+), 25 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index fc746950d..6f6689188 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -1880,6 +1880,38 @@ (defun org-export-transcoder (blob info)
(let ((transcoder (cdr (assq type (plist-get info :translate-alist)
(and (functionp transcoder) transcoder)
+(defun org-export--keep-spaces (data info)
+ "Non-nil, when post-blank spaces after removing DATA should be preserved.
+INFO is the info channel.
+
+This function returns nil, when previous exported element already has
+trailing spaces or when DATA does not have non-zero non-nil
+`:post-blank' property.
+
+When the return value is non-nil, it is a string containing the trailing
+spaces."
+ ;; When DATA is an object, interpret this as if DATA should be
+ ;; ignored (see `org-export--prune-tree'). Keep spaces in place of
+ ;; removed element, if necessary. Example: "Foo.[10%] Bar" would
+ ;; become "Foo.Bar" if we do not keep spaces. Another example: "A
+ ;; space@@ascii:*@@ character." should become "A space character"
+ ;; in non-ASCII export.
+ (let ((post-blank (org-element-post-blank data)))
+(unless (or (not post-blank)
+(zerop post-blank)
+(eq 'element (org-element-class data)))
+ (let ((previous (org-export-get-previous-element data info)))
+ (unless (or
Re: [DOC] Mismatch on doc regarding position of src block switches
João Pedro writes: > I've noticed that in (org)Literal Examples[0], when documenting the switches > for example and source blocks, it is mentioned that they should be placed at > the *end* of the #+BEGIN line, while both in (org)Structure of Code Blocks[1] > and the Org Syntax document[2] the switches are documented to be placed right > after the language (when appropriate), which is the correct placement for it. Thanks for reporting! Fixed, on bugfix. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a9275d5fd > I've also noticed that the Org Syntax for blocks (greater or lesser) don't > mention example blocks having optional switches. We deliberately limit the number of details in the syntax spec. For now, we just say that lesser blocks can have arbitrary DATA at the begin line. -- 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>
Re: [BUG] Agenda query trailing spaces [9.5 (release_9.5-225-g494c20.dirty @ /Users/carlos/Install/Source/org-mode/lisp/)]
Ihor Radchenko writes: > Confirmed > > However, this behaviour seems to be partially intentional. It was > explicitly introduced in 774964adb. So, the fix may not be > straightforward. Someone needs to study the relevant agenda code. Fixed, on bugfix. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0db82ee8f -- 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>
Feedback on the new "feature" system in org-export (was: [Pre-PATCH] Overhaul of the LaTeX preview system)
Timothy writes: > After months of work, Karthink and I have prepared a rather large patch-set > completely overhauling the LaTeX preview system. I hope to have a patch set > shortly, but in the mean time it would be good to get some more people testing > this. > > To test this feature, please check out the `dev' branch of > <https://git.tecosaur.net/tec/org-mode.git> (it’s the default branch). There > are > also some other changes there currently, but I don’t think anything is broken. Now, after the last blocker with odt export has been addressed, I am starting to review the patch formally for merging upstream. One of the new core mechanisms introduced in the patch is the "feature" system for building export preambles. It allows building the preambles selectively, depending on the document contents and current export configuration. The feature is mostly designed for use in latex/beamer export where every additional \usepackage call adds to the compile time. Not to mention the problem when we have to limit the latex packages we use by default in order to not create incompatibilities with user packages. For now, I will provide some high-level feedback: 1. After not following latex-preview feature development for a while, with a fresh mind, I find the basic terminology rather confusing. When reading the new "Export features" section of the manual, and looking through the code, I feel that a more appropriate name for the "features" would be "templates" - what you call "feature implementations" is, at the end, very similar to Emacs skeletons, but with a twist that the template order is not fixed: (cl-defstruct (org-export-backend (:constructor org-export-create-backend) (:copier nil)) ... template-conditions templates) 2. While reading the new manual section, I have an impression that the feature/template system can be used in any export backend and that document preamble can be customized by users locally, on top of the backend. However, it is only really true for ox-latex and its derived backends. If one, for example, tries to use org-export-update-features on 'html (for example, to include some JS library conditionally), it will not work. I thus feel that the newly added section does not really belong to the user manual. Rather to https://orgmode.org/worg/dev/org-export-reference.html 3. What could make sense to expose to users (and to add to the user manual) is the means to customize the document preamble conditionally. Now, we have `org-latex-classes' with its awkward syntax of [DEFAULT-PACKAGES] \usepackage statements for default packages [NO-DEFAULT-PACKAGES] do not include any of the default packages [PACKAGES] \usepackage statements for packages [NO-PACKAGES] do not include the packages [EXTRA] the stuff from #+LATEX_HEADER(_EXTRA) [NO-EXTRA] do not include #+LATEX_HEADER(_EXTRA) stuff I think that it could be a good idea to support an alternative syntax making use of feature/template system. Same thing for similar customizations like `org-cite-csl-latex-preamble' and `org-latex-engraved-preamble' Ideally, we should supply users with a list of templates for the most commonly used latex packages, formalizing LaTeX package dependencies and conflicts 4. The overall design of the feature/template system is solid, and we can extend it in case we need to. However, I am slightly concerned that the only user of the new system is ox-latex. I believe that we can test the current API better if we try to use it for real in several scenarios. I have the following use-cases in mind: + `org-latex-classes' and similar user-defined templates + `org-latex-template' + `org-beamer-template' -> this one is important as we can partially inherit from the latex template. + `org-html-template' -> something non-LaTeX -- 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>
Re: `org-element-cache-map' misses elements at end of buffer
Morgan Smith writes: >> It is the time to refactor this function yet again. >> (a tricky endeavour considering all the edge cases we can encounter when >> there are changes in buffer while `org-element-cache-map' is mapping >> over it). > > See attached for a way to break :from-pos as well. I would like to help > refactor but studying this function is a little dizzying for me. At this point, it might be easier to rewrite the whole thing from scratch, just based on the commentary (I tried my best to leave detailed commentary explaining the intended logic). We have a decent test coverage when mapping headings in buffer, so edge cases will be checked by make test. In particular, it might be a good idea to get rid of the idea of START variable and just make use of AFTER-ELEMENT. For now, they serve kinda the same purpose, but the latter was added because START was not enough when the buffer is modified by FUNC. -- 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>
Re: [FR] Please add custom command variable to org-latex-footnote-refere
Alexander Gogl writes: > I have tested the global and buffer local options with kaoscript and the > article class. I could't find any problems with the option. Labels and > footnotes inside footnotes work. > > The current version of the patch (fixed a typo) is attached. Thanks! May you please send the final version of the patch, against main branch rather than a series of incremental patches? -- 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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Alexander Adolf writes: > Ah, `org-column--clean-item'; well spotted! > > Two observations: > > 1) As is now, I'm generating the links in the data collection function >`org-columns--capture-view'. As `org-column--clean-item' is called >from code that runs after the data collection, >`org-column--clean-item' was probably never designed to be able to >handle strings containing links. That it still did sort of "the right >thing" seems more luck than anything else? There is a difference between what `org-columns--clean-item' does and stripping link paths. `org-columns--clean-item' is cleaning up the results for insertion into a table specifically. This is only meaningful in dynamic block, but not in the traditional column view where nothing is actually written to buffer - the columns are displayed on top of the existing headings. Calling `org-columns--clean-item' is a must to create a valid table. In contrast, the purpose of `org-link-display-format' is purely visual - to not make the collected titles way too long. Also, it has no effect when there is a custom `org-columns-modify-value-for-display-function' (see `org-columns--displayed-value'). > 2) Considering what happens when I do `org-store-link' and >`org-insert-link', it would seem more advisable to: > >a) move the link generation to the new formatting function > (re-removing it from `org-columns--capture-view'); > >b) pass the "cleaned" string to `org-link-make-string' as both, the > link and the description parameter. I do not recall seeing `org-store-link' in the patches you submitted. So, I am not sure what you are talking about. May you elaborate? >> We should probably also change org-clock to use >> `org-columns--clean-item'. >> [...] > > As a separate patch, or as a third commit to the patch we are discussing > now? Up to you. -- 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>
Re: PATCH allow explicit style= in #+cite_export: biblatex
Pedro Andres Aranda Gutierrez writes: > +: #+cite_export: biblatex backend=bibtex,style=numeric What about something like #+cite_export: biblatex backend=bibtex,bibstyle=numeric > BTW, I was thinking that maybe "\\`[^=]+=" may be better than matching > style= anywhere in the options string... > Open to discuss it... May you elaborate what exactly will be improved? -- 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>
Re: Trailing whitespace after export snippets without a transcoder
Max Nikulin writes: >> I have no clue about the rationale of this special behaviour - it dates >> back to the days when Org export was merged. It is also not documented >> anywhere, AFAIK. > > I would not expect that the space after the following export snippet is > ignored in the case of ox-html or ox-latex backend: > > A space@@ascii:*@@ character. > > The space may be put inside the export snippet if the intention is to > omit it for output formats other than plain text. So current behavior is > perfectly reasonable and flexible enough. Hmm. We actually have a similar scenario in `org-export--prune-tree' with a slightly different logic - only keep spaces when previous object does not have any. I am attaching tentative patch that will duplicate the logic for export snippets as well. And for any other object where transcoder returns nil. WDYT? >From 54939c4044fb407b068c0666c258ccd01e59c2af Mon Sep 17 00:00:00 2001 Message-ID: <54939c4044fb407b068c0666c258ccd01e59c2af.1713703523.git.yanta...@posteo.net> From: Ihor Radchenko Date: Sun, 21 Apr 2024 15:37:18 +0300 Subject: [PATCH 1/2] org-export-data: Handle trailing spaces when transcoder returns nil * lisp/ox.el (org-export-data): When transcoder returns nil, handle trailing spaces after an object the same way `org-export--prune-tree' does. Remove special handling of export snippets that unconditionally keep their trailing spaces. Link: https://orgmode.org/list/87h6fwmgkm.fsf@localhost --- lisp/ox.el | 43 --- 1 file changed, 32 insertions(+), 11 deletions(-) diff --git a/lisp/ox.el b/lisp/ox.el index fc746950d..ccc4c94ce 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -1930,15 +1930,11 @@ (defun org-export-data (data info) (eq (plist-get info :with-archived-trees) 'headline) (org-element-property :archivedp data))) (let ((transcoder (org-export-transcoder data info))) - (or (and (functionp transcoder) - (if (eq type 'link) - (broken-link-handler - (funcall transcoder data nil info)) - (funcall transcoder data nil info))) - ;; Export snippets never return a nil value so - ;; that white spaces following them are never - ;; ignored. - (and (eq type 'export-snippet) "" + (and (functionp transcoder) + (if (eq type 'link) + (broken-link-handler + (funcall transcoder data nil info)) + (funcall transcoder data nil info) ;; Element/Object with contents. (t (let ((transcoder (org-export-transcoder data info))) @@ -1979,8 +1975,33 @@ (defun org-export-data (data info) (puthash data (cond - ((not results) "") - ((memq type '(nil org-data plain-text raw)) results) + ((not results) + ;; TRANSCODER returned nil. When DATA is an object, + ;; interpret this as if DATA should be ignored (see + ;; `org-export--prune-tree'). Keep spaces in place of + ;; removed element, if necessary. + ;; Example: "Foo.[10%] Bar" would become + ;; "Foo.Bar" if we do not keep spaces. + ;; Another example: "A space@@ascii:*@@ character." + ;; should become "A space character" in non-ASCII export. + (let ((post-blank (org-element-post-blank data))) + (or +(unless (or (not post-blank) +(zerop post-blank) +(eq 'element (org-element-class data))) + (let ((previous (org-export-get-previous-element data info))) + (unless (or (not previous) + (pcase (org-element-type previous) + (`plain-text + (string-match-p +(rx whitespace eos) previous)) + (_ (org-element-post-blank previous + ;; When previous element does not have + ;; trailing spaces, keep the trailing + ;; spaces from DATA. + (make-string post-blank ?\s +""))) +((memq type '(nil org-data plain-text raw)) results) ;; Append the same white space between elements or objects ;; as in the original buffer, and call appropriate filters. (t -- 2.44.0 > The issue is empty lines that serve as paragraph separators and that may > appear due to expansion of a macro or due to skipped export snippets. > Perhaps transcoders of other elements, e.g. links, may return empty > strings as well. Right. This is a special case in MD where blank lines separate paragraphs. Just like in ox-latex, where we fixed exactly same thing reported in https://orgmode.org/list/tufdb6$11h2$1...@ciao.gmane.io It is also a side effect of the fact that newlines are not considered a part of the Org markup
Re: [FR] Add C-u and C-u C-u prefix arguments to org-paste-subtree (was: Make org-paste-subtree more predictable and useful)
Philipp Kiefer writes: > To be honest, I don't see much need for fine-grained special cases. I'd > be very happy with C-u yanking at the level of the heading at point and > C-u C-u yanking at one level below that, regardless of the exact > position of point. I realize that would mean C-u doubling what can > already be done by calling org-paste-subtree with point at the beginning > of a heading but accessing both options (paste as sibling or child) with > a single or repeat C-u seems more consistent to me than having one > depend on position and getting at the other via the command prefix. This feature is now implemented on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5b0b7f292 Done. -- 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>
Re: `org-element-cache-map' misses elements at end of buffer
Morgan Smith writes: > So I found another bug in `org-element-cache-map'. > > Executing the following code just freezes up. I am struggling to work > through the logic of `org-element-cache-map'. If no-one else magically > solves my issues, I'll figure it out eventually. But I would appreciate > some advice on how to debug this stuff (both my issue of missing > elements and freezing). Hmm. :after-element keyword logic is broken. It does not account for the case when :after-element is past the START point. It is the time to refactor this function yet again. (a tricky endeavour considering all the edge cases we can encounter when there are changes in buffer while `org-element-cache-map' is mapping over it). -- 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>
Re: [DISCUSSION] What should we do with undocumented x^(superscript inside /round/ braces) syntax?
Ihor Radchenko writes:
> Upon further examination, I found that ^:{} does accept _only_ curly
> braces:
> ...
> So, round braces can be seen as another variant of DWIM behavior.
>
> I conclude that there is no reason to change the existing syntax.
>
> I will need to update `org-use-sub-superscripts' docstring and
> https://orgmode.org/worg/org-syntax.html#Subscript_and_Superscript to
> document this special case.
>
> Maybe also update the manual section 12.3 Subscripts and Superscripts.
All done on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=36d092804
https://git.sr.ht/~bzg/worg/commit/834ac25e
Closed.
--
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>
Re: strange export problem with a file: link
"Fraga, Eric" writes: > I have a file that consists of these three lines: > > --8<---cut here---start->8--- > #+begin_src latex :results file raw :exports results :file function.png > \[ y = f(x) \] > #+end_src > --8<---cut here---end--->8--- > > With "emacs -Q" and loading in org from the git repository as of maybe > an hour or so ago, I get this error: > > org-odt-export-to-odt: OpenDocument export failed: Opening input file: No > such file or directory, /tmp/file:function.png > > when I try to export the file to ODT. Exporting to LaTeX (PDF) works > just fine. For the ODT export, the "file:" link specification is not > being removed. > > I don't think I'm doing anything wrong; is this a bug in the exporter? Yes. Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=769018718 -- 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>
Trailing whitespace after export snippets without a transcoder (was: [PATCH v2] org-faq.org: Inline comments)
Max Nikulin writes: >>>>>> +#+begin_src org >>>>>> +The following line may become a patagraph separator. >>>>>> +@@comment: might give unexpected effect @@ >>>>>> +Put some text before @@comment: a better variant >>>>>> +@@ and after instread. >>>>>> +#+end_src >> >> I am no longer able to reproduce the problem with @@comment:...@@ >> splitting paragraph in the above example. > > I see no changes in respect to ox-md on the main branch. Right. Upon debugging further, to my great surprise, I found the following comment in ox.el: ;; Export snippets never return a nil value so ;; that white spaces following them are never ;; ignored. (and (eq type 'export-snippet) "") and then even a test: ;; Ignored export snippets do not remove any blank. (should (equal "begin end\n" (org-test-with-parsed-data "begin @@test:A@@ end" (org-export-data-with-backend tree (org-export-create-backend :transcoders '((paragraph . (lambda (paragraph contents info) contents)) (section . (lambda (section contents info) contents info The test was added in the commit https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a6d9fd82e Back-end developers should pay attention to the fact that white spaces before and after an ignored export snippet now are accumulated in the output. I have no clue about the rationale of this special behaviour - it dates back to the days when Org export was merged. It is also not documented anywhere, AFAIK. -- 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>
Re: [PATCH] Allow external libraries (org-roam) to supply org-id locations
Ihor Radchenko writes: > Also, before we merge your patch, may I know if you discussed this > change with org-roam developers? If they do not want to use the proposed > hook, there is no reason to add it to Org mode. It has been over a month since the last message in this thread. May I know if there is any progress? -- 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>
Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))
Bruno Barbier writes: > Thanks for the review. > > I've pushed a new version, hoping to decrease the number of dislikes > ;-) Thanks! >>> Cancel is handled by sending a failure message (see >>> `org-pending-cancel'). It's customizable using the reglock field >>> ~org-pending-reglock-user-cancel-function~, which can decide what to >>> do (like kill a process) and which can send a better outcome. >>> Standard 'cancel' leaves a failure outcome mark. >> >> Note that this function is not documented anywhere other than in reglock >> class documentation. > > Thanks. I've improved the documentation of `org-pending' to mention > that one may want to customize the following fields of a reglock: > before-kill-function, user-cancel-function and > insert-details-function. And, also, I added that one can attach > custom properties using the "properties" field. Thanks, but I still feel confused. May you: 1. Explain what does "kill" and "cancel" mean in the context of the REGLOCK. 2. Add information about visual hints, "kill", and "cancel" to the top-level commentary. For now, when reading the top commentary: ;; This library contains an API to lock a region while it is "being ;; updated"; the content of the region is "pending" and cannot be ;; modified. It will be updated, later, when the new content is ;; available. I have an impression that the only side effect of "locking" is that the region becomes read-only. It is not clear at all that any other visual indication will be provided. >> In general, I am confused about your overall design >> of the user interaction with the locks. >> The updated top commentary explains well how Elisp programs can send >> data to the locks, but it does not say anything about how Elisp programs >> can receive the data. > > An elisp program, that uses org-pending, must update the locks using > `org-pending-send-update'. That program does not receive any data > from the lock; it may customize Emacs behavior using the reglock > fields mentioned above: before-kill-function, user-cancel-function and > insert-details-function. > > Hopefully, it's clearer now with the improved documentation of the > org-pending function. > > Just let me know if you still think that the top commentary should > explain this. Thanks. Yes, I do think that top commentary should explain this. The very idea that lock may be "canceled" or "killed" is important when designing Elisp code that uses the org-pending library. >> Also, I'd like to see more information in the top commentary about what >> are the "visual hints" displayed to the user and how to configure them. > > If you think the current "visual hints" are good enough and could be > shipped as-is, in a first version (indirect buffers, etc.); I could > work on documenting them better. What kind of configuration are you > thinking about ? just the faces ? or more advanced configurations ? I am not thinking about details yet. I just want insert-details-function to be described in the top commentary. At high level. Something like * Visual indication of the "pending" regions While the region is locked, it is visually highlighted in the buffer, providing information about the lock status as an overlay. The status can be: 1. :scheduled - the region is "being updated", but the computation has not yet started. 2. :progress - the computation is in progress After unlocking the region, the visual indication is not necessarily removed. Instead, the outcome is indicated in an overlay. The outcome may be: 1. :success - the computation has been successful and the region text has been updated 2. :failure - the computation failed The lock status is updated according to the data submitted to REGLOCK object via `org-pending-send-update'. * User interaction with pending regions For any pending region, users may request detailed description to be displayed. The description includes the pending region status, creation time, outcome, duration, results, errors, etc. Elisp code using this library may also supply additional details about any given reglock, via `insert-details-function' field of REGLOCK object. For example, process logs can be displayed this way. I hope that the above clarifies what I am looking for. -- 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>
Re: org syntax: is \begin{equation} a latex-fragment?
Max Nikulin writes:
> Is it expected that
>
> 8<
> \begin{equation}
> >8
>
> is parsed by (org-element-parse-buffer) as the following?
>
> (latex-fragment ... :value "\\begin{equation}")
Yes.
It matches https://orgmode.org/worg/org-syntax.html#LaTeX_Fragments
> \begin{something} is quite special in LaTeX, so despite it is similar to
> `latex-fragment' definition, it almost certainly leads to an error.
> Perhaps is should be detected by `org-lint' and treated as literal text
> by `org-element' since it is incomplete `latex-environment'.
Yes, a linter would make sense.
Patches welcome!
--
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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Alexander Adolf writes:
>> Also, if you mention a variable in the manual, please add #+vindex:
>> entry. Maybe even #+cindex: entry for "formatter", to make the parameter
>> more discoverable.
>
> I kept it to the format of the existing parameter descriptions, which
> don't create index entries. Happy to add one though. #+cindex would seem
> more appropriate, as it's not a variable?
When suggesting #+vindex, I was referring to
org-columns-dblock-formatter variable.
> On a loosely related note: the description of the :formatter parameter
> of the clock table does not have and index entry either. Should it get
> one too, then?
Within the scope of this patch, it is enough to add the index entry to
the newly added parameter.
More generally, we do want index entries for various parameters in
dynamic blocks and clock tables. As we do for header arguments:
#+cindex: @samp{file}, header argument
But that should be a separate patch.
For colview dynamic blocks, cindex entry may look like
#+cindex: @samp{formatter}, dynamic block parameter
>> Is there any reason why you did not remove the statistics cookies here
>> as well?
>> [...]
>
> Somehow (how?) the statistics cookies get removed in my current
> implementation. org-link-make-string does not remove them (I double
> checked). I would thus speculate that perhaps the overlay creation (to
> show description only) removes them? OTOH, I'm happy to add the
> org-trim part to make things more robust.
I see how. It is because CELL-CONTENT is not the original heading. It is
the heading name processed with `org-columns--clean-item'.
`org-column--clean-item' removes statistics cookies among other things.
It actually removes more, leading to some edge cases in your patch:
** TODO Foo
** TODO src_elisp{"Hello"} world
#+begin: columnview :id global :link t
| <25> | | <3> | |
| ITEM | TODO | PRIORITY | TAGS |
|---+--+--+--|
| [[file:/tmp/test.org::*Foo][Foo]] | TODO | B| |
| [[file:/tmp/test.org::*src_elisp{"Hello"} world][world]] | TODO | B|
|
#+end:
Note how inline src block is stripped from the link description.
We should probably also change org-clock to use
`org-columns--clean-item'.
--
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>
Re: `org-element-cache-map' misses elements at end of buffer
Morgan Smith writes: > I may or may not have been trying to rewrite `org-clock-sum' for like > the 5th time. > > Anyways I was wanting to parse a file using `org-element-cache-map' that > looked roughly like this: > > > * clock > :LOGBOOK: > CLOCK: [2024-03-24 Sun 15:18]--[2024-03-24 Sun 15:39] => 0:21 > :END: > === > > However I couldn't get the clock element this way. After much trail and > error I found that simply adding another heading on the end allowed me > to get the clock element! > > I've attached a test so you can reproduce the problem. In the test it > is a paragraph element that is not showing up. Thanks for reporting! Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=942a7320d -- 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>
Re: org-persist-write slowing down kill-buffer
Karthik Chikmagalur writes: > I've been noticing that kill-buffer blocks Emacs for a noticeable > period when killing org buffers. Here are elp results obtained by > instrumenting org-persist-* and kill-buffer: > > | Function name | Call count | Elapsed time | Average > time | > |---++--+--| > | kill-buffer | 38 | 2.5647546329 | > 0.0674935429 | > | org-persist-write-all-buffer | 1 | 2.562779994 | > 2.562779994 | > | org-persist-write-all | 1 | 2.56277329 | > 2.56277329 | > | org-persist-write | 1 | 1.627834788 | > 1.627834788 | > | org-persist--write-elisp-file | 1 | 0.312172392 | > 0.312172392 | > It blocks Emacs for about 3 seconds each time. Any Org file with > 500 > lines causes this behavior. > > I've also attached the sampling profiler output from killing an Org > buffer. > > Some facts that might be relevant: > > - I'm using the WIP LaTeX preview system fork of Org, but there are no > LaTeX previews in the Org buffers that I run these tests on. (There > aren't even any LaTeX fragments.) > > - My org-persist-dir is 627MB in size. What is your (length org-persist--index) ? Also, it does not look like your `org-element-ast-map' is compiled. -- 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>
Re: [BUG] A custom org-num-format-function causes org-latex-preview warn when it called. [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]
Ihor Radchenko writes: > I was able to reproduce using the provided steps using the built-in Org > mode version and using the latest stable Org mode version. > However, I am unable to reproduce using the latest development Org mode > version. Handled. -- 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>
Re: [BUG] LaTeX preview should use a subdirectory in /tmp
Emmanuel Charpentier writes: >> What if you do M-x trace-function org-compile-file-commands > > No such function : I just have org-compile-file , which I traced. May you try the development branch of Org mode (main)? -- 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>
Re: [BUG] org-paste-subtree level when point is in the middle of a heading (was: Make org-paste-subtree more predictable and useful)
Ihor Radchenko writes: > Steps to reproduce: > > 1. Create a file > > 1.1.1.1 > 1.1.1.2 > * 3 > ** 3.1 > *** 3.1.1 > low-level item > *** 3.1.2 > *** 3.1.3 > > 2. Copy the first two headings > 3. Move point as indicated > 4. M-x org-paste-subtree > > Observed: 1.* headings inserted after 3.1.1 and before "low-level-item", > thus breaking the sub-tree. Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d73688faa -- 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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
l, and `make test` ended with the > following: > ... > 4 unexpected results: >FAILED ob-calc/matrix-inversion >FAILED test-ob-shell/bash-uses-assoc-arrays >FAILED test-ob-shell/bash-uses-assoc-arrays-with-lists >FAILED test-org-table/sort-lines MacOS? There are known issues with locale rules in MacOS that may cause test failures. -- 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>
Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere
Samuel Wales writes: > for some reason 9.6.22 says org-auto-align-tags is set to t by default. Hmm... That's a good reason. And I need to get some sleep. The default is really t. The change is still breaking though, but only for people who customized ~org-auto-align-tags~. -- 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>
Re: [BUG] LaTeX preview should use a subdirectory in /tmp
Emmanuel Charpentier writes:
>> Assuming that your `org-preview-latex-default-process' is using the
>> default value of 'dvipng, does it help if you change the image
>> convertor
>> command to use absolute path?
>
> I didn't know that one could do that : the placeholders are not well
> documented...
Yeah. This particular option is missing from the docstring of
`org-preview-latex-process-alist'.
>> (plist-put (alist-get 'dvipng org-preview-latex-process-alist)
>> :image-converter
>> '("dvipng -D %D -T tight -o %O %F"))
>
> Nope, same problem : the *Org Preview LaTeX Output* buffer says :
>
> ../../../../../tmp/orgtexSyy18r.dvi: No such file or directory
> This is dvipng 1.15 Copyright 2002-2015 Jan-Ake Larsson
>
> If I understand it correctly, the %F placeholder should be an
> *absolute* filename. It is not...
>
> Couldn't the output directory of the :latex-compiler element being
> hardcoded to, say, the curerent directory or a subdirectory thereof,
> and ditto for the input directory of :image-converter ?
What if you do M-x trace-function org-compile-file-commands
and run the preview.
Then, a buffer should appear listing the command expansions used during
the preview process. May you then share that buffer?
--
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>
Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]
Björn Bidar writes: >>> E.g.: >>> 1. I capture a link using org-protocol >>> 2. Switch to the org-buffer >>> 3. C-c C-l >>> 4. RET <- frame closes however links isn't inserted into the target >>> org-buffer >> >> May you provide more details about how to reproduce? > > What do you miss after the initial details? 1. Did you start from emacs -Q? 2. What kind of protocol did you use? 3. Did you need to switch to specific Org buffer or it gotta be some an arbitrary org buffer? In other words, I need detailed steps starting from emacs -Q, if possible. -- 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>
Re: [BUG] LaTeX preview should use a subdirectory in /tmp
Emmanuel Charpentier writes:
> I have a case where the current way of forcing the temporary directory
> to me `/tmp` is wrong. Running emacs on Ubuntu **under WSL2**,,
> exporting latex snippets to ODT *as images* fails : the `.dvi` files
> are correctly compiled and placed in `/tmp{, but the convert program
> tries to read them in `../../../../tmp/`, which is indeed `/tmp` in a
> "normal" filesystem but **is not** in WSL, where the root (`/`) is in
> fact a mounted tree.
>
> Admittedly, this is a corner case, but it turned out to be necessary
> (exporting via mathml gave unsatisfying results).
It looks like is a different bug. (probably even in Emacs, when
calculating relative path)
Assuming that your `org-preview-latex-default-process' is using the
default value of 'dvipng, does it help if you change the image convertor
command to use absolute path?
(plist-put (alist-get 'dvipng org-preview-latex-process-alist)
:image-converter
'("dvipng -D %D -T tight -o %O %F"))
--
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>
Re: [POLL] Should we enable or disable automatic tag alignment by default everywhere
William Denton writes: > On Wednesday, April 17th, 2024 at 06:21, Ihor Radchenko > wrote: > >> I'd like to ask you, Org mode users, whether we should flip the default >> value of ~org-auto-align-tags~ to t or leave it as nil > > I use proportional fonts for regular text (with the mixed-pitch package). In > this situation, as far as I know the only way to make tags look at consistent > is to set org-tags-column to 0 so they directly follow the text (I make the > font size smaller, so there's a large heading then small tag) or to jam them > way over as far right as they'll go. Anything else and they look ragged. Yes. But this is out of scope of the discussed tag alignment - `org-auto-align-tags' controls the actual plain text in Org buffers. `org-tags-column' has no meaning when non-proportional fonts are used. For non-proportional fonts, the display depends on the specifics of the fonts used to display various parts of the headline. If we want to display Org tags right-aligned, for example, it is a job for fontification and does not need to involve editing the underlying plain text. > So I suspect people using variable pitches will already have this turned on, > and making it the default won't bother them. Sure. I'd like to hear from people who do care about the proposed changes. -- 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>
Re: [C-c C-q] org-set-tags-command completed tags does not contains current buffer local tags
"Christopher M. Miles" writes: > In the [C-c C-q] org-set-tags-command, I found it does not complete tags in > current buffer. > ... > Steps to reproduce: > > 1. create an empty Org mode file and open it as a Emacs buffer. > 2. Fill in Org content as bellowing > > #+begin_src org > * headline 1 :tag1:workflow: > > * headline 2 :tag2:name: > #+end_src > > 3. save buffer > 4. Press [C-c C-q] org-set-tag-command > 5. You can't see buffer local tags "tag1", "tag2", "workflow", "name" in tags > completion. I followed your steps starting from emacs -Q and also starting from make repro in Org git repo using Emacs master and Emacs 29. In all the cases, I am seeing all the buffer tags in the completion. I am unable to reproduce the problem. May you please provide steps to reproduce starting from emacs -Q using the latest bugfix or main branch of Org mode? -- 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>
Re: [FR] Please add custom command variable to org-latex-footnote-reference
Alexander Gogl writes:
> I completed the patch (see attachment). Please let me know if I made any
> mistake in the patch or if I should send the patch to another E-Mail-Address.
Thanks! We use Org mailing list (public) to send patches and discuss Org
mode development.
I added Org mailing list to CC in this email.
You can simply use "Reply All" to send the next version of the patch.
> Reason for patch
>
> Some LaTeX classes define their own footnote commands. For example, kaobook
> (https://github.com/fmarotta/kaobook/blob/master/example_and_documentation.pdf)
> has \footnotes and \sidenotes, whereby sidenotes (notes are put into the
> outter margin) are the dominant form of putting notes in kaobook. It would be
> great if you could make the footnote command in the footnote function
> customizable. My proposal is in the attachment.
You can put this description in the commit message.
Also, if you can, please add changelog entries, as described in
https://orgmode.org/worg/org-contribute.html#commit-messages
> Subject: [PATCH] added option to customize latex footnote command in export
What about
ox-latex: New option to customize LaTeX footnote command
My version (1) clearly states which library the patch is changing; (2)
Uses imperative tone as we usually do in commit messages.
> +*** New option ~latex-default-footnote-command~
> +
> +This new option allows you to define the LaTeX command the org-mode
> footnotes are converted to (for example ~\\sidenote{%s%s}~).
We use "Org mode" to name Org mode.
Also, we fill the text to default `fill-column' value of 70.
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 5c19e1fe7..b45d13ca2 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -135,6 +135,9 @@
> (:latex-default-table-environment nil nil
> org-latex-default-table-environment)
> (:latex-default-quote-environment nil nil
> org-latex-default-quote-environment)
> (:latex-default-table-mode nil nil org-latex-default-table-mode)
> +;; TODO implement options variable
May you explain the purpose of this TODO?
> +(:latex-default-footnote-command "\\footnote{%s%s}" nil
> org-latex-default-footnote-command)
"\\footnote{%s%s}" makes no sense in this context. The format of export
options is described in the docstring of `org-export-options-alist':
The key of the alist is the property name, and the value is a list
like (KEYWORD OPTION DEFAULT BEHAVIOR) where:
KEYWORD is a string representing a buffer keyword, or nil.
OPTION is a string that could be found in an #+OPTIONS: line.
DEFAULT is the default value for the property.
BEHAVIOR determines how Org should handle multiple keywords for
You placed "\\footnote{%s%s}" in KEYWORD slot, which is not right.
KEYWORD slot is what defines how to set the value locally. For example,
"AUTHOR" in (:author "AUTHOR" nil user-full-name parse) means that
:author export option can be set as
#+AUTHOR: value
> +(defcustom org-latex-default-footnote-command "\\footnote{%s%s}"
> + "Default command used to insert footnotes.
> + Customize this command if the LaTeX class provides a different notation
> command like `\\sidenote{%s%s}' that you want to use."
Please explain what is the meaning of each %s in the value in the
docstring.
Also, please re-fill the docstring to avoid long lines.
> + :group 'org-export-latex
> + :version "24.4" ;; FIXME enter correct version
:version is not needed. It is obsolete keyword we no longer use in the
new customizations.
--
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>
Re: [BUG] query-replace breaks org-mode [9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Joe Gilder writes: > Noticed this a few times. When I run query-replace, it functions as usual. > However, when I’m done with the query-replace, it seems to break org-fold. I > can’t fold/unfold headings anymore. > > I had the same issue the other day with replace-string as well. > > Killing buffer and coming back fixes it. You can set `org-fold-core-style' to 'overlays (early in your config) to fix this. Unfortunately, text-property based folding cannot be reliable because too many parts of Emacs and third-party packages hard-code certain implementation details. The default value of `org-fold-core-style' is changed to 'overlays on main to avoid this and similar problems. Handled. -- 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>
[POLL] Should we enable or disable automatic tag alignment by default everywhere
Dear all, We have ~org-auto-align-tags~ option that controls whether editing commands re-align the tags. However, this option is only respected by some editing commands, like changing the headline level. Many other editing commands re-align tags unconditionally. For example, when * typing right here or deleting inside a heading with :tag1:tag2: the :tag1:tag2: automatically remains aligned, regardless of the value of ~org-auto-align-tags~. In the attached patch, I am changing all the commands in Org mode, including "self-insert" and "delete-backwards" to respect this option. However, because ~org-auto-align-tags~ is disabled by default, this will cause breaking change - there are many more commands in Org mode that re-align tags unconditionally compared to the commands that do take it into account. I'd like to ask you, Org mode users, whether we should flip the default value of ~org-auto-align-tags~ to t or leave it as nil - flipping the default value will preserve the behavior described above, but change the default behavior of ~org-promote~, ~org-demote~, ~org-todo~, ~org-delete-indentation~, and ~org-return~. Keeping the value nil, will change the default behavior when typing/deleting inside headline, in ~org-mobile-edit~, ~org-insert-heading~, ~org-edit-headline~, ~org-priority~, ~org-entry-put~, ~org-kill-line~. Or maybe should we keep the status quo with ~org-auto-align-tags~ sometimes respected and sometimes not? >From 6f16612796076077c95176be0929677ffe8e0d3d Mon Sep 17 00:00:00 2001 Message-ID: <6f16612796076077c95176be0929677ffe8e0d3d.1713348551.git.yanta...@posteo.net> From: Ihor Radchenko Date: Wed, 17 Apr 2024 13:04:52 +0300 Subject: [PATCH] Respect `org-auto-align-tags' in all the editing commands * lisp/org-mobile.el (org-mobile-edit): * lisp/org.el (org-insert-heading): (org-edit-headline): (org-priority): (org-set-tags): (org-entry-put): (org-self-insert-command): (org-delete-backward-char): (org-delete-char): (org-kill-line): Only re-align tags when `org-auto-align-tags' is set to non-nil. * etc/ORG-NEWS (~org-auto-align-tags~ is not respected universally): Announce the breaking change. Link: https://orgmode.org/list/87msxoc3qp.fsf@localhost --- etc/ORG-NEWS | 10 ++ lisp/org-mobile.el | 2 +- lisp/org.el| 20 ++-- 3 files changed, 21 insertions(+), 11 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index e61bd6988..e6dc35f87 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -13,6 +13,16 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org. * Version 9.7 (not released yet) ** Important announcements and breaking changes +*** ~org-auto-align-tags~ is not respected universally + +Previously, only a subset of Org editing commands respected +~org-auto-align-tags~ option. Now, it is no longer the case. All the +editing commands, including typing (~org-self-insert-command~) and +deletion respect the option. + +~org-auto-align-tags~ is still disabled by default. Now, none of the +Org editing commands re-align tags to ~org-tags-column~ by default. + *** Underline syntax now takes priority over subscript when both are applicable Previously, Org mode interpreted =(_text_)= as subscript. diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el index 83e0316fd..b34623686 100644 --- a/lisp/org-mobile.el +++ b/lisp/org-mobile.el @@ -1057,7 +1057,7 @@ (defun org-mobile-edit (what old new) (goto-char (match-beginning 4)) (insert new) (delete-region (point) (+ (point) (length current))) - (org-align-tags)) + (when org-auto-align-tags (org-align-tags))) (t (error "Heading changed in the mobile device and on the computer"))) diff --git a/lisp/org.el b/lisp/org.el index a53f36d33..c4475cd62 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6565,7 +6565,7 @@ (defun org-insert-heading ( arg invisible-ok level) ;; Preserve tags. (let ((split (delete-and-extract-region (point) (match-end 4 (if (looking-at "[ \t]*$") (replace-match "") - (org-align-tags)) + (when org-auto-align-tags (org-align-tags))) (end-of-line) (when blank? (insert "\n")) (insert "\n" stars " ") @@ -6677,7 +6677,7 @@ (defun org-edit-headline ( heading) (if old (replace-match new t t nil 4) (goto-char (or (match-end 3) (match-end 2) (match-end 1))) (insert " " new)) - (org-align-tags) + (when org-auto-align-tags (org-align-tags)) (when (looking-at "[ \t]*$") (replace-match "" (defun org-insert-heading-after-current () @@ -11215,7 +11215,7 @@ (defun org-priority ( action show) (insert " [#" news "]")) (goto-char (match-beginning 3)) (insert "[#" news "] " - (org-align-tags)) + (when org-auto-align-tags (org-align-tags)))
Re: [BUG] org-open-at-point not presenting links within heading
Joe Gilder writes: > When cursor is in a heading, and I call org-open-at-point, it’s supposed to > (according to the documentation): > > “When point is on a headline, display a list of every link in the > entry, so it is possible to pick one, or all, of them.” > > That’s not happening. If the link is IN the heading, it follows the link. If > the link is in the “body” of the heading, it simply tells me “No link to open > here” _on_ a headline, which means that point must be on * Headline, but not inside the heading body Not a bug. Canceled. -- 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>
Re: [BUG] Invalid search bound (wrong side of point) [9.6.25 ( @ /Users/cchoi/.config/emacs/elpa/org-9.6.25/)]
Charles Choi writes: > Got this warning when running Org Agenda, thought I'd report it in. > > ⛔ Warning (org-element-cache): org-element--cache: Org parser error in > 2024_04_07.org::#. Resetting. > The error was: (error "Invalid search bound (wrong side of point)") Does it also happen on main? -- 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>
Re: [BUG] Warning (org-element-cache): org-element--cache: Org parser error [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]
Keith Waclena writes: > Since upgrading from Emacs v28 to v29 I get this error the first time I > pull up the agenda via M-x org-agenda: > > ⛔ Warning (org-element-cache): org-element--cache: Org parser error in > emacs.org::#. Resetting. > The error was: (error "Invalid search bound (wrong side of point)") > Backtrace: > nil > Please report this to Org mode mailing list (M-x org-submit-bug-report). > > The same error is repeated 15 times for 15 different agenda files (with > different marker values), once per file; most of these markers are at > end-of-file but not all of them. > > When the warning pop up emacs is spinning the CPU and is hung; at that > moment this command in the shell also hangs: > > $ emacsclient --eval '(top-level)' > > Emacs tells me to hit C-g 4 times to interrupt, and that works. > > After I interrupt it, my agenda works fine until I restart Emacs and > then it happens again. > > Any ideas / hints? Thanks! Thanks for reporting! May you try to upgrade to the development version of Org mode? -- 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>
Re: [BUG] Unescaped #+ lines in WORG example blocks (was: [PATCH] #+begin_example lang used in manual and worg (was: [DISCUSSION] Refactoring fontification system))
Ihor Radchenko writes: >>> -#+BEGIN_EXAMPLE org >>> +#+BEGIN_EXAMPLE >>> #+STARTUP: showall indent >>> #+STARTUP: hidestars >>> #+BEGIN_EXPORT html >> >> It is not the scope of this patch but looks like missed commas to escape >> leading "#". > > You are right. We need someone to look through worg pages and spot all > such instances. > (Help appreciated) https://git.sr.ht/~bzg/worg/commit/729b9679 -- 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>
Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
Juan Manuel Macías writes: > Pedro Andres Aranda Gutierrez writes: > >> I agree it does not take advantage of the AUTO facility here, but I >> nevertheless think it would >> be interesting to show people how to do this. Until we expand the AUTO >> facility to cope with >> all quirks of multi-language in pdflatex (lualatex and xetex are a >> different pair of shoes), a quick >> and dirty alternative may be helpful for people. The introductory text >> could be > > Pedro, the only problem I see with that is that it is an example of > LaTeX rather than Org. The only Org part here is #+LaTeX_header, and in > the entire section it's already made clear enough what it's used for. > > Perhaps a brief reminder (the AUTO facility of the previous examples > is very limited) could be added first, and that if the users want to > obtain more complex, or more specific results (like the case you > exemplify for pdfLaTeX) they must put explicit LaTeX code, using > LaTeX_header. And then your example would come, but emphasizing that the > LaTeX documentation must be consulted. wdyt? > > My point is that if we abuse examples of this type (at the expense of > "#+latex_header:something"), or "how is this done in LaTeX?", in the end > a LaTeX manual is made instead of Org. A gentle ping. This patch is still hanging in the air. -- 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>
Re: [PATCH v2] org-faq.org: Inline comments
Ihor Radchenko writes: >>>> +#+begin_src org >>>> +The following line may become a patagraph separator. >>>> +@@comment: might give unexpected effect @@ >>>> +Put some text before @@comment: a better variant >>>> +@@ and after instread. >>>> +#+end_src >>> >>> May you please elaborate? >>> If you see inline export block starting a paragraph, it is a bug. > ... > > As for comments, I tend to agree that it is indeed a bug. I am no longer able to reproduce the problem with @@comment:...@@ splitting paragraph in the above example. -- 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>
Re: [BUG] crash [9.7-pre (release_9.6.11-927-g819cd7 @ /home/minshall/.emacs.d/straight/build/org/)]
> You are on a fairly old common from main - 5 month old. *commit
Re: Using search options in HTTP-style links
Joseph Turner writes: > ... > (eww "https://ushin.org/needs-list.org#%3A%3A%23care;) > > ...loads the file in eww-mode with point at the top of the file. > > I think it would be more useful to instead activate org-mode (or a mode > which derives from it - "eww-org-mode"?), decode the link fragment, and > then jump to the location specified by the search option. There is a convention for pdfs: http://www.example.com/document.pdf#page=5 But, AFAIK, it is not RFC. So, there is nothing stopping from creating an ad-hoc convention to parse URL locators in links to PDFs or org files or whatnot. However, the question about activating a major mode on web content is a question to Emacs developers. It should be considered carefully, because activating major modes may not be safe. -- 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>
Re: [BUG] crash [9.7-pre (release_9.6.11-927-g819cd7 @ /home/minshall/.emacs.d/straight/build/org/)]
Greg Minshall writes: > i was editing a buffer, but it was in read-only mode, so i closed the > buffer and re-visited the file, then hit something like carriage return > and got the crash. > > (it's possible, i suppose, that i was doing some for of "org-capture" > for that buffer?) > > cheers. > > - > ⛔ Warning (org-element-cache): org-element--cache: Org parser error in > sysnotes.org::2622892. Resetting. > The error was: (error "org-element--cache: Emergency exit") Thanks for reporting! You are on a fairly old common from main - 5 month old. May you upgrade to the latest main and let us know if you keep seeing problems? -- 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>
Re: [BUG] org-speed-commands deleting headings when using mark-set [9.5.5 (release_9.5.5 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Joe Gilder writes: > I discovered the problem. I believe it has to do with (delete-selection-mode) > > When that mode is enabled, I get this behavior. When it is disabled, things > work as expected. > > Since I’m not technically typing anything when using speed commands, it > shouldn’t delete headings even with delete-selection-mode enabled. So maybe > it’s still a bug? Yes, it is. Fixed, on bugfix. For the next bugfix release. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4ae5cc018 -- 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>
Re: Attributes on images (was:: Experimental public branch for inline special blocks)
"Rick Lupton" writes:
>> #+attr_html: :height 300
>> [[file:image.png]] has a height of 300, but what if we want a
>> different height in @@[:html-height 300]{[[file:another-image.png]]}?
>>
>> Note how @@{...} markup assigns attributes to objects inside - the
>> attributes should be somehow inherited.
>
> This way of assigning a height to the image seems odd to me. Mostly, the
> attributes specified by the inline block apply to the block, not the
> contents, so wouldn't this case be potentially surprising?
We already have #+attr_html: :height 300 that applies to the whole
paragraph and it is not going anywhere. So, my idea is natural given the
existing convention.
And I explicitly suggested that attributes of anonymous inline blocks
@@[...]{...} will be inherited by all other markup. This is not just for
images, but in case if we want some extra configuration for other
traditional Org markup:
@@[:weight semi-bold]{All the *bold text here* will *be* semi-bold.}
Also, one may do something like
@@[:html-height 300]{This [[file:image.png]] and that
[[file:other-image.png]]}, but not third [[file:yet-another-image.png]].
> Both of these examples mean different things in HTML, and it seems like you
> might want to create either -- how would you control which was produced using
> the "@@[:html-height 300]{[[file:another-image.png]]}" syntax?
>
>
>
>
Anonymous inline markup will not at all be exported by itself. Its
purpose is to provide attributes or serve as back escape sequence.
So, I envision your examples as
@span{@@[:html-height 300]{}}
@span[:html-style height: 300]{}
> Instead, I wonder if the problem is that the way of inserting an image using
> a link itself. If you need more control, could there be a special "img"
> inline special block which can handle additional attributes?
>
> For example:
>
> Or, if using the original syntax, perhaps the attribute should be explicitly
> :img-attr or :img-height to resolve the ambiguity about which element is
> being targetted?
I do not have much of an opinion about the attribute names. If we need
to make them unique, that's totally fine and does not affect the overall
syntax design. I used image height simply as an illustration of the idea
of attribute inheritance. The above example with attributes for *bold*
is illustrating the same idea.
> @img[:height 300]{image.png} has a height of 300, and we can also have images
> with different heights and attributes like @img[:height 400 :alt "An
> image"]{another-image.png}.
This is also an option, although it allows setting attributes only for a
single image. Maybe we can modify the anonymous markup to make its
attributes be inherited by a subset of the markup inside:
@@[:parent-of link :height 300]{Only [[file:link.png]] inherits :height
attribute, but not @bold{other markup}}
This way, we can have some interesting options for ad-hoc markup like
#+inline_attr:tall: :parent-of link, latex-fragment :height 1000
@tall{All the images and latex inside will be tall:
\(x^2\)}
Another aspect of your example is that you implicitly suggested an
alternative link markup, which raises a more general question - should
we allow making the inline markup an alias of an existing markup?
This may require two alternative approaches:
a. Special treatment of certain inline markup names, like
@code{verbatim code}
@verbatim{...}
@bold{...}
@italic{...}
@underline{...}
@strikethrough{...}
@link[...]{path}{description}
(we need such special treatment to make sure that, for example,
@bold{...} in Org files can still be correctly exported by export
backends not aware about the new inline markup)
b. In addition to :export_template idea I proposed that would define
custom *per-backend* export rules, we will need some way to define
ad-hoc markup in terms of the more traditional Org markup:
@code{...} == ~code~
@bold{...} == *bold*
or even
@alert{...} == @bold{@italic{...}}
I personally feel that b is more powerful, but it is getting so close to
the idea of {{{macros}}} that we may confuse users.
--
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>
Re: [PATCH 1/2] org-capture: Allow entry template to start without heading
.205d09da8 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1356,13 +1356,14 @@ (defun org-capture-place-item ()
(defun org-capture-place-table-line ()
"Place the template as a table line."
(require 'org-table)
- (let ((text
- (pcase (org-trim (org-capture-get :template))
- ((pred (string-match-p org-table-border-regexp))
- "| %?Bad template |")
- (text (concat text "\n"
- (table-line-pos (org-capture-get :table-line-pos))
- beg end)
+ (let* ((template (org-trim (org-capture-get :template)))
+ (text
+ (pcase template
+ ((pred (string-match-p org-table-border-regexp))
+ (concat "| " template))
+ (text (concat text "\n"
+ (table-line-pos (org-capture-get :table-line-pos))
+ beg end)
(cond
((org-capture-get :exact-position)
(org-with-point-at (org-capture-get :exact-position)
diff --git a/testing/lisp/test-org-capture.el b/testing/lisp/test-org-capture.el
index 4e9139c40..f97d08bce 100644
--- a/testing/lisp/test-org-capture.el
+++ b/testing/lisp/test-org-capture.el
@@ -613,6 +613,16 @@ (ert-deftest test-org-capture/table-line ()
"| 2 |" :immediate-finish t
(org-capture nil "t"))
(buffer-string
+ ;; Prepend | when the template does not start with it
+ (should
+ (equal "| 1 |\n| 2 |\n"
+ (org-test-with-temp-text-in-file "| 1 |\n"
+(let* ((file (buffer-file-name))
+ (org-capture-templates
+`(("t" "Table" table-line (file ,file)
+ "2 |" :immediate-finish t
+ (org-capture nil "t")
+ (buffer-string)
;; When `:prepend' is nil, add the row at the end of the table.
(should
(equal "| a |\n| x |\n"
--
2.44.0
--
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>
Re: org-clone-subtree-with-time-shift with reverse order
Christian Barthel writes: > On the other hand: There are ways to specify the > ordering like org-reverse-note-order. Would it make > sense to have one global `org-reverse-order' that is > dealing with reversing "everything" that is somehow > dependent on ordering? The problem is that it is not very clear what to do when: org-clone-subtree-with-time-shift docstring: If the original subtree did contain time stamps with a repeater, the following will happen: ... - the original entry will be placed *after* all the clones, with repeater intact. So, the change is not trivial. -- 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>
Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]
Björn Bidar writes: >> Fixed, on main. Alongside with other similar places. >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=78e9dd0c4 > > I noticed after the change that captured links are not picked up. > > E.g.: > 1. I capture a link using org-protocol > 2. Switch to the org-buffer > 3. C-c C-l > 4. RET <- frame closes however links isn't inserted into the target > org-buffer May you provide more details about how to reproduce? -- 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>
Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx
Ihor Radchenko writes: > So, in the message I linked, Nicolas (the major Org mode contributor) > was not right. I hence need to fix the parser and update Org syntax > page. This includes fixing `org-element-clock-line-re' to account for > CLOCK: => 1:00 syntax. I changed the parser on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=17072a469 and updated the syntax ref https://git.sr.ht/~bzg/worg/commit/1c56837d -- 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>
Re: [BUG] bug in 'ox-man?
Greg Minshall writes: >> #+begin_src bash :results output :exports code :eval never-export >> echo 'lf "\n"' >> #+end_src > > it seems that `.man` files are in troff(1) format, which uses backslash > escapes up the wazoo (however that is spelled). it seems that (one way) > to getting a backslash character through troff is representing it as > "\e". > > for my *particular* instance, where the backslash is in an org src > block, the below modification to `(org-man-src-block)` may work. > > presumably one might have backslash sequences in example blocks, or in > the main text, or ...? i don't know enough to have any idea if there is > some general mechanism that might solve all those. See the attached tentative patch. >From ef3fa244d1a32c2cce3616a6dffc9c3dcafd4e34 Mon Sep 17 00:00:00 2001 Message-ID: From: Ihor Radchenko Date: Sun, 14 Apr 2024 14:05:59 +0300 Subject: [PATCH] ox-man: Escape backslash characters in verbatim examples * lisp/ox-man.el (org-man--protect-example): New helper function protecting special escape characters inside literal examples. (org-man-example-block): (org-man-inline-src-block): (org-man-src-block): (org-man-table): Protect contents that is intended to be rendered verbatim. Reported-by: Greg Minshall Link: https://orgmode.org/list/2924644.1643637...@apollo2.minshall.org --- lisp/ox-man.el | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/lisp/ox-man.el b/lisp/ox-man.el index 958740da8..cdd4fea7d 100644 --- a/lisp/ox-man.el +++ b/lisp/ox-man.el @@ -293,6 +293,13 @@ (defun org-man--protect-text (text) "Protect minus and backslash characters in string TEXT." (replace-regexp-in-string "-" "\\-" text nil t)) +(defun org-man--protect-example (text) + "Escape necessary characters for verbatim TEXT." + ;; See man groff_man_style; \e must be used to render backslash. + ;; Note that groff's .eo (disable backslash) and .ec (re-enable + ;; backslash) cannot be used as per the same man page. + (replace-regexp-in-string "" "\\e" text nil t)) + ;;; Template @@ -400,7 +407,7 @@ (defun org-man-example-block (example-block _contents info) (org-man--wrap-label example-block (format ".RS\n.nf\n%s\n.fi\n.RE" - (org-export-format-code-default example-block info + (org-man--protect-example (org-export-format-code-default example-block info) ;;; Export Block @@ -529,11 +536,11 @@ (defun org-man-inline-src-block (inline-src-block _contents info) (delete-file out-file) code-block) (format ".RS\n.nf\n\\fC\\m[black]%s\\m[]\\fP\n.fi\n.RE\n" - code + (org-man--protect-example code) ;; Do not use a special package: transcode it verbatim. (t - (concat ".RS\n.nf\n" "\\fC" "\n" code "\n" + (concat ".RS\n.nf\n" "\\fC" "\n" (org-man--protect-example code) "\n" "\\fP\n.fi\n.RE\n") @@ -749,7 +756,7 @@ (defun org-man-src-block (src-block _contents info) contextual information." (if (not (plist-get info :man-source-highlight)) (format ".RS\n.nf\n\\fC%s\\fP\n.fi\n.RE\n\n" - (org-export-format-code-default src-block info)) + (org-man--protect-example (org-export-format-code-default src-block info))) (let* ((tmpdir temporary-file-directory) (in-file (make-temp-name (expand-file-name "srchilite" tmpdir))) (out-file (make-temp-name (expand-file-name "reshilite" tmpdir))) @@ -772,7 +779,7 @@ (defun org-man-src-block (src-block _contents info) (delete-file in-file) (delete-file out-file) code-block) - (format ".RS\n.nf\n\\fC\\m[black]%s\\m[]\\fP\n.fi\n.RE" code) + (format ".RS\n.nf\n\\fC\\m[black]%s\\m[]\\fP\n.fi\n.RE" (org-man--protect-example code)) ;;; Statistics Cookie @@ -836,9 +843,10 @@ (defun org-man-table (table contents info) (format ".nf\n\\fC%s\\fP\n.fi" ;; Re-create table, without affiliated keywords. -(org-trim - (org-element-interpret-data - `(table nil ,@(org-element-contents table)) +(org-man--protect-example + (org-trim + (org-element-interpret-data + `(table nil ,@(org-element-contents table))) ;; Case 2: Standard table. (t (org-man-table--org-table table contents info -- 2.44.0 -- 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>
Re: Identical attributes id="text-table-of-contents" of div with role="doc-toc" when exporting to html when using tables of contents for multiple subheadings
Ihor Radchenko writes: >> div's for toc (with role="org-toc") in subheadings par 1 and par 2 get the >> same id : text-table-of-contents : > > Confirmed. > Timothy, could you take a look? > We could probably modify the id in `org-html-toc' when SCOPE is non-nil. Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b42867b5a -- 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>
Re: How does =org-md-item= produce the correct indentation for nested lists?
"Rohit Patnaik" writes: > #+BEGIN_SRC elisp > (concat bullet > ... > (and contents >(org-trim (replace-regexp-in-string "^" "" contents > #+END_SRC > > and I'm wondering why it's adding indentation in front of the bullet. > Naively, I > would expect the result of this snippet, for an unordered list to be something > like: > > =-[item contents]= > > That is, it concatenate the bullet, then three spaces (4 - length of bullet), > then another four spaces, then the contents of the item. Instead, what I see > is > a four-space indent, followed by the bullet and its padding, followed by the > item contents: > > =- [item contents]= > > This is the correct result, but I don't see how the code from ox-md.el > produces > that result. The code makes use of the CONTENTS. If you have nested lists - item - sub-item - sub-sub-item "sub-sub-item" transcoder will receive CONTENTS="sub-sub-item" and return - sub-sub-item then, "sub-item" transcoder will receive CONTENTS="sub-item" + output of nested transcoder - CONTENTS= sub-item - sub-sub-item and add 4 spaces to each line, except first: - sub-item - sub-sub-item then, item transcoder will receive the result of the two nested transcoders: CONTENTS= item - sub-item - sub-sub-item yielding - item - sub-item - sub-sub-item Hope, it clarifies things. -- 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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Alexander Adolf writes: >> In any case, making column views more flexible is welcome. >> [...] > > Lure me into contributing a patch? fair enough; I might just as well > give that a try. I presume I'd get some support here on this list? > And/or on IRC (e.g. libera.chat#org-mode)? Yup. You are free to ask questions on the mailing list. You may also try to ask questions in IRC or Matrix: - https://web.libera.chat/#org-mode - https://matrix.to/#/%23org-mode:matrix.org Or even live, during online meetup: - https://list.orgmode.org/18ed37bf7da.110d936ff448640.1616496967933735...@excalamus.com/T/#t See https://orgmode.org/worg/org-contribute.html for more instructions. > I have signed FSF copyright assignment for all of Emacs, so I guess > nothing would need to be done at the paperwork level? Org mode is a part of Emacs. So, your copyright assignment for Emacs is enough. -- 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>
Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx
Morgan Smith writes: >>> - (goto-line 2) >>> + (insert (org-test-clock-create-clock ". 1:00" ". 2:00") >>> + "CLOCK: => 1:00\n") >> >> This is not a valid clock format. Matching such lines is a bug. >> See https://list.orgmode.org/orgmode/87wpkkhafc.fsf@saiph.selenimh/ > > Let me preface this defense with the fact that I don't like this format > and I don't think we should support it. Rewriting `org-clock-sum' would > be much easier if we drop support for it. However, I do believe we > currently support it. > > First of all, it currently does work. > > Accord to the "Version 4.78" release notes as found on worg, this is > valid. > > ``` >- You may specify clocking times by hand (i.e. without > clocking in and out) using this syntax. > > : CLOCK: => 2:00 > > Thanks to Scott Jaderholm for this proposal. > ``` This is convincing. I did not know that this format is explicitly mentioned in the news. Our general rule is that we do not drop existing features in Org mode except extraordinary circumstances: https://bzg.fr/en/the-software-maintainers-pledge/ Especially when they are documented. So, in the message I linked, Nicolas (the major Org mode contributor) was not right. I hence need to fix the parser and update Org syntax page. This includes fixing `org-element-clock-line-re' to account for CLOCK: => 1:00 syntax. Luckily, it does not look like we are going to break the existing external exporter packages as long as they are using ox.el API - `org-export-translate' works just fine with missing timestamps. > Also last time I went to rewrite `org-clock-sum' you said > (https://list.orgmode.org/orgmode/87bkg7xbxo.fsf@localhost/): > > ``` > Further, you dropped the > >((match-end 4) > ;; A naked time. > > branch of the code, which accounts for CLOCK: => HH:MM lines that are not > clock elements. > ``` Yup. Although I did not see Nicolas' message that time. My judgment was simply based on looking at the code and seeing that CLOCK: => HH:MM matching was clearly intentional. -- 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>
Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]
Anush V writes: > Thanks for outlining your steps. I’ve added an additional step > (5). Here's the updated sequence: > ... > 5. M-: (setq org-startup-numerated t) Then, it looks like a duplicate of https://list.orgmode.org/orgmode/caedgbw4gmfmpt4-w6edrh7poapd5drarbtusfulrq7vbvtu...@mail.gmail.com/ There is no bug on the latest development version of Org mode (main). -- 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>
Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx
Morgan Smith writes: > See two attached patches. All tests pass on my computer. > > Every once in a while I feel obligated to go back to org-clock-sum to > try and optimize it. I have a file with 8 clocktables in it and it > takes forever to update. This time I decided instead of trying to > optimize, I'm just going to try and understand. > > The regex has been altered slightly. > > 1. Instead of using "[ \t]", I decided to use [[:blank:]]. No real > reason. I just think it's easier to read and maybe slightly more > correct? > > 2. For the timestamps, instead of ".*?" (using a non-greedy ".*") I > decided to use "[^]]*" (accept everything except "]"). I did this simply > because I'm not used to using non-greedy regex's. Maybe this way > performs better? I didn't test that. > > 3. I used the variable `org-outline-regexp' but that doesn't actually > change the regex. Thanks for the patch! I think that a better approach would be re-using the parser constant `org-element-clock-line-re'. > * testing/lisp/test-org-clock.el (test-org-clock/clocktable/insert): > Add a clock time that does not include timestamps. > ... > - > - (goto-line 2) > + (insert (org-test-clock-create-clock ". 1:00" ". 2:00") > + "CLOCK: => 1:00\n") This is not a valid clock format. Matching such lines is a bug. See https://list.orgmode.org/orgmode/87wpkkhafc.fsf@saiph.selenimh/ -- 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>
Re: PATCH allow explicit style= in #+cite_export: biblatex
Pedro Andres Aranda Gutierrez writes: > HI, > Attached is a small patch to allow explicitly adding style= in the biblatex > export options, to increase consistency with > Customisation variables. Thanks! > (style-options > (cond >((null style) nil) > + ;; allow the user to include "style=" anywhere in the style options > + ((string-match "\\(^s\\|,s\\)tyle=" style) (list style)) >((not (string-match "/" style)) (list (concat "style=" style))) >(t > (list (concat "bibstyle=" (substring style nil (match-beginning > 0))) If we allow style=..., may as well allow bibstyle= and citestyle=. -- 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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Alexander Adolf writes:
>> In fact, CLOCKSUM property does not support custom summaries.
>
> ???
AFAIU, you cannot do %CLOCKSUM{max}.
>>> Is there any way to change the summation behaviour for either or both
>>> column types?
>>
>> It is currently hard-coded. (Although, it is not too hard add some kind
>> of switch).
>> [...]
>
> I think that instead of a switch, I would prefer the columnview dblock
> to get a :formatter added. Knowing how the values have been computed in
> the dblock's write function, I can re-calculate whatever data I need in
> the formatter.
>
> I am already using this approach successfully with the clocktable dblock
> to generate invoices for me.
>
> Compared to a new switch, it would seem to me that adding a :formatter
> to the columnview dblock has several advantages:
>
> - it would likely be a smaller code change;
>
> - instead of implementing a single, new behaviour (activated by switch)
> it would give users the flexibility to implement any new behaviour
> they might want (user-supplied :formatter function).
>
>
> Thus, from my point of view, having a :formatter for the columnview
> dblock would be quite fabulous. 濾
This will not prevent the property values from being changed by column
view.
In any case, making column views more flexible is welcome.
--
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>
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
Protesilaos Stavrou writes: > With regard to the disambiguation scheme, I am playing around with > various scenaria to see how Org HTML export behaves. Using the > following: > ... > This is test 2 role="doc-backlink">1 > ... > This is test 3 role="doc-backlink">1 > > Notice that the 100 in the ID is not incremented further. I guess this > is something that can be worked on but, again, I think it is separate > from the issue of using the label for the ID and HREF. > > Any thoughts? Duplicate IDs are against HTML spec: https://softwareengineering.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really So, this is a bug. >>> Though I should have clarified my intent earlier: the idea is to use the >>> label as a fixed reference to the footnote, so that the link does not >>> change between exports. This is the same principle as what we do with >>> links to headings that have a CUSTOM_ID. >>> >>> As such, the anchor text can still be the way it is now as an >>> automatically generated number sequence (^1, ^2, etc.), but the HTML >>> "id" and "href" values will be constructed based on the label of the >>> footnote, NOT its number in the sequence. See the attached tentative patch. >From 446bfc8c8afb5b2e09d0e0acf7b136b9f0780f5a Mon Sep 17 00:00:00 2001 Message-ID: <446bfc8c8afb5b2e09d0e0acf7b136b9f0780f5a.1713016519.git.yanta...@posteo.net> From: Ihor Radchenko Date: Sat, 13 Apr 2024 16:53:48 +0300 Subject: [PATCH] ox-html: Use non-number footnote names as link anchors * lisp/ox-html.el (org-html-footnote-section): * lisp/ox-html.el (org-html-footnote-reference): When footnote has a non-number name, build link anchors using this name. * etc/ORG-NEWS (=ox-html=: When exporting footnotes with custom non-number names, the names are used as link anchors): Announce the change. Link: https://orgmode.org/list/875xwngiwx@protesilaos.com --- etc/ORG-NEWS| 8 + lisp/ox-html.el | 77 + 2 files changed, 53 insertions(+), 32 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index e61bd6988..1b7040815 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -13,6 +13,14 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org. * Version 9.7 (not released yet) ** Important announcements and breaking changes +*** =ox-html=: When exporting footnotes with custom non-number names, the names are used as link anchors + +Previously, link anchors for footnote references and footnote +definitions were based on the footnote number: =fn.1=, =fnr.15=, etc. + +Now, when the footnote has a non-number name, it is used as an anchor: +=fn.name=, =fnr.name=. + *** Underline syntax now takes priority over subscript when both are applicable Previously, Org mode interpreted =(_text_)= as subscript. diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 0471a573b..1262da1aa 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -1873,36 +1873,42 @@ (defun org-html-footnote-section (info) (pcase (org-export-collect-footnote-definitions info) (`nil nil) (definitions + (format + (plist-get info :html-footnotes-section) + (org-html--translate "Footnotes" info) (format - (plist-get info :html-footnotes-section) - (org-html--translate "Footnotes" info) - (format - "\n%s\n" - (mapconcat - (lambda (definition) - (pcase definition - (`(,n ,_ ,def) - ;; `org-export-collect-footnote-definitions' can return - ;; two kinds of footnote definitions: inline and blocks. - ;; Since this should not make any difference in the HTML - ;; output, we wrap the inline definitions within - ;; a "footpara" class paragraph. - (let ((inline? (not (org-element-map def org-element-all-elements -#'identity nil t))) - (anchor (org-html--anchor - (format "fn.%d" n) - n - (format " class=\"footnum\" href=\"#fnr.%d\" role=\"doc-backlink\"" n) - info)) - (contents (org-trim (org-export-data def info - (format "%s %s\n" - (format (plist-get info :html-footnote-format) anchor) - (format "%s" -(if (not inline?) contents - (format "%s" - contents - definitions - "\n")) + "\n%s\n" + (mapconcat + (lambda (definition) + (pcase definition + (`(,n ,label ,def) + ;; Do not assign number labels as they appear in Org mode + ;; - the footnotes are re-numbered by + ;; `org-export-get-footnote-number'. If the label is not + ;; a number, keep it. + (when (equal label (number-to-string (string-to-number lab
Re: [BUG] A custom org-num-format-function causes org-latex-preview warn when it called. [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]
Garid Zorigoo writes: > * To Reproduce > > 1. Change the org-num-format-function as written above > 2. (In org-file) Turn-on ~org-num-mode~ > 3. (In org-file) On any equation, change it. > 4. run ~org-latex-preview~ to preview the equation image. > 5, run ~org-latex-preview~ go back to text mode. (here warning comes) > (If warning doesn't appear try from step 3 again) > (When org-num-mode turned off, it doesn't produce warning) > >$\alpha$ Thanks for reporting! I was able to reproduce using the provided steps using the built-in Org mode version and using the latest stable Org mode version. However, I am unable to reproduce using the latest development Org mode version. -- 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>
Re: [FR] :noweb-wrap header arg
Amy Grinn writes: >>> +(while (< (point) (point-max)) >>> + (unless (looking-at " *\"\\([^\"]+\\)\" *") >>> +(looking-at " *\\([^ ]+\\)")) >> >> May you please explain the rationale behind this regexp? AFAIU, it >> implies that you want to allow whitespace characters inside :noweb-wrap >> boundaries. But I do not think that we need to complicate things so much. > > That is exactly what I was going for. I thought about the ways this > could be used and the most general-purpose, non-syntax-breaking, > easily-recognizable way I could think of was to use the language's > line-comment construct followed by the standard << >> characters. > > # <> > ;; <> > // <> > > I can see how it might be harder to maintain to allow whitespace in the > noweb-wrap header arg. I could create a separate org-parse-arg-list > function to ease that burden somewhat. My opinion is that having the > option to use the examples above is preferable to using non-standard > wrappers, from a third-person point-of-view. Makes sense. Also, see a similar idea being discussed in https://list.orgmode.org/orgmode/87o7jlzxgn.fsf@localhost/ I recommend the following: If the value starts from ", use Elisp's `read': |"# <<" ">>" (read (current-buffer)) ; => "# <<" otherwise, consider read until the first whitespace. |#<<; >>; (re-search-forward (rx (1+ (not whitespace #<<;| However, there may be edge cases like "<< >>" "<< >> << << >> << "asd" >> -- 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>
Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]
Anush V writes: >> Thanks for reporting! >> I tried to follow your steps, but I am unable to reproduce the problem. >> May you please attach the exact problematic Org file, so that we can >> make sure that we do the same thing? > > Thanks for the prompt response. > > Please find the attached file tmp.org. > > Please ensure that the LaTeX preview image for the equation ($\alpha$) > is not in the directory specified by org-preview-latex-image-directory. > This warning appears when you generate a preview image that is not > already present in the directory specified by > org-preview-latex-image-directory. I should have clarified this in the > initial email. Apologies for any confusion. I did the following: 1. Save your file to /tmp/ 2. rm -rf /tmp/ltximg 3. emacs-29 --version GNU Emacs 29.3 Copyright (C) 2024 Free Software Foundation, Inc. 4. emacs-29 -Q 5. C-x C-f /tmp/tmp.org 6. C-n 7. C-c C-x C-l 8. C-c C-x C-l 9. I do not observe any warnings -- 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>
Re: (error "Listing directory failed but ‘access-file’ worked")
Edgar Lux writes:
> I got this in an Org file:
>
> #+begin_src org
> [[file:Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg]]
> [[file:Figures/Ti19-g(w, eta={0.1,}, R=1e-3).png]]
> #+end_src
>
> The files exist, and can be viewed in image-mode (tested with src_bash{emacs
> -q}).
> With =C-c C-o= src_emacs-lisp{(org-open-at-point)}, the result is:
>
> #+begin_example
> Debugger entered--Lisp error: (error "Listing directory failed but
> ‘access-file’ worked")
> ...
> dired("Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg")
> ...
> org-link-open-as-file("Figures/Ti19-g(w, eta={0.1,}, R=1e-3).svg" nil)
Thanks for reporting!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6cb088972
--
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>
Re: [BUG] Org parser error when removing latex preview [9.6.15 (release_9.6.15 @ /gnu/store/gnvv2a1nxfbibkm1wdxdv6bd6mhk4cf8-emacs-29.3/share/emacs/29.3/lisp/org/)]
Anush V via "General discussions about Org-mode." writes: > Below are the steps to replicate the issue: > > Start emacs by running "emacs --no-init". > > Set the org-startup-numerated variable to true with the command (setq > org-startup-numerated t). > > Create a new file named tmp.org and insert the following content: > > - H > $\alpha$ > > To view the latex equation, place the cursor on the equation and press > the shortcut C-c C-x C-l to run org-latex-preview. This will display > the latex preview. > > Press C-c C-x C-l again to remove the latex preview and receive the > warning: > > > > ■ Warning (org-element-cache): org-element--cache: Org parser error in > tmp.org::11. Resetting. > The error was: (error "Invalid search bound (wrong side of point)") > Backtrace: nil > Please report this issue to the Org mode mailing list using M-x > org-submit-bug-report. Thanks for reporting! I tried to follow your steps, but I am unable to reproduce the problem. May you please attach the exact problematic Org file, so that we can make sure that we do the same thing? -- 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>
Re: [PATCH] Ensure org-table-header displays without cursor inside table
Bastien Guerry writes: > Ihor Radchenko writes: > >> P.S. Bastien, may your please check Lei Zhe's copyright status? > > Yes, I confirm Lei Zhe copyright status is okay. Applied, onto bugfix. I amended the commit author field to contain the https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5128460f9 full name. Lei Zhe, you are now listed as an Org contributor. Thank you! https://git.sr.ht/~bzg/worg/commit/104102ff -- 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>
Re: [PATCH] org-faq.org: rename org-export-htmlize-* options to org-html-htmlize-*
Ihor Radchenko writes: > Rudolf Adamkovič writes: > >> While you are on it, ... >> ... > > See the attached updated patch. Applied, onto master. https://git.sr.ht/~bzg/worg/commit/dcb2c11c -- 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>
Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]
Daniel Kraus writes: > Eric S Fraga writes: > >> On Monday, 15 Nov 2021 at 00:03, dal-bla...@onenetbeyond.org wrote: >>> So if we want to make org cooperate with window.el we must ban theses >>> functions and instead delegate the window management with calls to >>> proper display functions. >> >> I agree completely. One of my bug-bears is org-capture which I often >> use during meetings to take notes or create TODO items. Typically, the >> org capture window covers my Teams buffer (I use exwm as my window >> manager...) which is rather annoying. >> >> I did play with display-buffer-alist but it seemed to not be able to >> take control of some of org's windows. Everything else I do in Emacs is >> nicely managed through that alist. > > Just want to mention that I would also really appreciate this. > I asked for it ~4 years ago on this list > https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00241.html > and it also comes up from time to time in other places > like this Reddit thread > https://www.reddit.com/r/emacs/comments/ic4u1m/stop_emacs_from_hiding_other_windows_when/ I believe that `display-buffer-alist' is fully obeyed now by Org mode (on main branch). A few exceptions are when `org-agenda-window-setup' or/and `org-src-window-setup' are customized to non-default value - then Org does what the user asked for. -- 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>
Re: Verbatim content (inline-special-block)
Max Nikulin writes:
>> It may be enough to have @kbd{@code{...}} - it is not like Texinfo has a
>> concept of truly verbatim text like in Org.
>>
>> Alternatively, we may allow two classes of inline markup:
>> @foo{parsed *text* inside}
>> and
>> @foo={verbatim *text* inside}/@foo~{verbatim *text* inside}
>>
>> This way, instead of @code{}, we should use @code~{...} or even
>> @~{...}/@={...} (mnemonics for ~...~ and =...=)
>
> I consider @foo={}-like variants as unnecessary complications of the
> inline special block feature. The idea of composition is better from my
> point of view. With this approach it is enough to have non-conflicting
> syntax for non-parsed fragments. I am against making @code{} a special
> name with suppressed markup parsing. The price of composition in
> comparison with @foo={} is more verbose markup.
Then, do you have an idea about such syntax?
One option I thought of was making @foo{=...=} a special type of boundary
delimiting non-parsing contents. However, it is not very elegant IMHO.
> By the way, Org has src_lang{...} syntax for almost non-parsed fragments
> (neglecting requirement of balanced curly brackets that is an issue).
Yes, but it is handled differently by exporters from =verbatim=/~code~.
In fact, even the idea with @foo{@code{...}} may be problematic in this
regard - @code{...} inside, if we treat it as an equivalent of ~code~,
may be problematic if some export backends do something unusual about
code markup.
> Actually "=" in @foo={} is a kind of special argument distinct from ones
> specified inside [] and {}.
Yes, but it is much easier to parse. If we use a proper attribute, we
run into all kind of issues with how consistent it should be with the
parsing rules for other attributes (should it be inherited? may it
appear in arbitrary place in [...]?). And if we make it special, we will
run in various special cases in the parser...
>>> @code{def calculate(@param{expr}, @param{env})}
> [...]
>> Also, the reason why Texinfo users do @param in @code is the lack of
>> automatic syntax highlighting, unlike in Org mode.
>
> Is ox-texinfo able to convert syntax highlighting to native texinfo markup?
No.
> So if @markup{} is not allowed in verbatim content then it is another
> feature loosely related to custom inline blocks.
May you elaborate?
--
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>
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
Jim Porter writes: > On 2/5/2024 7:07 AM, Ihor Radchenko wrote: >> It would make sense to add a number of alists: >> - bounds-of-thing-at-point-provider-alist >> - same for 'forward-op, 'beginning-op, 'end-op. >> >> After Emacs have those, we can add Org mode support. > > That sounds reasonable enough to me; does anyone else have opinions on > this? Otherwise, I'll get to work on a patch (though probably not for a > couple weeks). It has been a while since the last message in this thread. Jim, may I know if you had a chance to work on the patch? -- 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>
Re: Bug: inconsistent handling of empty duration cells in table [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210816/)]
Jeff Trull writes: > When calc formulas producing empty strings are evaluated in the default > mode, an empty cell is produced. When evaluated in duration mode (U, T, > or t) a zero duration is produced. I feel the behavior should be > consistent with the number formats, producing a empty value instead of a > zero. Fixed, on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c27412899 -- 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>
Re: [BUG] Customizing org-emphasis-alist does not work as expected [9.6.15 (release_9.6.15 @ d:/emacs_home/program/emacs/share/emacs/29.2/lisp/org/)]
Max Nikulin writes: >> I have updated the docstring to explain this. >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=42cdf2a90 > > Have you decided to discard another variant that warns users? > > Ihor Radchenko… [PATCH v5] org.el: Warning for unsupported markers in > `org-set-emphasis-alist' Thu, 02 Feb 2023 10:53:20 +. > https://list.orgmode.org/87r0v8pcdb.fsf@localhost In that thread, the decision has been made to obsolete `org-emphasis-alist'. However, I postponed its implementation until after the new font-lock engine. -- 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>
[no subject]
Sébastien Gendre writes: > When I try to execute a block of PlantUML in an Org document, I get an > error message: > > "org-babel-execute-src-block: No org-babel-execute function for plantuml!" > ... > (add-to-list > 'org-babel-load-languages > '(plantuml . t)) Just use (require 'ob-plantuml). To use `org-babel-load-languages', you should either set it before loading Org mode or run `org-babel-do-load-languages' manually, as described in "16.9 Languages" section of the manual. -- 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>
Re: org-clone-subtree-with-time-shift with reverse order
Christian Barthel writes: > I'd like to suggest adding a new prefix arg i.e. > `C-u C-u org-clone-subtree-with-item-shift' to reverse > the order of newly created / cloned siblings. Would > that be of interest for other orgmode users? May you explain your use case a bit more? -- 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>
Re: [FR] :noweb-wrap header arg
Amy Grinn writes: > First of all, I would like to change (defalias) the function name > org-babel-noweb-wrap to org-babel-noweb-make-regexp. I think this in > more in line with other functions which create regular expressions. +1 You may even use obsolete alias (add it to lisp/org-compat.el) > Second, the command org-babel-tangle-clean is not able to determine > which noweb syntax is being used in any tangled source file because the > header arguments are not tangled along with the source code. > > My proposal is to add an additional warning to this command, stating: > > """ > Warning, this command removes any lines containing constructs which > resemble Org file links or noweb references. It also cannot determine > which noweb syntax is being used for any given source file, if > :noweb-wrap was specified in the original Org file. > """ Makes sense. Ideally, this function should try to follow the link and lookup code block headers, but it is already short of doing this. Improving `org-babel-tangle-clean' is out of scope of your patch. > +(defun org-babel-get-noweb-wrap ( info) > + "Retrieve a description the :noweb-wrap header arg from INFO. > + > +The description will be in the form of a list of two of strings > +for the start and end of a reference. INFO can be the result of > +`org-babel-get-src-block-info' otherwise this function will parse > +info at point." > + (unless info > +(setq info (org-babel-get-src-block-info 'no-eval))) > + (when-let ((raw (cdr (assq :noweb-wrap (nth 2 info) > +(let (result) > + (with-temp-buffer Please, avoid creating throwaway buffers and work with strings instead. Creating buffers (even temporary buffers) may be costly for some users who heavily customized buffer hooks. > +(insert raw) > +(goto-char (point-min)) > +(while (< (point) (point-max)) > + (unless (looking-at " *\"\\([^\"]+\\)\" *") > +(looking-at " *\\([^ ]+\\)")) May you please explain the rationale behind this regexp? AFAIU, it implies that you want to allow whitespace characters inside :noweb-wrap boundaries. But I do not think that we need to complicate things so much. -- 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>
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Alexander Adolf writes:
> it seems that the time summing behaviour of columnview dynamic blocks is
> different for CLOCKSUM than for EFFORT columns with respect to how the
> contributions from sub-headlines are handled. When summing up CLOCKSUM
> columns, a parent headline can have its own clocked time, which gets
> added to the sum of its sub-items' clocked times to produce its CLOCKSUM
> value. When summing up EFFORT columns, any effort a parent headline may
> have been manually assigned gets overwritten with the sum of its
> sub-items' efforts, however. In the example at the end of this message,
> compare the results for tasks A and D. If you change the effort for
> either task B or C, and then update the dynamic block, the EFFORT in the
> property drawer of task A will get overwritten with the new sum of B's
> and C's efforts.
>
> I'd have two questions regarding this:
>
> Does anyone recall the rationale for this different behaviour?
The "default" behaviour is to store summary of all the child property
value in each parent.
For example, starting from
#+COLUMNS: %ITEM%EFFORT{:}
* 1
:PROPERTIES:
:EFFORT: 0:00
:END:
** 1.1
:PROPERTIES:
:EFFORT: 0:20
:END:
** 1.2
:PROPERTIES:
:EFFORT: 0:20
:END:
after generating column view, you will get
* 1
:PROPERTIES:
:EFFORT: 0:40
:END:
...
This is, however, not possible for CLOCKSUM because clocksum is not an
actual property, but a "special" one - it is derived from logbook data.
That's why its behavior is different.
In fact, CLOCKSUM property does not support custom summaries.
> Is there any way to change the summation behaviour for either or both
> column types?
It is currently hard-coded. (Although, it is not too hard add some kind
of switch).
--
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>
Re: [PATCH] lisp/org-element.el: Add repeater-deadline support to org-element
DELAY (optional) :: An instance of the following pattern: #+begin_example MARK VALUE UNIT #+end_example Where MARK, VALUE and UNIT are not separated by whitespace characters. - MARK :: Either =-= (all type) or =--= (first type). - - VALUE :: A number + - VALUE :: A number. - UNIT :: Either the character =h= (hour), =d= (day), =w= (week), =m= -(month), or =y= (year) +(month), or =y= (year). *Examples* @@ -1807,6 +1807,7 @@ ** Timestamps [2004-08-24 Tue]--[2004-08-26 Thu] <2012-02-08 Wed 20:00 ++1d> <2030-10-05 Sat +1m -3d> +<2012-03-29 Thu ++1y/2y> #+end_example ** Text Markup -- 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>
Re: Verbatim content (inline-special-block)
Max Nikulin writes:
>> - We should be able to define special markup for code, where the
>> contents is not parsed. Something like
>>
>> @code{ unlike =code=, we can have leading and trailing spaces }
>> @code{ @foo{is not interpreted inside}}
>
> I think, it should be controlled by some optional parameter like
>
> @kbd[:verbatim t]{ unlike =code=, ... }
I do not like this idea - this will make the attribute list a part of
the Org markup spec, which I would like to avoid if possible:
1. External parsers would be forced to understand the attribute syntax,
which will complicate Org markup spec.
2. Our own parser may have to account for attribute inheritance while
parsing, which will complicate the parser too much.
The question remains how to define custom verbatim markup, of course.
It may be enough to have @kbd{@code{...}} - it is not like Texinfo has a
concept of truly verbatim text like in Org.
Alternatively, we may allow two classes of inline markup:
@foo{parsed *text* inside}
and
@foo={verbatim *text* inside}/@foo~{verbatim *text* inside}
This way, instead of @code{}, we should use @code~{...} or even
@~{...}/@={...} (mnemonics for ~...~ and =...=)
> Certainly parsing of normal Org markup should be suppressed,
> however I am less sure concerning @markup{}. In the following example
> text inside @param{} may be emphasized:
>
> @code{def calculate(@param{expr}, @param{env})}
>
> "@" inside such object may be escaped as @{@}. An alternatively is a
> parameter like :parse that can have values like "markup", "custom",
> "verbatim". This case "verbatim" disabled parsing of @objects().
AFAIU, you are referring to how Texinfo handles its @code{...} command,
where other texinfo commands are allowed, which is _conceptually_
different from how Org handles the verbatim/code - as a general rule,
all the "code" in Org mode syntax is taken verbatim (with the only
exception of src blocks where we have no choice).
Also, the reason why Texinfo users do @param in @code is the lack of
automatic syntax highlighting, unlike in Org mode.
I think that Org mode's equivalent of Texinfo @code should be either
1. inline src block
2. if direct markup is unavoidable, use something like
@fixedwidth{@code{def calculate(}@param{expr}@code{, }@param{env}@code{)}}
Most of the @code{..} can be safely dropped. It is just to illustrate
the idea that we still parse the contents.
In practice, things like
*def* calculate(expr, env) "foo\alpha"
will become
@fixedwidth{*def@code{*} calculate(@param{expr}, @param{env})
"foo@code{\}alpha"}
or
@fixedwidth{\star{}def* calculate(@param{expr}, @param{env}) "foo\@@{}alpha"}
--
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>
Re: Experimental public branch for inline special blocks
Juan Manuel Macías writes: > The latest added to the branch are Maxim's proposals (and code) for > backend control. See this thread: > > https://list.orgmode.org/?t=20240321102752 > > And this other thread, continuation of the previous one: > > https://list.orgmode.org/877ciavnwo.fsf...@posteo.net/ I have seen these two branches and my comments account for them. -- 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>
Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))
(it's read-only too). We usually "hide" fields by declaring them private. Hiding them from the type docs is not a good idea because it defeats the purpose of type documentation in general. > The fields anchor-ovl, region-ovl, on-outcome, set-status and > creation-point are the dump of the closure context, so that > org-pending doesn't rely anymore on a closure to handle updates; I've > rewritten that recently. Nobody is supposed to use or change those > values, except the update process. > > IMHO, dumping those as fields in the lock structure would be more > confusing and fragile than keeping those out of sight. I could add > comments when they are created/used in the code to help understand how > they are used. I disagree. In particular, I dislike the fact that they are not documented anywhere and one has to read the internals of the code to understand their purpose. -- 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>
Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]
Protesilaos Stavrou writes: > Though I should have clarified my intent earlier: the idea is to use the > label as a fixed reference to the footnote, so that the link does not > change between exports. This is the same principle as what we do with > links to headings that have a CUSTOM_ID. > > As such, the anchor text can still be the way it is now as an > automatically generated number sequence (^1, ^2, etc.), but the HTML > "id" and "href" values will be constructed based on the label of the > footnote, NOT its number in the sequence. > > What do you think? That may work. One may simply change the anchors for footnote references and footnotes when they are labeled. However, we should be careful when labels are duplicated (multiple references to the same named footnote) - only a single back-reference is possible from the footnote definition back to footnote reference. -- 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>
