(Reopened) Bug: font-lock error with - in code-mode
We need to fix the problem (see the first message in the thread) in some other way. I currently cannot think anything better than using org-element parser (which may be slow) to avoid treating closing emphasis marker as a new opening marker. Max Nikulin writes: > Would not it be enough to just add X-Woof-Bug header to the message? > Maybe even with "(Reopened)" suffix to the title to warn other people > that it is not a forgotten bug, even if they remember that some patch > was committed. It is a wild guess, I did not looked into the "Woof!" > code. I just assume that logic inside is not overcomplicated. Trying it now in this message. I was mostly confused by the new Woof! docs in https://github.com/bzg/woof/blob/master/resources/md/howto.md Best, Ihor
Cancel "yes" entry on updates.orgmode.org (was: Re: Bug: font-lock error with - in code-mode)
Canceled. On 27/10/2021 14:08, Ihor Radchenko wrote: Max Nikulin writes: Would not it be enough to just add X-Woof-Bug header to the message? Maybe even with "(Reopened)" suffix to the title to warn other people that it is not a forgotten bug, even if they remember that some patch was committed. It is a wild guess, I did not looked into the "Woof!" code. I just assume that logic inside is not overcomplicated. Trying it now in this message. I was mostly confused by the new Woof! docs in https://github.com/bzg/woof/blob/master/resources/md/howto.md It works in the sense that your message added a bug named "yes", I am going to remove it and to create a more informative one. I agree that older docs were more clear. Sorry for the noise.
[Bug] org-persist.el: xdg.el is unavailable in emacs-25.2
Org-mode compilation fails with the following errors if emacs-25.2.2 is used (Ubuntu-18.04 LTS bionic) Compiling /home/ubuntu/org-mode/lisp/ox-ascii.el... In toplevel form: ox-ascii.el:31:1:Error: Cannot open load file: No such file or directory, xdg Compiling /home/ubuntu/org-mode/lisp/ox-beamer.el... In toplevel form: ox-beamer.el:34:1:Error: Cannot open load file: No such file or directory, xdg > > ... org.el in the main branch still declares ;; Package-Requires: ((emacs "25.1")) but it seems xdg.el used by org-persist.el was added in emacs-26.0. I do not actually use emacs-25.2, but it happened that I have a test container for Org based on Ubuntu-18.04. Either org-persist and org-compat should be updated with some compatibility code or required emacs version should be updated once more.
Re: [Bug] org-persist.el: xdg.el is unavailable in emacs-25.2
Max Nikulin writes: >> In toplevel form: >> ox-beamer.el:34:1:Error: Cannot open load file: No such file or directory, >> xdg > > > > ... > > org.el in the main branch still declares > >> ;; Package-Requires: ((emacs "25.1")) > > but it seems xdg.el used by org-persist.el was added in emacs-26.0. > > I do not actually use emacs-25.2, but it happened that I have a test > container for Org based on Ubuntu-18.04. > > Either org-persist and org-compat should be updated with some > compatibility code or required emacs version should be updated once more. Technically, the current Emacs version is Emacs 27. So, following our maintenance convention [1], we should support everything down to Emacs 25 (e.g. 27-2). However, Emacs 28 is going to be out soon-ish and the problem is not on bugfix branch, but only on main. I am not sure if we need to follow version-2 convention for main as well. Maybe better require only version-1? Weaker back-compatibility requirement can allow us to implement more advanced features relying on more recent Emacs versions. [1] https://orgmode.org/worg/org-maintenance.html Also, org-src.el from bugfix may not run on Emacs 25: In end of data: org-src.el:1312:1:Warning: the function ‘replace-buffer-contents’ is not known to be defined. Best, Ihor
Re: [ISSUE] org-mode fill paragraph is slow and suspend often
I applied your patch on the latest pulled org-mode source code. Still can't org-fill elements quickly when region select text contains org headlines, properties drawer etc. If I only fill paragraph, it is fine. <#secure method=pgpmime mode=sign> -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
[PATCH] Fix behavior of lambda default header arg vars
Hello, :var header arguments can be provided multiple times. This is supported directly at the source block and through the default header argument facility. However, this was not handled correctly when the var was evaluated from a closure in a default header argument (only the last var was taken). This patch fixes that. I've also added documentation explaining how to set multiple vars in the default header argument facility. Thanks, Matt >From 5f02fe4e896e6909fab18e8d90a7e14bdce9d5c4 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Wed, 27 Oct 2021 07:47:20 -0700 Subject: [PATCH] ob-core.el: Fix behavior of lambda default header arg vars * lisp/ob-core.el: Permit multiple :var default header arguments when using closures. Additionally, document how to use default header arguments for arguments that can be provided multiple times. --- lisp/ob-core.el | 26 -- 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 7a9467b0e..21f461a08 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -478,12 +478,21 @@ For the format of SAFE-LIST, see `org-babel-safe-header-args'." This is a list in which each element is an alist. Each key corresponds to a header argument, and each value to that header's value. The value can either be a string or a closure that -evaluates to a string. The closure is evaluated when the source -block is being evaluated (e.g. during execution or export), with -point at the source block. It is not possible to use an -arbitrary function symbol (e.g. 'some-func), since org uses -lexical binding. To achieve the same functionality, call the -function within a closure (e.g. (lambda () (some-func))). +evaluates to a string. Some header arguments (e.g., :var for +some language backends) can be provided multiple times for a +source block. This functionality is also supported for default +header arguments by providing the header argument multiple times +in the alist. For example: + +'((:var . \"foo=\\\"bar\\\"\") + (:var . \"bar=\\\"foo\\\"\")) + +A closure is evaluated when the source block is being +evaluated (e.g. during execution or export), with point at the +source block. It is not possible to use an arbitrary function +symbol (e.g. 'some-func), since org uses lexical binding. To +achieve the same functionality, call the function within a +closure (e.g. (lambda () (some-func))). To understand how closures can be used as default header arguments, imagine you'd like to set the file name output of a @@ -2718,6 +2727,11 @@ parameters when merging lists." (pcase pair (`(:var . ,value) (let ((name (cond +;; Default header arguments can accept lambda +;; functions. We uniquely identify the var +;; according to the full string contents of +;; the lambda function. + ((functionp value) value) ((listp value) (car value)) ((string-match "^\\([^= \f\t\n\r\v]+\\)[ \t]*=" value) (intern (match-string 1 value))) -- 2.31.1
Re: [ISSUE] org-mode fill paragraph is slow and suspend often
"Christopher M. Miles" writes: > I applied your patch on the latest pulled org-mode source code. Still can't > org-fill elements > quickly when region select text contains org headlines, properties drawer etc. > > If I only fill paragraph, it is fine. Thanks for the pointer. I now managed to reproduce the problem. It was an infinite loop in org--backward-paragraph-once. Fixed on main via cc3df3af2. Best, Ihor
Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
Hi Vikas,
Vikas Rawal writes:
> This is excellent. There is only one improvement that I would like you to
> consider. Is it possible to allow multiple ":options " lines that are
> appended when exported to
> +latex? Something like this:
>
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align colspec = {XXX}, width = 0.85\linewidth
> #+ATTR_LATEX: :options remark{Note} = {Lorem ipsum dolor sit amet}
> #+ATTR_LATEX: :options remark{Source} = {The source of data}
>
> ==> \begin{longtblr}[remark{Note} = {Lorem ipsum dolor sit amet},
> remark{Source} = {The source of data}]{colspec = {XXX},
> width = 0.85\linewidth}
>
> This would be more elegant since table notes can be elaborate and putting
> them all in one line would make them unwieldy.
>
> At the moment, only the last ":options" line is considered.
The normal behavior is that you cannot put more than one property
`:foo', because in that case only the value of the last one is added
when exporting to LaTeX (ther is a property list where each property has
a string value).
I can think of a somewhat tricky solution, in case you want to adapt it
to your use case:
First, you need to convert a plist to an alist (source:
https://caiorss.github.io/Emacs-Elisp-Programming/Elisp_Programming.html#sec-1-8-4):
#+begin_src emacs-lisp
(defun plist->alist (plist)
(if (null plist)
'()
(cons
(list (car plist) (cadr plist))
(plist->alist (cddr plist)
#+end_src
And this would be the modified function:
#+begin_src emacs-lisp
(defun org-latex--org-table (table contents info)
"Return appropriate LaTeX code for an Org table.
TABLE is the table type element to transcode. CONTENTS is its
contents, as a string. INFO is a plist used as a communication
channel.
This function assumes TABLE has `org' as its `:type' property and
`table' as its `:mode' attribute."
(let* ((attr (org-export-read-attribute :attr_latex table))
(alignment (org-latex--align-string table info))
;; various `:options' props <== modified from here
(attr-alist (plist->alist attr))
(options-list)
(options-str (progn
(mapc (lambda (m)
(when (eq (car m) :options)
(add-to-list 'options-list (cdr m
attr-alist)
(mapconcat (lambda (x) (mapconcat 'identity x ""))
options-list " ")))
< == to here
(table-env (or (plist-get attr :environment)
(plist-get info :latex-default-table-environment)))
(width
(let ((w (plist-get attr :width)))
(cond ((not w) "")
((member table-env '("tabular" "longtable")) "")
((member table-env '("tabu" "longtabu"))
(format (if (plist-get attr :spread) " spread %s "
" to %s ")
w))
(t (format "{%s}" w)
(caption (org-latex--caption/label-string table info))
(above? (org-latex--caption-above-p table info)))
(cond
((member table-env '("longtable" "longtabu"))
(let ((fontsize (let ((font (plist-get attr :font)))
(and font (concat font "\n")
(concat (and fontsize (concat "{" fontsize))
(format "\\begin{%s}%s{%s}\n" table-env width alignment)
(and above?
(org-string-nw-p caption)
(concat caption "\n"))
contents
(and (not above?)
(org-string-nw-p caption)
(concat caption "\n"))
(format "\\end{%s}" table-env)
(and fontsize "}"
(t
(let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
;; modified here
(if options-list (format "[%s]" options-str) "")
width
alignment
contents
table-env)))
(org-latex--decorate-table output attr caption above? info))
#+end_src
Pleas tell me if it works for you.
Best regards,
Juan Manuel
Re: Fwd: errors when using org-agenda
On 24/10/2021 15:34, Ihor Radchenko wrote: Max Nikulin writes: `org-version' with FULL argument checks whether org and org-loaddedfs are loaded from the same directory and adds "mixed installation!" to the version string. `org-submit-bug-report' puts full version to the message subject but it is easily to miss this warning since it is in the middle of the long string. Yes, but unfortunately it does not handle early Org loading correctly. Try the following init.el: (require 'org) (add-to-list 'load-path (expand-file-name "/path/to/newest/org-mode/lisp")) Then run emacs -Q -l /path/to/init.el M-x org-version does not report anything suspicious even though M-x org-mode will error on current main because old 'org is trying to load files from the new load-path. You are right, `org-version' can not catch such case. However improvements of mixed install detection should be incorporated into `org-submit-bug-report'. I would not mind to have more prominent warning in the message body, maybe even with the link to the FAQ entry. + (loaded-features (seq-filter + (lambda (f) (memq (alist-get 'provide f) +org-feature-list)) +load-history)) Some time ago I found `featurep' function, so I am curious if there are reasons why it should not be used here. If earlier loaded org modules is a problem during update and compiling of new sources, couldn't it be solved by `eval-when-compile'? E.g. by new `org-require' macro that wraps `require' and checks that the file is loaded from the same directory (e.g. org-loaddefs, the required file, and the compiled file)? The idea is that such code should not depend on particular package manager.
Re: Cancel "yes" entry on updates.orgmode.org (was: Re: Bug: font-lock error with - in code-mode)
On 27/10/2021 18:50, Max Nikulin wrote: Canceled. Magic in the message body did not help, so one more attempt with the header. On 27/10/2021 14:08, Ihor Radchenko wrote: Max Nikulin writes: Would not it be enough to just add X-Woof-Bug header to the message? Maybe even with "(Reopened)" suffix to the title to warn other people that it is not a forgotten bug, even if they remember that some patch was committed. It is a wild guess, I did not looked into the "Woof!" code. I just assume that logic inside is not overcomplicated. Trying it now in this message. I was mostly confused by the new Woof! docs in https://github.com/bzg/woof/blob/master/resources/md/howto.md It works in the sense that your message added a bug named "yes", I am going to remove it and to create a more informative one. I agree that older docs were more clear. gitk does not like emoji in commits... Sorry for the noise.
[SOLVED] Re: [ISSUE] org-mode fill paragraph is slow and suspend often
Thanks, confirmed solved. Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> I applied your patch on the latest pulled org-mode source code. Still can't >> org-fill elements >> quickly when region select text contains org headlines, properties drawer >> etc. >> >> If I only fill paragraph, it is fine. > > Thanks for the pointer. I now managed to reproduce the problem. It was > an infinite loop in org--backward-paragraph-once. Fixed on main via > cc3df3af2. > > Best, > Ihor <#secure method=pgpmime mode=sign> -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
tangle option to not write a file with same contents?
hi.
i wonder if it would be reasonable to add an option such that, when
tangling, `org-babel-tangle` would not write a file with the
already-existing contents of the target file?
this would be helpful, e.g., for those of us who use make(1)-based work
flows.
then, if this might generally be thought useful, i wonder if this should
be implemented as specifically this, or whether we might implement a
callback at the appropriate point in `org-babel-tangle` asking whether
or not to proceed. (then, the user's callback routine could do the
comparison.)
if we do "specifically this", i would suggest that this comparison be
dead simple: read in the existing file's contents into some hidden
buffer, and use `compare-buffer-substrings` to compare point-{min,max}
of both.
cheers, Greg
Re: org-persist warning when archiving
> Ihor Radchenko writes: > Colin Baxter 😺 writes: >> Ok, I now applied your patch and remade org-mode. Unfortunately, >> I don't see any change. I still get the warning on all the >> archive commands: org-agenda-archive-default, org-agenda-archive >> and org-agenda-archive-default-with-confirmation. I've appended >> the warning for the latter command. > Thanks for testing! My guess was incorrect and I am still unable > to reproduce using agenda (previously, I just tried archiving from > inside Org buffer). >> --8<---cut here---start->8--- >> Warning (emacs): org-element--cache: Unregistered buffer >> modifications detected. Resetting. If this warning appears >> regularly, please report it to Org mode mailing list (M-x >> org-submit-bug-report). The buffer is: todo.org_archive Current >> command: org-agenda-archive-default-with-confirmation Disable >> showing Disable logging Warning (emacs): org-element--cache: >> Unregistered buffer modifications detected. Resetting. If this >> warning appears regularly, please report it to Org mode mailing >> list (M-x org-submit-bug-report). The buffer is: >> todo.org_archive Current command: >> org-agenda-archive-default-with-confirmation Disable showing >> Disable logging --8<---cut >> here---end--->8--- >> >> I've not tried it on emacs -Q yet. For that, do I need to start >> afresh and first delete the org-persist-directory? > You can simply start from emacs -Q + a new file (the new file will > not have any cache). In my testing, I just created a new org file, > opening it from emacs -Q -L /path/to/latest/org/lisp -l org > /path/to/the/new/file.org Then, I added a new TODO heading, opened > todo agenda for current buffer, and tried to archive the heading > from agenda. No warning on my side. > You can repeat my steps and see what happens. If nothing, you may > try archiving from your todo.org (but still using emacs -Q). If > still nothing, it may be something about your config. The warnings may be due to my use of ATTACH directories in agenda files. I don't attach by id but prefer to use a directory for each node and to link attachments to other files rather than copy. The attachments also include other org-mode files. I should have time this weekend to check this and to confirm if my configuration is responsible. Best wishes, Colin.
