Re: Concatenate properties
Tyler Grinn writes: > Thanks for the advice. I've added the caret symbol (:EXPORT_FILE_NAME^: > assignment-1) to mean 'concatenate' as opposed to + for 'joining'. If > this is something the community would want I will clean it up and send > in a patch. Hmm. I am not sure if it going to be a straightforward patch. You may need to update org-element parser accordingly. Also, I do not like the idea of extending org syntax with :PROPERTY^:. It may be easier to introduce a variable similar to org-use-property-inheritance where the user can customise how to accumulate parent properties. Best, Ihor
Re: org-fold problems
Eric S Fraga writes: > I am seeing very strange and somewhat frustrating behaviour with the new > org-fold implementation. I have not been able to determine the exact > conditions leading to the problem but some subtrees cannot be revealed > by either org-cycle or org-fold-reveal and act as if the have no content > (even when they do). However, the content can be revealed if I search > for some text, text I know is in the hidden content. > > I'm busy with a deadline so cannot do more investigation at this point. While you are at the deadline, feel free to switch org-fold-core-style back to overlays. If you get some time and encounter the described issue, can you try to run M-: (setq org-fold-core-first-unfold-functions nil) and try org-reveal again? Best, Ihor
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Ignacio Casso writes: >> Sounds reasonable. Could you prepare a patch? >> COMMENT should be inside a shy group and note that there might be an >> arbitrary number of space after COMMENT string. > > Here it is. Thanks! Could you also update the org-complex-heading-regexp-format docstring and make the commit massage conform with https://orgmode.org/worg/org-contribute.html#commit-messages (also see https://orgmode.org/list/87ilqz14ys.fsf@localhost)? Best, Ihor
Re: org-fold documentation
Samuel Wales writes: > so one would not be able to load all of org then compile? Not using native-comp, AFAIK. Best, Ihor
Re: [PATCH] New LaTeX code export option: engraved
Timothy writes:
Thanks for the updated patch! See some more comments below.
> +The first two options provide basic syntax
> +highlighting (listings), or none at all (verbatim).
> ...
> -Alternatively,
> +There are two options for more comprehensive fontification. The
> +first can be set with,
Maybe "The other two options"? Also, using first/second here is a bit
confusing because: (1) they are actually 3/4 in the above list; (2)
engraved is listed last.
> +The second more comprehensive option can be used with,
*can be set with
> -causes source code to be exported using the minted package as
> -opposed to listings. If you want to use minted, you need to add
> -the minted package to `org-latex-packages-alist', for example
> +which causes source code to be exported using the minted package
> +as opposed to listings. If you want to use minted, you need to
> +add the minted package to `org-latex-packages-alist', for example
> using customize, or with
I feel slightly confused about using the word "package" here. Which one
refers to LaTeX package and which one to Emacs? I would state "Emacs
package" explicitly to highlight contrast with "LaTeX package".
> +(defcustom org-latex-engraved-preamble
> + "\\usepackage{fvextra}
> +
> +[FVEXTRA-SETUP]
> +
> +\\renewcommand\\theFancyVerbLine{\\footnotesize\\color{black!40!white}\\arabic{FancyVerbLine}}
I'd like to see a comment on what it does.
> +\\usepackage{xcolor}
> +
> +\\providecolor{codebackground}{HTML}{f7f7f7}
> +\\providecolor{codeborder}{HTML}{f0f0f0}
> +\\providecolor{EFD}{HTML}{28292e}
> +
> +% TODO have code boxes keep line vertical alignment
> +\\usepackage[breakable,xparse]{tcolorbox}
> +\\DeclareTColorBox[]{Code}{o}%
Same request to provide a comment. Also, what it that % TODO doing
there? It is confusing.
Also, it is unclear what the [breakable,xparse] options to tcolorbox are
doing there and what will happen if the user removes them.
Further, I am wondering what is going to happen if the user happens to
have tcolorbox without options loaded via org-latex-packages-alist.
> +There is quite a lot of flexibility in what this preamble can be, as long as
> it:
> +- Loads the fvextra package.
> +- Loads the package xcolor (if it is not already loader elsewhere).
> +- Defines a \"Code\" environment (note the capital C), which can be
> + later used to wrap \"Verbatim\" environments (provided by fvextra).
The last point is not very clear. What kind of environment?
> +(defun org-latex-generate-engraved-preamble (info syntax-colours-p)
> + "Generate the preamble to setup engraved code.
> +The result is constructed from `org-latex-engraved-preamble' and
> +`org-latex-engraved-options'."
This is relying on
(:latex-engraved-options nil nil org-latex-engraved-options)
(:latex-engraved-preamble nil nil org-latex-engraved-preamble)
If it changes any time in future (e.g. to allow per-file settings), the
docstring may be overlooked.
> + (let ((src-p (org-element-map (plist-get info :parse-tree)
> +'(src-block inline-src-block) #'identity))
> + (fixedw-p
> + (org-element-map (plist-get info :parse-tree)
> + '(example-block fixed-width) #'identity)))
I'd use FIRST-MATCH argument for org-element-map. It will be slightly
faster on large buffers.
> - (downcase org-lang)))
> + (downcase lang)))
I am not sure if this belongs to this patch. Please double check.
> +(mapcar 'length
> +(org-split-string (car code-info)
> + "\n")
I am not sure how well it will work with e.g. Chinese characters in comments.
Best,
Ihor
Re: [PATCH v4] org-encode-time compatibility and convenience helper
Max Nikulin writes: > On 04/05/2022 16:56, Ihor Radchenko wrote: >> Max Nikulin writes: >> >> 1 unexpected results: >> FAILED test-org-clock/clocktable/ranges > > Resetting timezone to UTC should be fixed in timestamps generated by a > testing helper function. I was disappointed that `mapcar' can not be > used with multiple lists, but I have found an old function created > namely for zeroing nils in timestamps. FYI, there is cl-mapcar, but your solution here is also fine. > I have created one more patch with tests quite close to the case caused > this series. Thanks! LGTM. All the tests are passing now on my side. I'll postpone merging to next week to make sure that there are no more comments. Best, Ihor
Re: org-fold documentation
so one would not be able to load all of org then compile? On 5/6/22, Ihor Radchenko wrote: > Samuel Wales writes: > >> is there a quick trick like loading everything first? for .el under >> my control i have a[n otherwise] strict policy of clean compilation >> but don't declare. just load before compiling. > > I am not aware about such trick. native-comp works in isolated Emacs > process for each individual .el file. > > Properly resolving the warning on Org side is impossible because we rely > on runtime. Putting all the necessary requires would cause circular > requires :( > > Best, > Ihor > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: org-fold documentation
Samuel Wales writes: > is there a quick trick like loading everything first? for .el under > my control i have a[n otherwise] strict policy of clean compilation > but don't declare. just load before compiling. I am not aware about such trick. native-comp works in isolated Emacs process for each individual .el file. Properly resolving the warning on Org side is impossible because we rely on runtime. Putting all the necessary requires would cause circular requires :( Best, Ihor
Re: org-fold documentation
is there a quick trick like loading everything first? for .el under my control i have a[n otherwise] strict policy of clean compilation but don't declare. just load before compiling. not using native yet so idk if the q makes sense. On 5/6/22, Ihor Radchenko wrote: > Vikas Rawal writes: > >> After upgrading to 9.5.3, I am getting warnings such as this, which I >> suspect are due to org-fold.et. >> >> Warning (comp): org-fold.el:834:27: Warning: Unused lexical variable >> `org-hide-macro-markers' Disable showing Disable logging >> Warning (comp): org.el:76:30: Warning: Package cl is deprecated Disable >> showing Disable logging >> Warning (comp): ox.el:79:1: Warning: the function ‘org-back-to-heading’ >> might not be defined at runtime. Disable showing Disable logging >> Warning (comp): ox.el:79:1: Warning: the function >> ‘org-next-visible-heading’ might not be defined at runtime. Disable >> showing >> Disable logging >> Warning (comp): ox.el:79:1: Warning: the function ‘org-at-heading-p’ >> might >> not be defined at runtime. Disable showing Disable logging >> >> Is org-fold.el documented already? Any pointers to what might be causing >> the above? > > These are native-comp warnings. They are not uncommon when > native-compiling Org (not only org-fold.el) and generally harmless. > If you are sufficiently annoyed with them, most of these warnings can be > "fixed" by declaring the missing functions. The functions are available > at runtime, but not during native-compilation. > > Best, > Ihor > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Recent changes in org-fold regarding emphasize visibility
Daniel Fleischer writes: > Ihor Radchenko writes: > >> Fixed on main by d2a459d25 > > I've tried the commit. I think there are still issues. E.g. given a > folded headline > > * Introduction...| > * Section > > Inserting text at that point will do the following thing depending on > `org-fold-catch-invisible-edits': > > - error : it inserts the text without unfolding; most dangerous. > - show : unfold, insert the text without displaying it; dangerous. > - show-and-error: unfold but inserts the text anyways. Thanks for testing! The problem here is that emphasis markers and links are also partially hidden and it is a good idea to check invisible edits there. It's just that they were ignored by org-catch-invisible-edits in the past. But not anymore. I afraid that it is impossible to follow the present docstring for org-catch-invisible-edits without mixing 'error/'show-and-error with 'smart. It's perfectly fine to insert text right after trailing ]] of the links, but, as you showed, not after folded headline contents. Now, we have different kinds of hidden text at hand: - folded headlines/lists - folded drawers - folded blocks - folded links/emphasis The question is what should be the logical behaviour of Org when editing text inside or at the border of these hidden text types? How should we interpret the values of org-catch-invisible-edits (nil error show show-and-error smart)? Best, Ihor
Re: org-fold documentation
Vikas Rawal writes: > After upgrading to 9.5.3, I am getting warnings such as this, which I > suspect are due to org-fold.et. > > Warning (comp): org-fold.el:834:27: Warning: Unused lexical variable > `org-hide-macro-markers' Disable showing Disable logging > Warning (comp): org.el:76:30: Warning: Package cl is deprecated Disable > showing Disable logging > Warning (comp): ox.el:79:1: Warning: the function ‘org-back-to-heading’ > might not be defined at runtime. Disable showing Disable logging > Warning (comp): ox.el:79:1: Warning: the function > ‘org-next-visible-heading’ might not be defined at runtime. Disable showing > Disable logging > Warning (comp): ox.el:79:1: Warning: the function ‘org-at-heading-p’ might > not be defined at runtime. Disable showing Disable logging > > Is org-fold.el documented already? Any pointers to what might be causing > the above? These are native-comp warnings. They are not uncommon when native-compiling Org (not only org-fold.el) and generally harmless. If you are sufficiently annoyed with them, most of these warnings can be "fixed" by declaring the missing functions. The functions are available at runtime, but not during native-compilation. Best, Ihor
Re: [PATCH] New LaTeX code export option: engraved
Max Nikulin writes: >> +(defun org-latex-src-block--verbatim >> +(src-block info _lang caption caption-above-p _label >> + _num-start _retain-labels _attributes float) > > On the one hand I have no a better suggestion, but on the other hand 10 > arguments is too much for straightforward code from my point of view. > Unsure that getting parameters in each function or passing a property > list would not be worse however. I agree that having that many unused arguments is awkward, especially when the arguments are repeated in all the calls. Maybe the functions could be rewritten using cl-defun with keys and and then called via apply on a let-bound arg plist? Best, Ihor
[PATCH] Re: [Style] Shouldn’t the macros in org-fold-core have (indent 0)
Anders Johansson writes: > When looking through the code in org-fold-core (while debugging a tricky > problem that seems to be an interaction with org-modern, I may get back to > it) I noticed that all the macros that wrap a “body” argument have (indent > 1), but I gather that they should have (indent 0), similar to for example > `with-silent-modifications`. Thanks for the heads up! This was just a blind kill-yank from a macro with extra arg. > I didn’t want to create a patch, since it would involve whitespace changes > on quite a lot of places, but I thought it could be good to highlight now > that org-fold just got merged. Still, it needs to be done. Attaching the patch with fixed indent statements and reindented code. Best, Ihor >From 6412cc974afa3a4701a784f331b7182278ba5bef Mon Sep 17 00:00:00 2001 Message-Id: <6412cc974afa3a4701a784f331b7182278ba5bef.1651895053.git.yanta...@gmail.com> From: Ihor Radchenko Date: Sat, 7 May 2022 11:34:10 +0800 Subject: [PATCH] Fix macro indentation and re-indent code misindented by nameless * lisp/org-fold-core.el (org-fold-core-cycle-over-indirect-buffers): (org-fold-core-ignore-modifications): (org-fold-core-ignore-fragility-checks): * lisp/org-macs.el (org-element-with-disabled-cache): Fix incorrect indentation declare statement. Body-only macros should use (indent 0) to avoid indenting first line differently from other body. * lisp/org-capture.el: * lisp/org-clock.el: * lisp/org-fold-core.el: * lisp/org-fold.el: * lisp/org-id.el: * lisp/org-list.el: * lisp/org-macs.el: * lisp/org.el: Reindent. Reported in https://orgmode.org/list/cakjdto_z4lbgek3suc6-a_z0-ddd6l26_yfmypztn7f92ux...@mail.gmail.com --- lisp/org-capture.el | 2 +- lisp/org-clock.el | 58 ++-- lisp/org-element.el | 458 +++- lisp/org-fold-core.el | 140 - lisp/org-fold.el | 91 +++--- lisp/org-id.el| 48 +-- lisp/org-list.el | 90 +++--- lisp/org-macs.el | 2 +- lisp/org.el | 688 +- 9 files changed, 812 insertions(+), 765 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 068e3eda2..5ca4e1f2f 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1174,7 +1174,7 @@ (defun org-capture-place-entry () (t (goto-char (point-max)) ;; Make sure that last point is not folded. (org-fold-core-cycle-over-indirect-buffers -(org-fold-region (max 1 (1- (point-max))) (point-max) nil + (org-fold-region (max 1 (1- (point-max))) (point-max) nil (let ((origin (point))) (unless (bolp) (insert "\n")) (org-capture-empty-lines-before) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index ec87aaf8a..e2c2688e1 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1582,8 +1582,8 @@ (defun org-clock-find-position (find-unclosed) (cond ((null positions) (org-fold-core-ignore-modifications - ;; Skip planning line and property drawer, if any. - (org-end-of-meta-data) + ;; Skip planning line and property drawer, if any. + (org-end-of-meta-data) (unless (bolp) (insert-and-inherit "\n")) ;; Create a new drawer if necessary. (when (and org-clock-into-drawer @@ -1607,28 +1607,28 @@ (defun org-clock-find-position (find-unclosed) ;; Skip planning line and property drawer, if any. (org-end-of-meta-data) (org-fold-core-ignore-modifications - (let ((beg (point))) - (insert-and-inherit - (mapconcat - (lambda (p) - (save-excursion - (goto-char p) - (org-trim (delete-and-extract-region - (save-excursion (skip-chars-backward " \r\t\n") - (line-beginning-position 2)) - (line-beginning-position 2) - positions "\n") - "\n:END:\n") - (let ((end (point-marker))) - (goto-char beg) - (save-excursion (insert-and-inherit ":" drawer ":\n")) - (org-fold-region (line-end-position) (1- end) t 'outline) - (org-indent-region (point) end) - (forward-line) - (unless org-log-states-order-reversed - (goto-char end) - (beginning-of-line -1)) - (set-marker end nil) + (let ((beg (point))) + (insert-and-inherit + (mapconcat + (lambda (p) + (save-excursion + (goto-char p) + (org-trim (delete-and-extract-region + (save-excursion (skip-chars-backward " \r\t\n") + (line-beginning-position 2)) + (line-beginning-position 2) + positions "\n") + "\n:END:\n") + (let ((end (point-marker))) + (goto-char beg) + (save-excursion (insert-and-inherit ":" drawer ":\n")) + (org-fold-region (line-end-position) (1- end) t 'outline) + (org-indent-region (point) end) + (forward-line) + (unless org-log-states-order-reversed + (goto-char
[PATCH] org-macs.el: Do not compare wall time and file modification time
Mark Barton to emacs-orgmode, emacs-devel. master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc. Tue, 26 Apr 2022 23:37:50 -0700. https://list.orgmode.org/bf5b9308-3fef-4dc6-98c9-bff36f19d...@gmail.com > The change also breaks org-file-newer-than-p function that triggered the debugger while loading my init that uses org babel. I think, it should be fixed in the bugfix Org branch. The attached patch is a compromise to some degree, but I do not see a robust solution. I do not consider current behavior as reliable, however if you would prefer to keep it, the following patch may be used instead: Paul Eggert to emacs-orgmode. Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc. Wed, 27 Apr 2022 00:39:01 -0700. https://list.orgmode.org/f200c9ab-d1d4-d5a8-24cf-4e1082528...@cs.ucla.edu The changes are not covered by unit tests at least when most babel languages are disabled. On 30/04/2022 17:56, Max Nikulin wrote: (and mtime (not (and time (time-less-p mtime time Treating equality as "newer" would break `org-compile-file', so I changed the condition. Previously it was not a case since file modification time is usually in the past in comparison to current time. On 30/04/2022 01:10, Paul Eggert wrote: + (when-let ((mtime (file-attribute-modification-time (file-attributes file +(time-less-p time mtime))) `file-attribute-modification-time' makes code clearer, but it causes some complications. Formally compatibility with Emacs-25 (e.g. ubuntu-18.04 LTS bionic) is not required for the "main" branch. Emacs sources have the "bugfix" Org branch of the stable release though. The latter still supports Emacs-25, so either the Emacs source tree and the Org bugfix branch will diverge at this point or it is safer to avoid `file-attribute-modification-time' till the next major Org release. Maybe Org maintainers and developers will correct me. I have found `file-attribute-modification-time' in org-compat.el.From d37b5bb295c69572d1615e7fb2c0bcce05cb2b58 Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Fri, 6 May 2022 23:34:52 +0700 Subject: [PATCH] org-macs.el: Do not compare wall time and file modification time * lisp/org-macs.el (org-file-newer-than-p): Fix Emacs-29 problem with changed representation of system clock timestamp. Recommend passing file modification time and do not truncate its precision. (org-compile-file): Store file modification time instead of system clock for later comparison by `org-file-newer-than-p'. It changes behavior of `org-babel-load-file' for the case of equal modification time of source and tangled files that may happen on filesystems with coarse timestamps, for example HFS+. The file will be tangled again. Treating equal timestamps as up to date state would break `org-compile-file' however. Anyway time comparison is not really reliable since precision of filesystem timestamps is unknown and it differs from system clock precision. Reported by Mark Barton https://list.orgmode.org/bf5b9308-3fef-4dc6-98c9-bff36f19d...@gmail.com During discussion of the issue Paul Eggert suggested over variants of the changes in the same thread. --- lisp/org-macs.el | 32 +--- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index b10725bd5..556bf658d 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -256,16 +256,26 @@ ignored in this case." ;;; File (defun org-file-newer-than-p (file time) - "Non-nil if FILE is newer than TIME. -FILE is a filename, as a string, TIME is a list of integers, as -returned by, e.g., `current-time'." - (and (file-exists-p file) - ;; Only compare times up to whole seconds as some file-systems - ;; (e.g. HFS+) do not retain any finer granularity. As - ;; a consequence, make sure we return non-nil when the two - ;; times are equal. - (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2) - (cl-subseq time 0 2) + "Non-nil if FILE modification time is greater than TIME. +TIME should be obtained earlier for the same FILE name using + + (file-attribute-modification-time (file-attributes file)) + +If TIME is nil (file did not exist) then any existing FILE +is considered as a newer one. Some file systems have coarse +timestamp resolution, for example 1 second on HFS+ or 2 seconds on FAT, +so nil may be returned when file is updated twice within a short period +of time. File timestamp and system clock `current-time' may have +different resolution, so attempts to compare them may give unexpected +results. + +Attempt to check whether a derived file has been updated in +response to modification of its source file may give unreliable +result. Equal timestamps in such case may mean that the derived +file is up to date however this function returns nil assuming +that the FILE is not modified." + (let ((mtime (file-attribute-modification-time (file-attributes file +(and
Re: Concatenate properties
John Kitchin writes: > I believe this is hard coded in org-entry-get-with-inheritance. The > fastest option would be an override advice with your own function that > replaces (and value " ") with (and value ""), and maybe the two other > " " with "". > > John > > --- > Professor John Kitchin (he/him/his) > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > Thanks for the advice. I've added the caret symbol (:EXPORT_FILE_NAME^: assignment-1) to mean 'concatenate' as opposed to + for 'joining'. If this is something the community would want I will clean it up and send in a patch.
FIXED (or never broken?) Re: [BUG] org-fill-paragraph unexpectedly creates list items [9.5.3 (9.5.3-g69c588 @ /Users/james/.emacs.d/elpa/org-9.5.3/)]
Thank you, Ihor! > If you need any advice about Org code base, feel free to ask this > list. I will do so, once I find a bug that actually exists! > I tried hard to reproduce your issue, but I am unable to get the > behaviour you report using the latest stable version of Org (bugfix: > f8bb41461), the latest dev version (main), and the Org version built > into Emacs 28. > > Could you create steps to reproduce the problem starting from emacs -Q? > See https://orgmode.org/manual/Feedback.html I went ahead and tried to reproduce the issue with -Q, no dice, then updated everything, and then the issue was gone there for me too. (I had tried this before emailing you all, but new packages came out, etc.) It looks like I must have had a strange interaction between packages that's now gone. Thanks for your nice email and welcoming attitude. This is not a bug in the newest version of things, nor in the distro version. Closed bug report, please! Warmly, -J.P.
org-fold problems
Hello all, I am seeing very strange and somewhat frustrating behaviour with the new org-fold implementation. I have not been able to determine the exact conditions leading to the problem but some subtrees cannot be revealed by either org-cycle or org-fold-reveal and act as if the have no content (even when they do). However, the content can be revealed if I search for some text, text I know is in the hidden content. I'm busy with a deadline so cannot do more investigation at this point. Thank you, eric -- : Eric S Fraga, with org release_9.5.3-472-gd2a459 in Emacs 29.0.50
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
> Sounds reasonable. Could you prepare a patch? > COMMENT should be inside a shy group and note that there might be an > arbitrary number of space after COMMENT string. Here it is. >From 54cd366c97bd64c226cc6fc79e125ee9f026ff66 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Fri, 6 May 2022 13:51:14 +0200 Subject: [PATCH] lisp/org.el: match COMMENT in `org-complex-heading-regexp-format' --- lisp/org.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 1d5fc3903..0ec717322 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4213,6 +4213,8 @@ related expressions." "\\(?: +" org-todo-regexp "\\)?" "\\(?: +\\(\\[#.\\]\\)\\)?" "\\(?: +" + ;; Headline might be commented + "\\(?:" org-comment-string " +\\)?" ;; Stats cookies can be stuck to body. "\\(?:\\[[0-9%%/]+\\] *\\)*" "\\(%s\\)" -- 2.25.1
Re: [BUG] org-fill-paragraph unexpectedly creates list items [9.5.3 (9.5.3-g69c588 @ /Users/james/.emacs.d/elpa/org-9.5.3/)]
J. P. Ascher writes: > This is a bug that I fixed locally, but I'm not up to speed on > contributions or your code style, and your code base is fairly > complicated. > > I contribute my solution in case it would be of broader use. Thanks for the report and the proposed solution! If you need any advice about Org code base, feel free to ask this list. > `One two three four five six seven eight nine ten eleven twelve thirteen 1. > fourteen` > > Filling that line with fill-column 72 results in: > > `One two three four five six seven eight nine ten eleven twelve thirteen > 1. fourteen` I tried hard to reproduce your issue, but I am unable to get the behaviour you report using the latest stable version of Org (bugfix: f8bb41461), the latest dev version (main), and the Org version built into Emacs 28. Could you create steps to reproduce the problem starting from emacs -Q? See https://orgmode.org/manual/Feedback.html > Another example, with ox-pandoc (I believe pandoc is slightly more > capacious in its list definitions) this will also trigger a new line: > > `One two three four five six seven eight nine ten eleven twelve thirteen A. > fourteen` > > Filling with fill-column 72 results in: > > `One two three four five six seven eight nine ten eleven twelve thirteen > A. fourteen` Note that ox-pandoc is not a part of Org. Could you submit the bug report to ox-pandoc author? Best, Ihor
Re: [Some news (nngnorb "UCMgmail")?] (was: [BUG] In recent GNU emacs master org-capture hangs [9.5.3 (release_9.5.3-465-gd7dc62 @ /home/oub/emacs/site-lisp/packages/org/)])
Uwe Brauer writes: > That did not work, however when removing > > (nngnorb "UCMgmail") > it worked. > > When you read this, any idea what is going on here? nngnorb is a third-party package that is certainly interacting with Org (https://elpa.gnu.org/packages/gnorb.html) It would be great if you report bug to the package author, so that he/she can help with debugging. Best, Ihor
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Ignacio Casso writes: >> Note that org-complex-heading-regexp-format does consider statistics >> cookies, but only at the beginning/end of the headline title. >> Unfortunately, it is impossible to provide generic printf format to >> match a headline title with arbitrary statistics cookies inserted in the >> middle of it. > > Could not something equivalent be done for COMMENT keywords and > optionally match them at the beginning of the headline in > `org-complex-heading-regexp-format'? Something like this: > > (setq org-complex-heading-regexp-format > (concat "^\\(\\*+\\)" > "\\(?: +" org-todo-regexp "\\)?" > "\\(?: +\\(\\[#.\\]\\)\\)?" > "\\(?: +" > + ;; Headline might be commented > + "\\(COMMENT \\)? > ;; Stats cookies can be stuck to body. > "\\(?:\\[[0-9%%/]+\\] *\\)*" > "\\(%s\\)" > "\\(?: *\\[[0-9%%/]+\\]\\)*" > "\\)" > "\\(?:[ \t]+\\(:[[:alnum:]_@#%%:]+:\\)\\)?" > "[ \t]*$")) > > This would fix the problem I really cared about: being able to use a > headline as capture target regardless of whether it is commented or > not. Getting the headline text was never important to me, so I don't > really care that much about `org-complex-heading-regexp'. Sounds reasonable. Could you prepare a patch? COMMENT should be inside a shy group and note that there might be an arbitrary number of space after COMMENT string. >> I generally dislike the idea of the available plethora of analytic >> regexps with numbered match groups. > > Do you mean that there is no way to specify an optional string in a > regular expression without wrapping it in a parenthesized group, which > would break the match group numbering backwards compatibility? I'm not > that familiar with regular expressions, but if that's the case I > completely agree with your last statement. Not exactly. We could use shy (unnumbered) match group and not break the group numbers. However, adding an extra optional match means that we can break an old code that could be relying on the next group to contain this optional match: Old code: (when (string-match-p "COMMENT" (match-string 1)) ...) Before "\\(.+\\)" After "\\(?:COMMENT\\)?\\(.+\\)" The old code will never match COMMENT when the new regexp is used. Best, Ihor
Re: org-capture problems again, the evil %from, %subject
Uwe Brauer writes: > I am again facing the problem that org-capture hangs even with my > recovered old setting. > > I investigated it a bit, org-capture is mostly ok, but not for those > templates that contain gnus specific commands like %from %subject etc > > How can I debug this? I'd try to debug-on-entry in org-store-link Best, Ihor
[PATCH] Re: [9.5.2] [org-keys] [cursor keys with modifiers] ESC missing?
R Primus writes: > For `(org-defkey org-mode-map (kbd "ESC ") #'org-metaleft)`, just > wondering if: > > 1. this was intentionally left out, and > 2. if so, what is the reason? > > This causes user `surprise` when switching from using emacs/org-mode in > the terminal to a GUI session. I tied to dig into commit history and I do not see any justification why ESC could be omitted from default non-terminal bindings. I agree that the current behaviour is inconsistent. The fix is attached. Best, Ihor >From 7232400abe73c9d4ad667781146f1b5da14b64a4 Mon Sep 17 00:00:00 2001 Message-Id: <7232400abe73c9d4ad667781146f1b5da14b64a4.1651833603.git.yanta...@gmail.com> From: Ihor Radchenko Date: Fri, 6 May 2022 18:37:10 +0800 Subject: [PATCH] org-keys: Bind ESC by default * lisp/org-keys.el (org-mode-map): Bind `org-metaleft' to ESC by default, not just in terminals. This completes the ESC binding group. ESC , , and are already bound and missing ESC can be confusing. Reported in https://orgmode.org/list/Yf6lsTR3JSNSXRDX@x.local --- lisp/org-keys.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org-keys.el b/lisp/org-keys.el index 782ffa871..e96fa217b 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -462,6 +462,7 @@ (org-defkey org-mode-map (kbd "M-RET") #'org-meta-return) Cursor keys with modifiers (org-defkey org-mode-map (kbd "M-") #'org-metaleft) +(org-defkey org-mode-map (kbd "ESC ") #'org-metaleft) (org-defkey org-mode-map (kbd "M-") #'org-metaright) (org-defkey org-mode-map (kbd "ESC ") #'org-metaright) (org-defkey org-mode-map (kbd "M-") #'org-metaup) -- 2.35.1
[PATCH] Re: [BUG] Set org-format-latex-options in .dir-locals.el [9.5.1 (release_9.5.1-11-g96d91b @ emacs-28.0.90/lisp/org/)]
Y. E. via "General discussions about Org-mode." writes: > Hello, > > I tried configuring 'org-format-latex-options' per a org-mode > file/directory by adding the following configuration into the > .dir-locals.el file: > The file settings I use: > > #+STARTUP: content latexpreview > #+OPTIONS: tex:dvisvgm html-style:nil > #+HTML_HEAD: > > The LaTeX formulas are embedded into the text as shown here: > https://orgmode.org/manual/LaTeX-fragments.html > > Am I overlooking something? Nope. This is a bug. It happens because LaTeX fragments are processed in temporary buffer and all the buffer-local variables you set in the original org buffer are discarded. The fix is attached. Nicolas, this kind of error might be present in various places of export library. You may want to fix it in more places than what I propose in this patch. Best, Ihor >From 37a37862a17c4b333164edffbac97f8a56052e88 Mon Sep 17 00:00:00 2001 Message-Id: <37a37862a17c4b333164edffbac97f8a56052e88.1651832231.git.yanta...@gmail.com> From: Ihor Radchenko Date: Fri, 6 May 2022 18:14:05 +0800 Subject: [PATCH] org-html-format-latex: Preserve buffer-local settings * lisp/ox-html.el (org-html-format-latex): Carry over buffer-local variables when create LaTeX images. Use `org-export-with-buffer-copy' instead of `with-temp-buffer'. Fixes https://orgmode.org/list/m2fsqr75md@ego.team --- lisp/ox-html.el | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 81ef002a0..7f2087a46 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -2872,11 +2872,12 @@ (defun org-html-format-latex (latex-frag processing-type info) ;; temporary buffer so that dvipng/imagemagick can properly ;; turn the fragment into an image. (setq latex-frag (concat latex-header latex-frag -(with-temp-buffer - (insert latex-frag) - (org-format-latex cache-relpath nil nil cache-dir nil - "Creating LaTeX Image..." nil processing-type) - (buffer-string +(org-export-with-buffer-copy + (erase-buffer) + (insert latex-frag) + (org-format-latex cache-relpath nil nil cache-dir nil + "Creating LaTeX Image..." nil processing-type) + (buffer-string (defun org-html--wrap-latex-environment (contents _ caption label) "Wrap CONTENTS string within appropriate environment for equations. -- 2.35.1
Re: :eval yes use and documentation
Charles Millar writes: > Is ":eval yes" officially allowed and, if so, why is it not documented? > > Should it be? Yes, it should be. Moreover, we have strip-export value undocumented. Confirmed. Best, Ihor
Re: Bug: org-attach-follow with wrong-number-of-arguments [ ( @ /home/sbrass/.emacs.d/elpa/org-9.4.4/)]
Simon Braß writes: > I've tried to open an attached file (added with org-attach-attach), however, > when I try to open it with C-c C-o I got the following backtrace: > > #+begin_example > Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1) For record. It should not be an issue on latest Org (both main and bugfix) unless there is mixed Org installation with ancient Org version being loaded. Best, Ihor
