[PATCH] Fix match/maxlevel conflict in colview dynblock
Specifying both `maxlevel' and `match' in a columnview dynamic block was broken: the `match' argument is ignored in that case. See the link below for a (not so minimal) ECM. Reported-by: Pablo A Perez-Fernandez Link: https://emacs.stackexchange.com/questions/66658/filter-columnview-dblock-on-properties-or-tags -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler >From 8bcff482e59c24758f87b9b5cdef3bc123dc12f8 Mon Sep 17 00:00:00 2001 From: Nick Dokos Date: Sun, 11 Jul 2021 22:30:22 -0400 Subject: [PATCH] Fix match/maxlevel conflict in colview dynblock * lisp/org-coplview.el (org-columns--capture-view): Combine the match and maxlevel arguments properly to construct the MATCH argument of `org-map-entries'. Specifying both `maxlevel' and `match' in a columnview dynamic block does not work: the `match' argument is ignored in that case. See the link below for a (not so minimal) ECM. Reported-by: Pablo A Perez-Fernandez Link: https://emacs.stackexchange.com/questions/66658/filter-columnview-dblock-on-properties-or-tags --- lisp/org-colview.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index 2e1c29a99..7144308ff 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -1398,8 +1398,9 @@ other rows. Each row is a list of fields, as strings, or (org-get-tags (push (cons (org-reduced-level (org-current-level)) (nreverse row)) table) - (or (and maxlevel (format "LEVEL<=%d" maxlevel)) - (and match match)) + (if match + (concat match (and maxlevel (format "+LEVEL<=%d" maxlevel))) + (and maxlevel (format "LEVEL<=%d" maxlevel))) (and local 'tree) 'archive 'comment) (org-columns-quit) -- 2.31.1
Re: org-mode export to (latex) PDF
Juan Manuel Macías writes: > Tim Cross writes: > >> Just FYI for those who don't know, you can use the org-latex-classes >> variable to define your own pseudo document classes, possibly using the >> DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex >> settings. So for example, you can add the babel or other packages you >> want and either make that the 'default' class or specify which class you >> want with the #+LATEX_CLASS header. I use this quite a bit because then >> I don't have to remember which LATEX_HEADER lines to include in the >> document, the specific option settings etc. I don't need support for >> multilingual documents, but I do have a number of 'special' documents >> (such as one with colours, logos and specific fonts for an employer to >> match their 'style guide'. I also have ones for generating project >> documents, letters, meeting minutes etc. They all use various different >> Latex extensions (particularly ones which don't mix well and cannot be >> included with other packages). > > I agree. `Org-latex-classes' is a very good option for create LaTeX > templates, and I have a few classes defined as well. The problem is when > you need really long and complex preambles (it is not a problem that > most users may have, though). In a recent project (a book) my preamble > had about 2000 lines (including macros and environments defined by me, > some functions in Lua for LuaTeX, etc.). With long or complex preambles > it's a bit awkward to do it in Elisp and org-latex-classes. In that > case, I usually write the preamble to an Org document and generate a > *.tex file using org-babel-tangle. Then I include that file at the very > beginning of my document with an \input macro. On the LaTeX side, there > is also the option to create your own sty file: > https://tex.stackexchange.com/questions/77/how-to-make-a-standard-preamble-into-a-package > > As an alternative to #+LaTeX_Header you can also include the > preamble in the Org document itself using a LaTeX block: > > #+NAME: preamble > #+begin_src latex :exports none > > ... a lot of latex code > #+end_src > > and then, in another block with the keyword `:noweb': > > #+begin_src latex :noweb yes :results raw > ,#+LaTeX_Header: <> > #+end_src > > (This useful trick came from Charles Berry in this thread: > https://orgmode.org/list/225a3d45-0f47-4ffe-8bba-f023cb8c9...@health.ucsd.edu/#r) > Yes, I do pretty much the same. I have a number of personal *.sty files which contain a lot of additional setup information which would be difficult to include directly in org-latex-classes. I have also used the idea of latex blocks and tangling, especially when working out the details for a specific latex configuration. Once I have it working, unless this is strictly a 'one off', I will typically move that information into a *.sty file or similar. I also use a couple of templates via either company or yasnipet which I use for some org documents which have a 'standard' outline and header setup. I find the combination of these techniques makes it easy to create new documents and maintain existing ones. I have a terrible memory for the low level configuration stuff, so the more I can rely on pre-defined configurations, the better. The nice thing about how I have things setup now is that it seems pretty robust. I rarely encounter any problems when updating org and am able to get 'up and running' on a new system fairly quickly. The biggest challenge I've had lately has been my move from my own standard configuration to using spacemacs. It has taken a bit of work to get spacemacs to work the way I want, but I have grown to love the modal editing of evil mode (probably because VI was my first editor). I'm now very happy with my configuration and workflow. -- Tim Cross
Re: Enhancement: M-x (+lag+) command
Ypo writes: > When I send M-x and I start to write a command, I write it down to the buffer > where I have my text, instead of to the new buffer where commands appear. > > So, after I send M-x, I have to wait some time, and then I can write the > command. There is a lag between M-x and command inputting availability. > > Couldn't this lag be neutralized? For example, by recording every sent key > after > M-x and pasting them down when the commands new buffer is available? > This does not sound like typical behaviour. The first thing which needs to be established is whether or not this is a local configuration problem. Start by running emacs -Q and then opening the org file where you see this issue and see if you can reproduce the problem. If you cannot, then it is very likely the issue is due to some configuration or additional package you have installed. If you can reproduce the problem, then please log a bug report using M-x org-submit-bug-report. This will generate a buffer with a lot of important information regarding your local setup and may help us track down the source of the issue. If you cannot reproduce the problem with emacs -Q, then the cause is likely a local configuration or additional package you have installed. Tracking down the cause might take a bit of work. Essentially, you will need to reduce your configuration to a minimal setup, test and if there is no problem, slowly add back bits of your configuration or additional packages, testing after each change, until you find the cause. Once we know what the cause is, we can probably provide suggestions/assistance to get it resolved. A number of popular add-on packages relating to command input, like helm, smex, hydra, ivy, counsel etc can cause significant slowdown in command input if not correctly configured. My suspicion is that one of these packages is likely the cause. -- Tim Cross
Enhancement: M-x (+lag+) command
When I send M-x and I start to write a command, I write it down to the buffer where I have my text, instead of to the new buffer where commands appear. So, after I send M-x, I have to wait some time, and then I can write the command. There is a lag between M-x and command inputting availability. Couldn't this lag be neutralized? For example, by recording every sent key after M-x and pasting them down when the commands new buffer is available? Greetings, Ypo
Re: [BUG] org-goto slows down org-set-property
Maxim Nikulin writes: > Ihor, did you get that numbers using emacs -Q? If not, I suspect you may > have twice more markers in the buffer than `org-refile-get-targets' > usually generates. If my guess is correct it may be necessary to file a > bug that org-ql or some other package abuses markers by generation to > much of them. With emacs -Q things are twice better, though still not good enough: #+RESULTS[b9f5ebaf91a21d8da95b8840c70f6d9aeb2ab3ae]: | 9.4.4 |||| | nm-tst | 5.57239744599 | 38 | 1.003988125002 | | org-refile-get-targets | 13.029634993 | 53 | 1.320467277997 | | nm-tst | 24.14228943402 | 25 | 0.710609429002 | | org-refile-cache-clear | 0.00502349 | 0 |0.0 | | nm-tst |5.043277087 | 38 | 0.829247048997 | org-ql might be one of the reasons of slowdown. Without it, the nm-tst after clearing the cache is slightly faster (was 13 sec): #+RESULTS[e5ee2bee7b348265a19834d5ca2697618a9bf261]: | 9.4.6 | ||| | nm-tst | 10.106726732 | 34 | 3.099316665004 | | org-refile-get-targets | 5.72127774201 | 19 | 1.686224143996 | | nm-tst | 22.056917422 | 33 | 3.00019151499 | | org-refile-cache-clear | 0.001498722 | 0 |0.0 | | nm-tst | 10.066160733 | 34 |3.203417302 | However, markers are also created by agendas for example. The last result is also on fresh Emacs. Fresh Emacs tends to be faster in general. Do you know a good way to find out all the markers associated with a buffer? > P.S. Maybe generating of custom IDs automatically is a viable idea. > Before I have not considered such variant believing that they would be > noticeably longer and would have weaker associations. Some examples of autogenerated IDs using bibtex-autokey: du-2021-recen-studies-in-mechan-proper-e4d Youtube-veritasium-2021-you-cant-prove-every-thats-true-346 schuh-2005-quant-insig-into-disloc-nucleat-a1d Karl-Voit-voit-2020-draft-workf-advan-projec-manag You can judge for yourself if it is too long or not. Also, the length can be customised as described in bibtex-generate-autokey docstring. Best, Ihor
Re: [BUG] org-goto slows down org-set-property
On 11/07/2021 21:20, Ihor Radchenko wrote: Maxim Nikulin writes > | nm-tst | 22.599429478 | 4 | 2.078571420924 | | org-refile-cache-clear |0.003903494 | 0 |0.0 | | nm-tst | 13.969909913 | 4 | 2.0694318153 | Certainly 13 seconds is no go especially for interactive usage. Yeah. So, I do not use it for now until me or someone else fixes the issue. Ihor, did you get that numbers using emacs -Q? If not, I suspect you may have twice more markers in the buffer than `org-refile-get-targets' usually generates. If my guess is correct it may be necessary to file a bug that org-ql or some other package abuses markers by generation to much of them. P.S. Maybe generating of custom IDs automatically is a viable idea. Before I have not considered such variant believing that they would be noticeably longer and would have weaker associations.
Re: [BUG] org-goto slows down org-set-property
Maxim Nikulin writes: > Certainly 13 seconds is no go especially for interactive usage. Yeah. So, I do not use it for now until me or someone else fixes the issue. > Do you have an alternative for adding properties? > Unfortunately `org-set-property-and-value' C-c C-x P does not allow to > set even fixed list of options for completion. For now, I just edit the properties drawer manually or use custom setters utilising org-set-property. You can always generate a list of options using `completing-read'. Example: (completing-read "Category: " (org-ql-select (org-agenda-files t t) '(property "CATEGORY") :action (lambda () (substring-no-properties (org-entry-get (point) "CATEGORY") > I use > `org-set-property' to add CUSTOM_ID when necessary. I do not like purely > random ID. You may want to customise `org-id-method'. Also, I often use `org-capture-ref-generate-key-human-readable' from my org-capture-ref package [1]. [1] https://github.com/yantar92/org-capture-ref Best, Ihor
Re: [BUG] org-goto slows down org-set-property
On 11/07/2021 18:49, Ihor Radchenko wrote: Your test on my 12M chars 18k headings org file (Emacs master, Org mode master). I cannot use org-set-property even without org-refile-cache :( | nm-tst | 13.969909913 | 4 | 2.0694318153 | Certainly 13 seconds is no go especially for interactive usage. I use `org-set-property' to add CUSTOM_ID when necessary. I do not like purely random ID. Do you have an alternative for adding properties? Unfortunately `org-set-property-and-value' C-c C-x P does not allow to set even fixed list of options for completion.
[PATCH] Re: [bug] Setting org-id-link-to-org-use-id to t creates IDs properties when tangling
Rodrigo Morales writes:
> * The issue
>
> When setting org-id-link-to-org-use-id to t, an :ID: property is created
> for each headline that contain at least one code block that is
> tangled.
Confirmed
The fix is attached.
Best,
Ihor
>From 0ed6b52b8ded461ad6d172b9c2d49fd36d5df129 Mon Sep 17 00:00:00 2001
Message-Id: <0ed6b52b8ded461ad6d172b9c2d49fd36d5df129.1626006467.git.yanta...@gmail.com>
From: Ihor Radchenko
Date: Sun, 11 Jul 2021 20:25:21 +0800
Subject: [PATCH] Avoid creating ID property during tangling
* lisp/ob-tangle.el (org-babel-tangle-single-block,
org-babel-tangle-comment-links): Suppress org-id-link-to-org-use-id
during tangling. The links used during tangle process are transient
and do not really need to use ID. Using ID may create unexpected
edits in the tangled Org buffer when org-id-link-to-org-use-id is set
to t. Fixes [1].
[1] https://orgmode.org/list/9eb31da73b12fcaf6820484834cc8cd3@libre.brussels/T/#t
---
lisp/ob-tangle.el | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2f60ef9a4..cec658f66 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -420,7 +420,14 @@ (defun org-babel-tangle-single-block (block-counter &optional only-this-block)
(extra (nth 3 info))
(coderef (nth 6 info))
(cref-regexp (org-src-coderef-regexp coderef))
- (link (let ((l (org-no-properties (org-store-link nil
+ (link (let* (
+ ;; The created link is transient. Using ID is
+ ;; not necessary, but could have side-effects if
+ ;; used. An ID property may be added to
+ ;; existing entries thus creatin unexpected file
+ ;; modifications.
+ (org-id-link-to-org-use-id nil)
+ (l (org-no-properties (org-store-link nil
(and (string-match org-link-bracket-re l)
(match-string 1 l
(source-name
@@ -506,7 +513,13 @@ (defun org-babel-tangle-comment-links (&optional info)
(number-to-string
(line-number-at-pos
("file" . ,(buffer-file-name))
- ("link" . ,(org-no-properties (org-store-link nil)))
+ ("link" . ,(let (;; The created link is transient. Using ID is
+ ;; not necessary, but could have side-effects if
+ ;; used. An ID property may be added to
+ ;; existing entries thus creatin unexpected file
+ ;; modifications.
+ (org-id-link-to-org-use-id nil))
+ (org-no-properties (org-store-link nil
("source-name" . ,name))
(list (org-fill-template org-babel-tangle-comment-format-beg link-data)
(org-fill-template org-babel-tangle-comment-format-end link-data
--
2.31.1
Re: org-mode-map binds [tab]
With Emacs compiled from master, after Nicolas Goaziou's fix to remove the binding, my tab key was no longer bound to org-cycle, but instead to outline-cycle from outline.el If I comment out line 185 in outline.el then TAB will bind to org-cycle. Does outline.el need to be fixed too? ——snippet from outline.el (defvar outline-mode-cycle-map (let ((map (make-sparse-keymap))) (let ((tab-binding `(menu-item "" outline-cycle ;; Only takes effect if point is on a heading. :filter ,(lambda (cmd) (when (outline-on-heading-p) cmd) (define-key map [tab] tab-binding) (define-key map (kbd "TAB") tab-binding) (define-key map (kbd "") #'outline-cycle-buffer)) map) "Keymap used by `outline-mode-map' and `outline-minor-mode-cycle'.") I don’t see outline as a minor mode listed when I use C-h m while in an org file expecting org-cycle. Mark > On Jun 27, 2021, at 8:34 AM, Daniel Mendler wrote: > > `org-mode-map` binds `[tab]` which is unnecessary and harmful, since it > takes precendence over bindings of TAB even in keymaps with higher > precedence. > > Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version > 3.24.5, cairo version 1.16.0) > of 2021-02-09, modified by Debian > Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ > /home/user/.config/emacs/elpa/org-9.4.6/) > > > > I've observed this problem with my GNU ELPA package Corfu, which > installs a keymap with higher precedence than org-mode. In order to > override Org, it also has to bind [tab], which is undesired. > > On 6/27/21 11:11 AM, Daniel Mendler wrote: >> On 6/26/21 4:02 PM, Stefan Monnier wrote: +(define-key map [tab] #'corfu-complete) >>> >>> Please avoid binding `tab`: the `tab` event (only generated under GUIs) >>> is supposed to be remapped to the TAB char-event (aka `C-i`) and this is >>> what you should bind to if you want your binding to work both under ttys >>> and GUIs. >>> >>> More importantly, if you bind to `tab` than this binding will take >>> precedence over all other bindings to TAB, even those in keymaps that >>> have higher precedence. >>> >>> The same holds for `return` vs RET, and `escape` vs ESC. >> >> Hello Stefan, >> >> I am aware of the unfortunate implications of these bindings. >> Originally I avoided these bindings for the exact reasons you mention >> and I hoped I could do without those (only binding RET/TAB and >> remappings). However I have to use these keys since Org-mode seems to >> override these keys too. Otherwise my keymap will not take precedence >> over the Org-mode keymap. >> >> Daniel >> > >
Re: [BUG] org-goto slows down org-set-property
Maxim Nikulin writes: > It seems, it is better to drop org-refile-cache completely. It has some > design problems making it rather fragile. At the same time a patch can > be applied that improves performance of `org-refile-get-targets' by a > factor of at least 2 for (org-refile-use-outline-path 'file). I tend agree. I got rid of org-refile-cache some time ago in favour of org-ql. The performance is much better subjectively, which indicates that alternative caching mechanisms could be much better. Your test on my 12M chars 18k headings org file (Emacs master, Org mode master). I cannot use org-set-property even without org-refile-cache :( #+RESULTS[e3fd8ffd9dd1a1d1cb8cf2ab3927bf647e944dd8]: | 9.4.6 || || | nm-tst | 13.63854329502 | 4 | 1.990350383204 | | org-refile-get-targets |5.355179174 | 2 | 0.9795413809 | | nm-tst | 22.599429478 | 4 | 2.078571420924 | | org-refile-cache-clear |0.003903494 | 0 |0.0 | | nm-tst | 13.969909913 | 4 | 2.0694318153 | Best, Ihor
citations: rx problems with emacs-26.3
I think citation support is a great feature. (Sorry, I do not work with
references now, so I can tell nothing concerning implementation for org.)
It seems, rx e.g. in emacs-26.3 does not support all features used in
oc.el and oc-csl.el. Loading an org file using git master, I get a warning
Eager macro-expansion failure: (error "rx form ‘regexp’ requires args satisfying
‘stringp’")
It looks like (rx (regexp ...)) require namely literal, variables are
not supported yet. In additional (rx (literal ...)) is not supported as
well.
Eager macro-expansion failure: (error "Unknown rx form ‘literal’")
In a couple of places `rx-to-string' likely could be used instead of
just `rx'. I have no idea yet what could be done with (pcase-let* ((rx
...))) in `org-cite-adjust-note'.
diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index 4e9d2e562..2ac601f34 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -656,7 +656,7 @@ present in the citation."
(org-open-file file '(4))
(if (not (equal "json" (file-name-extension file)))
(bibtex-search-entry key)
- (let ((regexp (rx "\"id\":" (0+ (any "[ \t]")) "\"" (literal key) "\"")))
+ (let ((regexp (rx-to-string `(seq "\"id\":" (0+ (any "[ \t]")) "\"" ,key
"\"") t)))
(goto-char (point-min))
(re-search-forward regexp)
(search-backward "{")
diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index a7a2a6042..f3c2fd901 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -248,10 +248,10 @@ If nil then the Chicago author-date style is used as a
fallback.")
"Alist mapping locator names to locators.")
(defconst org-cite-csl--label-regexp
- (rx word-start
- (regexp (regexp-opt (mapcar #'car org-cite-csl--label-alist) t))
- (0+ digit)
- (or word-start line-end (any ?\s ?\t)))
+ (rx-to-string `(seq word-start
+ (regexp ,(regexp-opt (mapcar #'car
org-cite-csl--label-alist) t))
+ (0+ digit)
+ (or word-start line-end (any ?\s ?\t))) t)
"Regexp matching a label in a citation reference suffix.
Label is in match group 1.")
diff --git a/lisp/oc.el b/lisp/oc.el
index 1d704fb03..43a3bb444 100644
--- a/lisp/oc.el
+++ b/lisp/oc.el
@@ -924,7 +924,7 @@ the same object, call `org-cite-adjust-punctuation' first."
(concat final-punct "\"") previous nil nil 2))
(new-next
(replace-regexp-in-string
- (rx string-start (literal final-punct))
+ (rx-to-string `(seq string-start ,final-punct) t)
"" next)))
(org-element-set-element previous new-prev)
(org-element-set-element next new-next)
Maybe I have missed other similar problems.
Does someone have better ideas how to restore compatibility with older
emacs versions? 24.3 is declared in org.el. Ubuntu 20.04 (latest long
time support release) has 26.3.
Re: [BUG] org-goto slows down org-set-property
On 10/07/2021 22:47, Maxim Nikulin wrote: It is rather annoying that C-c C-x p `org-set-property' may be quite slow if a file is large enough. (I do not consider it huge however.) There is noticeable delay before the prompt for property name appears in minibuffer. Accidentally I have noticed that sometimes it is fast. Problem appears after first jump using C-u C-c C-j `org-goto'. Actually a jump is not required, it is enough to get jump (refile) targets. It is strange. Merely 3500 markers created by org-refile-cache in 2.2Mb file ruin performance of regexps in that buffer. I would expect either no influence of markers at all since search is a read-only operation or some negligible penalty proportional to fraction of markers in relation to total amount of characters. Look at the numbers for nm-test that is just some regexp searches from `org-buffer-property-keys'. Performance is restored after clearing of the cache. #+begin_src elisp (defun nm-tst () (org-with-wide-buffer (goto-char (point-min)) (while (re-search-forward org-property-start-re nil t) (org-get-property-block) (outline-next-heading)) nil)) (org-refile-cache-clear) (let ((org-refile-targets '((nil :maxlevel . 6))) (org-refile-use-outline-path 'file) (org-refile-use-cache t) (iters 10)) (cons (list (org-version)) (mapcar (lambda (f) (append (list f) (benchmark-run iters (funcall f (list #'nm-tst ; #'org-buffer-property-keys #'org-refile-get-targets #'nm-tst ; #'org-buffer-property-keys #'org-refile-cache-clear #'nm-tst #+end_src #+RESULTS: | 9.4.6 | | || | nm-tst | 0.044981942 | 0 |0.0 | | org-refile-get-targets | 1.748572638 | 8 | 0.387660137993 | | nm-tst | 0.393022201 | 0 |0.0 | | org-refile-cache-clear | 0.001787078 | 0 |0.0 | | nm-tst | 0.035731803 | 0 |0.0 | It seems, it is better to drop org-refile-cache completely. It has some design problems making it rather fragile. At the same time a patch can be applied that improves performance of `org-refile-get-targets' by a factor of at least 2 for (org-refile-use-outline-path 'file). Emacs-26.3
Bug: "DEFINITION NOT FOUND" for footnote in Org manual
At https://orgmode.org/manual/Export-Settings.html#DOCF124 and (renumbered to "fn:123") in doc/org-manual.org, a foot- note is defined as "DEFINITION NOT FOUND": | [tim@vagabond ~/src/org-mode]$ git grep -2 'DEFINITION NOT FOUND' -- doc/org-manual.org | doc/org-manual.org-this timestamp are exported. | doc/org-manual.org- | doc/org-manual.org:[fn:123] DEFINITION NOT FOUND. | doc/org-manual.org- | doc/org-manual.org-[fn:124] At the moment, some export back-ends do not obey this | [tim@vagabond ~/src/org-mode]$ The original footnote seems to have been added with commit e30aed8f0c62e74633f7a0398340f9bd7bdfa3cc (but personally I don't find that text very helpful).
