* Odd characters in the fast tags selection interface
@ 2022-08-04 21:41 Hanno
2022-08-05 2:12 ` Ihor Radchenko
0 siblings, 1 reply; 10+ messages in thread
From: Hanno @ 2022-08-04 21:41 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 1328 bytes --]
Hej,
I use the fast tags selection interface (=org-set-tags-command= with
=org-use-fast-tag-selection= set to =t=) to quickly add several tags to
a heading. I have both tags and keys defined in
=org-tag-persistent-alist= and use
=org-complete-tags-always-offer-all-agenda-tags= to complete the
selection with various other tags that I have used in my agenda files.
However, I have noticed some oddities with the characters that are being
associated as keys to the entries in the interface:
- after "a..z" runs out, '{', '|' and '}' are being used which seems
reasonable -- but after that, I get '\200' and similar before reaching
'©'...
- when defining my own keys, they are not displayed in the top; instead
their characters are missing in the 'a'..'z' range leaving more room
for odd and very difficult-to-type characters
I am therefore wondering: can I limit the range of characters being
used? Can I force characters defined in =org-tag-persistent-alist= to be
shown on top? Is this behavior maybe a bug?
The org version I am using is around 2 months old at this point I am afraid.
I attach an org-file that demonstrates the issue when opened with =emacs
-Q= and after evaluating the included source block.
Thanks and cheers,
Hanno
--
Hanno Perrey
https://hoowl.se
[-- Attachment #1.2: Type: text/html, Size: 1476 bytes --]
[-- Attachment #2: test_org-set-tags-command.org --]
[-- Type: application/vnd.lotus-organizer, Size: 5935 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Odd characters in the fast tags selection interface
2022-08-04 21:41 Odd characters in the fast tags selection interface Hanno
@ 2022-08-05 2:12 ` Ihor Radchenko
2022-08-05 10:54 ` Hanno
0 siblings, 1 reply; 10+ messages in thread
From: Ihor Radchenko @ 2022-08-05 2:12 UTC (permalink / raw)
To: Hanno; +Cc: emacs-orgmode
Hanno <hanno@hoowl.se> writes:
> However, I have noticed some oddities with the characters that are being
> associated as keys to the entries in the interface:
>
> - after "a..z" runs out, '{', '|' and '}' are being used which seems
> reasonable -- but after that, I get '\200' and similar before reaching
> '©'...
This is indeed true, but what can we do? There are only that many
characters in the keyboard. We may instead start using two-key
combinations for tags beyond #26, similar to org-capture. Patches are
welcome!
> - when defining my own keys, they are not displayed in the top; instead
> their characters are missing in the 'a'..'z' range leaving more room
> for odd and very difficult-to-type characters
>
> I am therefore wondering: can I limit the range of characters being
> used? Can I force characters defined in =org-tag-persistent-alist= to be
> shown on top? Is this behavior maybe a bug?
I think that it would make sense to have `org-tag-persistent-alist`
staff being shown on top. Unless there are objections I can merge this
trivial change.
> I attach an org-file that demonstrates the issue when opened with =emacs
> -Q= and after evaluating the included source block.
Thanks! This was very helpful.
Best,
Ihor
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Odd characters in the fast tags selection interface
2022-08-05 2:12 ` Ihor Radchenko
@ 2022-08-05 10:54 ` Hanno
2022-08-06 8:13 ` Ihor Radchenko
0 siblings, 1 reply; 10+ messages in thread
From: Hanno @ 2022-08-05 10:54 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
>> - after "a..z" runs out, '{', '|' and '}' are being used which seems
>> reasonable -- but after that, I get '\200' and similar before reaching
>> '©'...
>
>This is indeed true, but what can we do? There are only that many
>characters in the keyboard. We may instead start using two-key
>combinations for tags beyond #26, similar to org-capture. Patches are
>welcome!
Thanks for the fast reply and fully agreed! I would indeed argue that automatically generated keys are not useful beyond a certain number (N=26?) as they could change with new tags and thus are hard to memorize. And taking in >N random choices every time is hardly "fast select" anymore.
In fact, the docstring for =org-fast-tag-selection= says that only a-z would be automatically assigned. That sounds reasonable to me (otherwise one can define more keys via =org-tag-persistent-alist=). Maybe this is a bug after all? If more than 26 choices are desired, maybe A-Z (i.e. capital letters) could extend the list before more unusual characters?
What do you think?
I am not at my computer right now but could try to come up with a patch later.
>> - when defining my own keys, they are not displayed in the top; instead
>> their characters are missing in the 'a'..'z' range leaving more room
>> for odd and very difficult-to-type characters
>I think that it would make sense to have `org-tag-persistent-alist`
>staff being shown on top. Unless there are objections I can merge this
>trivial change.
Thanks, that already improves the usability a lot!
Thanks and cheers,
Hanno
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Odd characters in the fast tags selection interface
2022-08-05 10:54 ` Hanno
@ 2022-08-06 8:13 ` Ihor Radchenko
2022-08-07 17:55 ` [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface) Hanno Perrey
2022-08-07 23:47 ` Odd characters in the fast tags selection interface Christopher M. Miles
0 siblings, 2 replies; 10+ messages in thread
From: Ihor Radchenko @ 2022-08-06 8:13 UTC (permalink / raw)
To: Hanno; +Cc: emacs-orgmode
Hanno <hanno@hoowl.se> writes:
>>> - after "a..z" runs out, '{', '|' and '}' are being used which seems
>>> reasonable -- but after that, I get '\200' and similar before reaching
>>> '©'...
>>
>>This is indeed true, but what can we do? There are only that many
>>characters in the keyboard. We may instead start using two-key
>>combinations for tags beyond #26, similar to org-capture. Patches are
>>welcome!
>
> Thanks for the fast reply and fully agreed! I would indeed argue that automatically generated keys are not useful beyond a certain number (N=26?) as they could change with new tags and thus are hard to memorize. And taking in >N random choices every time is hardly "fast select" anymore.
>
> In fact, the docstring for =org-fast-tag-selection= says that only a-z would be automatically assigned. That sounds reasonable to me (otherwise one can define more keys via =org-tag-persistent-alist=). Maybe this is a bug after all? If more than 26 choices are desired, maybe A-Z (i.e. capital letters) could extend the list before more unusual characters?
>
> What do you think?
>
> I am not at my computer right now but could try to come up with a patch later.
I am not sure. Omitting (random) part of the tags sounds awkward - some
tags will be assigned keys and some not. I guess something that will
improve the current situation would be simply not printing chars beyond
a-z, while still listing all the tags - it will be less awkward compared
to current situation when a key is printed but cannot be used anyway.
Or we may provide "paging" approach that will re-assign a-z keys when
user presses C-n/C-p. Though I do not like this idea too much because we
have a more universal menu backend in works at
https://orgmode.org/list/87zgisvuu5.fsf@localhost Adding new feature to
tag menu does not feel like a good direction to go. If we decide to go
this way at the end, we may, at least, also need to update
org-fast-todo-selection along similar lines.
Finally, we may simply not list tags with keys beyond "z" at all only
indicating that there are more by showing some text at the end of the
menu.
>>> - when defining my own keys, they are not displayed in the top; instead
>>> their characters are missing in the 'a'..'z' range leaving more room
>>> for odd and very difficult-to-type characters
>>I think that it would make sense to have `org-tag-persistent-alist`
>>staff being shown on top. Unless there are objections I can merge this
>>trivial change.
>
> Thanks, that already improves the usability a lot!
Done on main via a0b21e3f1.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a0b21e3f1c131bc6ee6398e2d3dda20944d6b358
--
Ihor Radchenko,
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface)
2022-08-06 8:13 ` Ihor Radchenko
@ 2022-08-07 17:55 ` Hanno Perrey
2022-08-07 23:42 ` Christopher M. Miles
` (2 more replies)
2022-08-07 23:47 ` Odd characters in the fast tags selection interface Christopher M. Miles
1 sibling, 3 replies; 10+ messages in thread
From: Hanno Perrey @ 2022-08-07 17:55 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]
> I am not sure. Omitting (random) part of the tags sounds awkward - some
> tags will be assigned keys and some not. I guess something that will
> improve the current situation would be simply not printing chars beyond
> a-z, while still listing all the tags - it will be less awkward compared
> to current situation when a key is printed but cannot be used anyway.
Good point. I attach a patch that does just that. After the '~'
character, only "space" is assigned -- which feels like a hack, but
means that the selection key field is empty and that the fields are
still aligned nicely. Actually selection any of these items is not
possible as space is assigned to clearing the tags. Should this break
anything that I have missed in my (brief) tests, please let me know!
Additionally, the range A-Z is used once 'z' is reached before assigning
non-alphabetic (but reasonably-reachable) characters. In case that
description is difficult to follow, I attach a screenshot of the
modified code in action.
Please note that I have not (yet) assigned copyright to the FSF.
However, I believe that these changes are still trivial enough to
qualify as TINYCHANGE.
> Or we may provide "paging" approach that will re-assign a-z keys when
> user presses C-n/C-p. Though I do not like this idea too much because we
> have a more universal menu backend in works at
> https://orgmode.org/list/87zgisvuu5.fsf@localhost Adding new feature to
> tag menu does not feel like a good direction to go. If we decide to go
> this way at the end, we may, at least, also need to update
> org-fast-todo-selection along similar lines.
Thanks for pointing out that thread, I missed it earlier. It does sound
like a good idea to wait with more fundamental changes until potential
changes to the backend are settled.
> Finally, we may simply not list tags with keys beyond "z" at all only
> indicating that there are more by showing some text at the end of the
> menu.
That might be an alternative, as I think not even all tags are shown
now. Let me know should you rather go down that route instead.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-Improve-automatic-fast-tag-selection-keys.patch --]
[-- Type: text/x-diff, Size: 1285 bytes --]
From cdaa585cea7481aca31148350e77a86f22512d0c Mon Sep 17 00:00:00 2001
From: Hanno Perrey <hanno@hoowl.se>
Date: Sun, 7 Aug 2022 19:44:18 +0200
Subject: [PATCH] org.el: Improve automatic fast tag selection keys
* lisp/org.el (org-fast-tag-selection): After automatically assigning
a-z as keys for selection, offer A-Z range. Continue with characters up
to tilde character before showing only blanks. Replaces previous logic
where also hard-to-type characters were assigned.
TINYCHANGE
---
lisp/org.el | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 8bc123e47..d48a44602 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11762,7 +11762,13 @@ Returns the new tags string, or nil to not change the current settings."
(while (or (rassoc char ntable) (rassoc char table))
(setq char (1+ char)))
(setq c2 c1))
- (setq c (or c2 char)))
+ (setq c (or c2
+ (if (> char ?~)
+ ?\s
+ char)))
+ ;; consider characters A-Z after a-z.
+ (if (equal char ?z)
+ (setq char ?A)))
(when ingroup (push tg (car groups)))
(setq tg (org-add-props tg nil 'face
(cond
--
2.34.1
[-- Attachment #3: 20220807_19h13m58s_grim.png --]
[-- Type: image/png, Size: 160839 bytes --]
[-- Attachment #4: Type: text/plain, Size: 34 bytes --]
--
Hanno Perrey
https://hoowl.se
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface)
2022-08-07 17:55 ` [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface) Hanno Perrey
@ 2022-08-07 23:42 ` Christopher M. Miles
2022-08-08 13:24 ` Ihor Radchenko
[not found] ` <62f04f7c.d40a0220.9da67.0a2cSMTPIN_ADDED_BROKEN@mx.google.com>
2 siblings, 0 replies; 10+ messages in thread
From: Christopher M. Miles @ 2022-08-07 23:42 UTC (permalink / raw)
To: Hanno Perrey; +Cc: Ihor Radchenko, emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 4301 bytes --]
I agree to improve the tag selection UI. The hard-to-type characters is
not necessary. It's hard to type, and not match the purpose of "fast tag
selection", and will break tags alignment.
Also need minor improvement on alignment of tags "group tag".
Please see my screenshot attachment.
Hanno Perrey <hanno@hoowl.se> writes:
>> I am not sure. Omitting (random) part of the tags sounds awkward - some
>> tags will be assigned keys and some not. I guess something that will
>> improve the current situation would be simply not printing chars beyond
>> a-z, while still listing all the tags - it will be less awkward compared
>> to current situation when a key is printed but cannot be used anyway.
>
> Good point. I attach a patch that does just that. After the '~'
> character, only "space" is assigned -- which feels like a hack, but
> means that the selection key field is empty and that the fields are
> still aligned nicely. Actually selection any of these items is not
> possible as space is assigned to clearing the tags. Should this break
> anything that I have missed in my (brief) tests, please let me know!
>
> Additionally, the range A-Z is used once 'z' is reached before assigning
> non-alphabetic (but reasonably-reachable) characters. In case that
> description is difficult to follow, I attach a screenshot of the
> modified code in action.
>
> Please note that I have not (yet) assigned copyright to the FSF.
> However, I believe that these changes are still trivial enough to
> qualify as TINYCHANGE.
>
>> Or we may provide "paging" approach that will re-assign a-z keys when
>> user presses C-n/C-p. Though I do not like this idea too much because we
>> have a more universal menu backend in works at
>> https://orgmode.org/list/87zgisvuu5.fsf@localhost Adding new feature to
>> tag menu does not feel like a good direction to go. If we decide to go
>> this way at the end, we may, at least, also need to update
>> org-fast-todo-selection along similar lines.
>
> Thanks for pointing out that thread, I missed it earlier. It does sound
> like a good idea to wait with more fundamental changes until potential
> changes to the backend are settled.
>
>> Finally, we may simply not list tags with keys beyond "z" at all only
>> indicating that there are more by showing some text at the end of the
>> menu.
>
> That might be an alternative, as I think not even all tags are shown
> now. Let me know should you rather go down that route instead.
>
> [2. text/x-diff; 0001-org.el-Improve-automatic-fast-tag-selection-keys.patch]
> From cdaa585cea7481aca31148350e77a86f22512d0c Mon Sep 17 00:00:00 2001
> From: Hanno Perrey <hanno@hoowl.se>
> Date: Sun, 7 Aug 2022 19:44:18 +0200
> Subject: [PATCH] org.el: Improve automatic fast tag selection keys
>
> * lisp/org.el (org-fast-tag-selection): After automatically assigning
> a-z as keys for selection, offer A-Z range. Continue with characters up
> to tilde character before showing only blanks. Replaces previous logic
> where also hard-to-type characters were assigned.
>
> TINYCHANGE
> ---
> lisp/org.el | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 8bc123e47..d48a44602 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -11762,7 +11762,13 @@ Returns the new tags string, or nil to not change the current settings."
> (while (or (rassoc char ntable) (rassoc char table))
> (setq char (1+ char)))
> (setq c2 c1))
> - (setq c (or c2 char)))
> + (setq c (or c2
> + (if (> char ?~)
> + ?\s
> + char)))
> + ;; consider characters A-Z after a-z.
> + (if (equal char ?z)
> + (setq char ?A)))
> (when ingroup (push tg (car groups)))
> (setq tg (org-add-props tg nil 'face
> (cond
> --
> 2.34.1
>
> [3. image/png; 20220807_19h13m58s_grim.png]...
--
[ 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
[-- Attachment #1.2: screenshot --]
[-- Type: image/png, Size: 3865291 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Odd characters in the fast tags selection interface
2022-08-06 8:13 ` Ihor Radchenko
2022-08-07 17:55 ` [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface) Hanno Perrey
@ 2022-08-07 23:47 ` Christopher M. Miles
1 sibling, 0 replies; 10+ messages in thread
From: Christopher M. Miles @ 2022-08-07 23:47 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Hanno, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]
Ihor Radchenko <yantar92@gmail.com> writes:
> Hanno <hanno@hoowl.se> writes:
>
>>>> - after "a..z" runs out, '{', '|' and '}' are being used which seems
>>>> reasonable -- but after that, I get '\200' and similar before reaching
>>>> '©'...
>>>
>>>This is indeed true, but what can we do? There are only that many
>>>characters in the keyboard. We may instead start using two-key
>>>combinations for tags beyond #26, similar to org-capture. Patches are
>>>welcome!
>>
>> Thanks for the fast reply and fully agreed! I would indeed argue that automatically generated keys
>> are not useful beyond a certain number (N=26?) as they could change with new tags and thus are
>> hard to memorize. And taking in >N random choices every time is hardly "fast select" anymore.
>>
>> In fact, the docstring for =org-fast-tag-selection= says that only a-z would be automatically
>> assigned. That sounds reasonable to me (otherwise one can define more keys via
>> =org-tag-persistent-alist=). Maybe this is a bug after all? If more than 26 choices are desired,
>> maybe A-Z (i.e. capital letters) could extend the list before more unusual characters?
>>
>> What do you think?
>>
>> I am not at my computer right now but could try to come up with a patch later.
>
> I am not sure. Omitting (random) part of the tags sounds awkward - some
> tags will be assigned keys and some not. I guess something that will
> improve the current situation would be simply not printing chars beyond
> a-z, while still listing all the tags - it will be less awkward compared
> to current situation when a key is printed but cannot be used anyway.
>
> Or we may provide "paging" approach that will re-assign a-z keys when
> user presses C-n/C-p. Though I do not like this idea too much because we
> have a more universal menu backend in works at
> https://orgmode.org/list/87zgisvuu5.fsf@localhost Adding new feature to
> tag menu does not feel like a good direction to go. If we decide to go
> this way at the end, we may, at least, also need to update
> org-fast-todo-selection along similar lines.
I prefer this second way, currently I don't know how to scroll tag
selection buffer. By using "paging" can solve the assigned keys problem.
Also used for other tags.
>
> Finally, we may simply not list tags with keys beyond "z" at all only
> indicating that there are more by showing some text at the end of the
> menu.
>
>>>> - when defining my own keys, they are not displayed in the top; instead
>>>> their characters are missing in the 'a'..'z' range leaving more room
>>>> for odd and very difficult-to-type characters
>>>I think that it would make sense to have `org-tag-persistent-alist`
>>>staff being shown on top. Unless there are objections I can merge this
>>>trivial change.
>>
>> Thanks, that already improves the usability a lot!
>
> Done on main via a0b21e3f1.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a0b21e3f1c131bc6ee6398e2d3dda20944d6b358
--
[ 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface)
2022-08-07 17:55 ` [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface) Hanno Perrey
2022-08-07 23:42 ` Christopher M. Miles
@ 2022-08-08 13:24 ` Ihor Radchenko
[not found] ` <62f04f7c.d40a0220.9da67.0a2cSMTPIN_ADDED_BROKEN@mx.google.com>
2 siblings, 0 replies; 10+ messages in thread
From: Ihor Radchenko @ 2022-08-08 13:24 UTC (permalink / raw)
To: Hanno Perrey; +Cc: emacs-orgmode
Hanno Perrey <hanno@hoowl.se> writes:
> Good point. I attach a patch that does just that. After the '~'
> character, only "space" is assigned -- which feels like a hack, but
> means that the selection key field is empty and that the fields are
> still aligned nicely. Actually selection any of these items is not
> possible as space is assigned to clearing the tags. Should this break
> anything that I have missed in my (brief) tests, please let me know!
>
> Additionally, the range A-Z is used once 'z' is reached before assigning
> non-alphabetic (but reasonably-reachable) characters. In case that
> description is difficult to follow, I attach a screenshot of the
> modified code in action.
Thanks!
Applied onto main via 4db67da68 with minor amendments like adding double
space between sentences and capitalizing first word in sentences.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4db67da68db820184bd9d4208c4f8bd7370ee9de
> Please note that I have not (yet) assigned copyright to the FSF.
> However, I believe that these changes are still trivial enough to
> qualify as TINYCHANGE.
You are good to go until 15LOC total contribution combined.
>> Finally, we may simply not list tags with keys beyond "z" at all only
>> indicating that there are more by showing some text at the end of the
>> menu.
>
> That might be an alternative, as I think not even all tags are shown
> now. Let me know should you rather go down that route instead.
We may, but then we need support from other users. Hiding staff will be
a breaking change, unlike the patch you propose, which barely improves
visuals.
--
Ihor Radchenko,
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] org-fast-tag-selection: Make group tags separator not break alignment
[not found] ` <62f04f7c.d40a0220.9da67.0a2cSMTPIN_ADDED_BROKEN@mx.google.com>
@ 2022-08-08 13:36 ` Ihor Radchenko
2022-08-22 12:02 ` Ihor Radchenko
0 siblings, 1 reply; 10+ messages in thread
From: Ihor Radchenko @ 2022-08-08 13:36 UTC (permalink / raw)
To: numbchild; +Cc: Hanno Perrey, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
"Christopher M. Miles" <numbchild@gmail.com> writes:
> I agree to improve the tag selection UI. The hard-to-type characters is
> not necessary. It's hard to type, and not match the purpose of "fast tag
> selection", and will break tags alignment.
>
> Also need minor improvement on alignment of tags "group tag".
>
> Please see my screenshot attachment.
This should be easy. See the attached patch.
Note that the patch does not consider a case of narrow screen, but it is
not like the menu is designed with such considerations, so I do not see
much point trying hard to cover the edge cases.
--
Ihor Radchenko,
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-fast-tag-selection-Make-group-tags-separator-not.patch --]
[-- Type: text/x-patch, Size: 1134 bytes --]
From 1cd18001f982092534664bc257b470fd9855b839 Mon Sep 17 00:00:00 2001
Message-Id: <1cd18001f982092534664bc257b470fd9855b839.1659965569.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Mon, 8 Aug 2022 21:30:04 +0800
Subject: [PATCH] org-fast-tag-selection: Make group tags separator not break
alignment
* lisp/org.el (org-fast-tag-selection): Start " : " group tags
separator before tag column in the menu.
Reported in https://orgmode.org/list/62f04f7c.d40a0220.9da67.0a2cSMTPIN_ADDED_BROKEN@mx.google.com
---
lisp/org.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 3b1caecf1..f7625dac7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11749,7 +11749,9 @@ (defun org-fast-tag-selection (current inherited table &optional todo-table)
(while (equal (car tbl) '(:newline))
(insert "\n")
(setq tbl (cdr tbl)))))
- ((equal e '(:grouptags)) (insert " : "))
+ ((equal e '(:grouptags))
+ (delete-backward-char 3)
+ (insert " : "))
(t
(setq tg (copy-sequence (car e)) c2 nil)
(if (cdr e)
--
2.35.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] org-fast-tag-selection: Make group tags separator not break alignment
2022-08-08 13:36 ` [PATCH] org-fast-tag-selection: Make group tags separator not break alignment Ihor Radchenko
@ 2022-08-22 12:02 ` Ihor Radchenko
0 siblings, 0 replies; 10+ messages in thread
From: Ihor Radchenko @ 2022-08-22 12:02 UTC (permalink / raw)
To: numbchild; +Cc: Hanno Perrey, emacs-orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> Subject: [PATCH] org-fast-tag-selection: Make group tags separator not break
> alignment
Applied onto main via 090dacb0a.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=090dacb0a9a3aac02b8cfa0e25f607d1f3cd2064
--
Ihor Radchenko,
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-08-22 12:03 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-08-04 21:41 Odd characters in the fast tags selection interface Hanno
2022-08-05 2:12 ` Ihor Radchenko
2022-08-05 10:54 ` Hanno
2022-08-06 8:13 ` Ihor Radchenko
2022-08-07 17:55 ` [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface) Hanno Perrey
2022-08-07 23:42 ` Christopher M. Miles
2022-08-08 13:24 ` Ihor Radchenko
[not found] ` <62f04f7c.d40a0220.9da67.0a2cSMTPIN_ADDED_BROKEN@mx.google.com>
2022-08-08 13:36 ` [PATCH] org-fast-tag-selection: Make group tags separator not break alignment Ihor Radchenko
2022-08-22 12:02 ` Ihor Radchenko
2022-08-07 23:47 ` Odd characters in the fast tags selection interface Christopher M. Miles
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).