[PATCH] Allow tags containing capital letters in org-agenda-filter
Hi, I recently noticed that org-agenda-filter does not match tags with capital letters because all the stored tags in agenda are downcased. The attached patch is fixing the issue. Though, ideally, it would be better if agenda filter were case-sensitive for tags. Best, Ihor >From 9d7a966497458bdb0ab5e5171d2bab1fa8612bc5 Mon Sep 17 00:00:00 2001 From: Ihor Radchenko Date: Thu, 11 Feb 2021 12:03:15 +0800 Subject: [PATCH] Allow tags containing capital letters in org-agenda-filter * lisp/org-agenda.el (org-agenda-filter): Downcase tags in the search string provided by user. This is needed because all the tags stored in 'tags text property are downcased. Example when old code did not work is a tag like COMMON. The user would not expect a need to input +|-common in the agenda filter instead of +|-COMMON. The latter would only result in "COMMON filter ignored because tag/category is not represented". --- lisp/org-agenda.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 90920ef41..0845d0ca6 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7767,8 +7767,8 @@ the variable `org-agenda-auto-exclude-function'." (setq s (replace-regexp-in-string ; Remove the temporary special string. "~~~" "-" (match-string 3 f-string))) (cond - ((member s tag-list) - (add-to-list 'ft (concat pm s) 'append 'equal)) + ((member (downcase s) tag-list) + (add-to-list 'ft (concat pm (downcase s)) 'append 'equal)) ((member s category-list) (add-to-list 'fc (concat pm ; Remove temporary double quotes. (replace-regexp-in-string "\"\\(.*\\)\"" "\\1" s)) -- 2.26.2
Re: Typing latency
i have a note that in org 8.0+ they have to be after the todo kw. however, i /always/ interpret this to mean after the todo kw position i.e. after where the todo kw would go if it is not there. thus "* #[A] take out garbage" is legit. "* #[A] NEXT take out garbage" is wrong. "* NEXT take out #[A] garbage" feels wrong to me as an assignment of priority to that entry. org maint seem to agree with me. On 2/10/21, Eric S Fraga wrote: > On Tuesday, 9 Feb 2021 at 23:33, Ihor Radchenko wrote: >> I have the following in my config to speed things up: >> >> (setq org-priority-regexp "^\\*+.*\\(\\[#\\([A-Z0-9]+\\)\\] ?\\)") > > Should this not be the default setting? Reading the documentation, > priority cookies must be in a headline with a TODO item. The current > default setting is not anchored to headlines so does seem to be both > expensive and not consistent with the documentation. Your suggestion is > more consistent. > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: local variables and export processing in hooks
Am 09. Februar 2021 um 14:21 Uhr +0100 schrieb Sébastien Miquel: > Eric S Fraga writes: > > I tried but this doesn't seem to be propagated to the export as the > > export works on a copy of the buffer, not the buffer itself. That's > > what #+BIND is for, supposedly... > > I think this buffer copy preserves local variables. I know I use a such a > local variable and its value can be read during macro expansion. > > It seems the org-export-before-parsing-hook functions are run before the > #+BIND values are collected (see org-export-as in ox.el). Interesting. I did not know about #+BIND, but just today I came about the issue where I needed file-local variables to be available both in the org-export-before-parsing-hook and in macro expansion. I circumvented the problem by picking the original buffer out of `buffer-list' and temporaryly switching to that buffer with `with-current-buffer'. Now I wonder whether #+BIND is more elegant. But my macro expansion function modifies a buffer-local variable. Does #+BIND allow for that, so that the changed value is available in the original org buffer? -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu |For security: Passau, Germany | kont...@guelker.eu| () Avoid HTML e-mail European Union | PGP: see homepage | /\ http://asciiribbon.org
Re: OT: M-S-$ Not Working
Maxim Nikulin writes: >> Were you able to get any assistance with this on the Emacs devel list? > > There was a thread in 2009, no results however. Unsure if it reasonable > to raise the question again without a proposal how to solve the problem. > > https://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00031.html > I think it would be worth raising again. There has been significant changes since 2009 (that message was prior to Emacs 23 release), especially with respect to CJK, MULE, UTF-8 and input methods. It is possible new solutions are now available. -- Tim Cross
Re: OT: M-S-$ Not Working
On 07/02/2021 00:18, Tim Cross wrote: I've not seen many editors with the same level of support for different alphabets and writing direction as Emacs and there are many keyborad layouts which don't include the '$' key. At the end of the day, it really just comes down to mapping of key codes - the 'image' on the key itself (and even the location) is largely irrelevant. To have reliable shortcuts, it necessary to have a way to obtain "canonical" Latin key when another layout is chosen. E.g. comma position depends on layout. In emacs only key symbol from current layout is available, information on symbols in other groups for the same keycode is lost. Even layout change events are hidden from lisp code. Were you able to get any assistance with this on the Emacs devel list? There was a thread in 2009, no results however. Unsure if it reasonable to raise the question again without a proposal how to solve the problem. https://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00031.html I have found a couple more workarounds on github. E.g. listening dbus messages related to keyboard layout changes (specific to particular desktop environment). In some sense they are similar to mine setup. Like it or not, computers are very english centric (and US english at that). In gnome some Xkb-related features suitable for layouts (groups) are broken due to their focus on input methods for Chinese-Korean-Japanese scripts.
Re: local variables and export processing in hooks
On 09/02/2021 19:06, Eric S Fraga wrote: On Tuesday, 9 Feb 2021 at 12:30, to...@tuxteam.de wrote: Perhaps a file local variable? I tried but this doesn't seem to be propagated to the export as the export works on a copy of the buffer, not the buffer itself. That's what #+BIND is for, supposedly... I have seen that you have achieved your goal with local variables. Concerning BIND, there was a topic a month ago that bind has to be enabled explicitly. Unsure if it makes parameter available early enough however: https://orgmode.org/list/87pn2iz3kr@posteo.net/ On 06/01/2021 18:51, Juan Manuel Macías wrote: > (setq org-export-allow-bind-keywords t)
Re: local variables and export processing in hooks
On Tuesday, 9 Feb 2021 at 14:21, Sébastien Miquel wrote: > I think this buffer copy preserves local variables. I know I use a > such a local variable and its value can be read during macro > expansion. It does. Not sure what happened but I thought setting a file local variable was the first thing I tried. Hey hum. Sorry for the noise and thank you. Works just fine now. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f
Re: Typing latency
On Tuesday, 9 Feb 2021 at 23:33, Ihor Radchenko wrote: > I have the following in my config to speed things up: > > (setq org-priority-regexp "^\\*+.*\\(\\[#\\([A-Z0-9]+\\)\\] ?\\)") Should this not be the default setting? Reading the documentation, priority cookies must be in a headline with a TODO item. The current default setting is not anchored to headlines so does seem to be both expensive and not consistent with the documentation. Your suggestion is more consistent. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f
