Re: [PATCH] org.el: Improve automatic fast tag selection keys (was: Odd characters in the fast tags selection interface)
Hanno Perrey 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
Re: Odd characters in the fast tags selection interface
Ihor Radchenko writes:
> Hanno 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
signature.asc
Description: PGP signature
Re: Odd characters in the fast tags selection interface
Hanno 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
Re: Odd characters in the fast tags selection 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!
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
Re: Odd characters in the fast tags selection interface
Hanno 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
Odd characters in the fast tags selection interface
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
test_org-set-tags-command.org
Description: Lotus Organizer
