* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-13 18:41 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Ihor Radchenko
@ 2024-12-13 22:09 ` Gabriel Santos
2024-12-14 9:57 ` Ihor Radchenko
2024-12-13 22:57 ` Suhail Singh
` (4 subsequent siblings)
5 siblings, 1 reply; 43+ messages in thread
From: Gabriel Santos @ 2024-12-13 22:09 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-devel, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 6022 bytes --]
Greetings,
I'll go through the examples found on this e-mail and
suggest the menu command I find best for the proposed
scenarios.
Below is how I think these options could be used.
context-menu-mode
No particular target, should mostly be used for actions on
the whole buffer or on a region, or all particular elements
defined.
Example: Org -> Headings -> Demote Headings
transient
Also no particular target, but should be used for commands that
would require a menu for interaction, such as exporting and capturing.
Example 1: org-export-*dispatch* -> transient menu
Example 2: org-capture -> transient menu
Example 3: org-attach -> transient menu
which-key
On a target, list actions that could be performed on it.
embark
Can be used to replace which-key in customization.
But, despite saying this, I have it configured to use which-key as its menu.
Ihor Radchenko <yantar92@posteo.net> writes:
> I have raised the topic of refactoring Org mode menu systems during
> EmacsConf in <https://emacsconf.org/2024/talks/org-update/>
I saw the talk live, really excited for the future of Org!
> The initial idea was replacing the self-written menu code in Org with
> built-in transient.el.
>
> Later, during OrgMeetup a number of people raised concerns that
> transient may sometimes be an overkill, and that some people may prefer
> alternative UIs. In particular, embark and context-menu-mode were
> mentioned.
Personally, I'd prefer for built-in packages/functionality to be considered first.
The consideration for context-menu for me is particularly intriguing, as there's
a lot of functionality already included in Org's context menu.
> (I am CCing the discussion participants and potentially interested
> maintainers)
Hope to see their responses to this.
I'm just a common user, so my opinions should be taken with a grain of salt.
> In Org mode (although not only in Org mode, looking at the success of
> embark.el), we often have a UI model where users call an "action"
> command (like org-ctrl-c-ctrl-c or org-open-at-point) followed by
> interactive selection among multiple actions.
I don't often use org-ctrl-c-ctrl-c, but now that I've seen the interaction
menu for properties as an example, I'd say the best option for it would be
which-key, as it's a simpler menu.
> For example, org-open-at-point on a heading with multiple links inside
> will raise a section buffer listing all the links - pressing a number
> will open the corresponding link.
I'd consider which-key again for this.
> Another example (see the example patch below), which is a
> work-in-progress patch for Org citation system, is "following" a
> citation. To "follow" citation may mean multiple things including but
> not limited to: (1) going to citation record in the bibliography file;
> (2) following URL; (3) downloading .pdf file for a citation; etc.
> **The list of "follow" actions may be customized by users**
This is similar to the functions available in the following package:
<https://github.com/emacs-citar/citar>
It also allows for opening the bibliography, links, notes, and files
connected to the citation.
I use it with embark:
<https://github.com/emacs-citar/citar/blob/main/citar-embark.el>
> The general UI flow in these scenarios will be:
>
> 1. User calls "action" with cursor at certain syntax element
> 2. Action menu is displayed, showing the available actions/targets (dynamically built)
> 3. User selects the action/target
I'm not sure what the best option would be for displaying targets, but which-key
should be able to cover most cases that would require "simpler" menus for actions.
I'd also add in that it could be considered over transient if its dynamically built.
I tend to associate transient with "static" options.
> This UI flow can be implemented using context menus, which-key popups,
> transient menus, and also using embark (where the way menu is displayed
> can be customized).
>
> All the 4 approaches represent different UI models with various
> strengths and weaknesses:
>
> - transient has a very flexible layout builder where the menu items can
> be arranged granularly, but intercepts the main loop disrupting
> certain keyboard-based workflows
> - which-key does not stand on the way and integrates well into Emacs'
> key binding model, but provides little flexibility for menu layout
It has options for setting the pop-up type and position. Could this help with
flexibility?
> - embark stays in the middle between which-key and transient, making use
> of transient keymaps and allowing a custom menu renderer
> - context-menu-mode provides mouse experience
>
> I am wondering if we can work out some universal API to plug the
> described action->menu->selection model into the UI that user prefers.
I'd say that this is the best options out of all of them, but, as you said:
> "I am wondering if we can work out [...]"
This would require considerable work.
> Tentatively, I am thinking about the following:
>
> For a given Emacs "prefix" command (e.g. org-open-at-point), we define a
> set of customizations:
>
> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
> PROPS is a plist defining extra properties like key-binding, display
> string, maybe something else to be used in the future.
> 2. Menu interface to use (transient, context-menu, embark, which-key)
> 3. Layout settings for the specific interfaces. For example, transient
> layout definition.
>
> WDYT?
>
> Best,
> Ihor
On this described state (list of actions), which-key would be the
best option according to my definition.
But, on the current state of org-open-at-point (shows more targets),
as I commented previously, there's no menu that I associate with:
"Act on target, display a list of other targets."
Maybe context-menu would be the closest one, but I wouldn't consider
which-key or embark, these are more related to functions.
Regards,
--
*Gabriel Santos*
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos
@ 2024-12-14 9:57 ` Ihor Radchenko
2024-12-14 10:59 ` Gabriel Santos
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-14 9:57 UTC (permalink / raw)
To: Gabriel Santos; +Cc: emacs-devel, emacs-orgmode
Gabriel Santos <gabrielsantosdesouza@disroot.org> writes:
> context-menu-mode
> No particular target, should mostly be used for actions on
> the whole buffer or on a region, or all particular elements
> defined.
>
> Example: Org -> Headings -> Demote Headings
> ...
> Personally, I'd prefer for built-in packages/functionality to be considered first.
We will definitely try to support built-ins first and foremost.
I mentioned embark as an example of alternative UI.
Also, embark might be a candidate for upstreaming.
> The consideration for context-menu for me is particularly intriguing, as there's
> a lot of functionality already included in Org's context menu.
This is not right. I think you are confusing ordinary menu bar and
context menu. Context menu is "right click" menu that will display
different items depending on where you click. Org mode currently does
not have context-menu-mode integration (we should fix this deficiency)
> I don't often use org-ctrl-c-ctrl-c, but now that I've seen the interaction
> menu for properties as an example, I'd say the best option for it would be
> which-key, as it's a simpler menu.
My conclusion so far is that there is no "best" for every user. We
should ideally support user-customized menu UI. The main question is how
to do it.
>> This UI flow can be implemented using context menus, which-key popups,
>> transient menus, and also using embark (where the way menu is displayed
>> can be customized).
>>
>> All the 4 approaches represent different UI models with various
>> strengths and weaknesses:
> ...
> It has options for setting the pop-up type and position. Could this help with
> flexibility?
May you elaborate what "it" refers to?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-14 9:57 ` Ihor Radchenko
@ 2024-12-14 10:59 ` Gabriel Santos
2024-12-14 13:10 ` Ihor Radchenko
0 siblings, 1 reply; 43+ messages in thread
From: Gabriel Santos @ 2024-12-14 10:59 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-devel, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]
>> The consideration for context-menu for me is particularly intriguing, as there's
>> a lot of functionality already included in Org's context menu.
>
> This is not right. I think you are confusing ordinary menu bar and
> context menu. Context menu is "right click" menu that will display
> different items depending on where you click. Org mode currently does
> not have context-menu-mode integration (we should fix this deficiency)
Maybe it's some third-party package I'm using, but right-cliking on an Org
buffer gives me a lot of options:
<https://0x0.st/XF1y.png>
>> I don't often use org-ctrl-c-ctrl-c, but now that I've seen the interaction
>> menu for properties as an example, I'd say the best option for it would be
>> which-key, as it's a simpler menu.
>
> My conclusion so far is that there is no "best" for every user. We
> should ideally support user-customized menu UI. The main question is how
> to do it.
I also agree with this conclusion. Hope others can contribute with
suggestions of how to go about it.
>>> This UI flow can be implemented using context menus, which-key popups,
>>> transient menus, and also using embark (where the way menu is displayed
>>> can be customized).
>>>
>>> All the 4 approaches represent different UI models with various
>>> strengths and weaknesses:
>> ...
>> It has options for setting the pop-up type and position. Could this help with
>> flexibility?
>
> May you elaborate what "it" refers to?
Sorry, seems I forgot to clarify. "It" in this context was referring to which-key.
It has the following variables for altering (window) display:
- which-key-popup-type
- which-key-side-window-location
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-13 18:41 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Ihor Radchenko
2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos
@ 2024-12-13 22:57 ` Suhail Singh
2024-12-14 9:59 ` Ihor Radchenko
2024-12-14 1:16 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Panayotis Manganaris
` (3 subsequent siblings)
5 siblings, 1 reply; 43+ messages in thread
From: Suhail Singh @ 2024-12-13 22:57 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode,
Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi,
Justin Burkett
Ihor Radchenko <yantar92@posteo.net> writes:
> Tentatively, I am thinking about the following:
>
> For a given Emacs "prefix" command (e.g. org-open-at-point), we define a
> set of customizations:
>
> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
> PROPS is a plist defining extra properties like key-binding, display
> string, maybe something else to be used in the future.
> 2. Menu interface to use (transient, context-menu, embark, which-key)
> 3. Layout settings for the specific interfaces. For example, transient
> layout definition.
>
> WDYT?
By "display string" do you mean a description of the action? Or would
that be additional?
Hopefully, the description of each action will be a first-class member
of the "List of possible actions". Or is the intent that the
description be taken from the form representing an action (e.g. a defun,
a lambda etc).
--
Suhail
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-13 22:57 ` Suhail Singh
@ 2024-12-14 9:59 ` Ihor Radchenko
2024-12-14 14:30 ` Suhail Singh
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-14 9:59 UTC (permalink / raw)
To: Suhail Singh
Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode,
Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi,
Justin Burkett
Suhail Singh <suhailsingh247@gmail.com> writes:
>> For a given Emacs "prefix" command (e.g. org-open-at-point), we define a
>> set of customizations:
>>
>> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
>> PROPS is a plist defining extra properties like key-binding, display
>> string, maybe something else to be used in the future.
>> 2. Menu interface to use (transient, context-menu, embark, which-key)
>> 3. Layout settings for the specific interfaces. For example, transient
>> layout definition.
>
> By "display string" do you mean a description of the action? Or would
> that be additional?
I mean some way to define how the action should be displayed in the
menu. It may be a full string or just a description to be appended to
the action name, or something else.
> Hopefully, the description of each action will be a first-class member
> of the "List of possible actions". Or is the intent that the
> description be taken from the form representing an action (e.g. a defun,
> a lambda etc).
Using a docstring sounds like a good idea. But it is a bit early to
decide these details. I'd like to discuss the more general design first.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-14 9:59 ` Ihor Radchenko
@ 2024-12-14 14:30 ` Suhail Singh
0 siblings, 0 replies; 43+ messages in thread
From: Suhail Singh @ 2024-12-14 14:30 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Suhail Singh, Tor-björn Claesson, emacs-devel, emacs-orgmode,
Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi,
Justin Burkett
Ihor Radchenko <yantar92@posteo.net> writes:
>> Hopefully, the description of each action will be a first-class member
>> of the "List of possible actions". Or is the intent that the
>> description be taken from the form representing an action (e.g. a defun,
>> a lambda etc).
>
> Using a docstring sounds like a good idea. But it is a bit early to
> decide these details. I'd like to discuss the more general design first.
I agree that it may be premature to think about implementation details
of how docstrings are stored etc. However, I would like to ensure that
any discussion of the design of ways-to-choose-an-action-at-point
include self-documentation and self-discovery in the desiderata.
Perhaps this goes without saying, in which case please ignore this
message. However, it's too important to be left to chance.
--
Suhail
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
2024-12-13 18:41 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Ihor Radchenko
2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos
2024-12-13 22:57 ` Suhail Singh
@ 2024-12-14 1:16 ` Panayotis Manganaris
2024-12-14 10:08 ` Ihor Radchenko
2024-12-14 10:50 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? indieterminacy
` (2 subsequent siblings)
5 siblings, 1 reply; 43+ messages in thread
From: Panayotis Manganaris @ 2024-12-14 1:16 UTC (permalink / raw)
To: Ihor Radchenko, Tor-björn Claesson, emacs-devel
Cc: emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
charles.choi, Justin Burkett
Hello. I'm very much an elisp amateur, but one of my main motives for
learning has been to make use of emacs' many beautiful UI systems.
Therefore, I'll provide my comments from a designer perspective and
avoid implementation detail.
Ihor Radchenko <yantar92@posteo.net> writes:
> TL;DR: We are in the process of designing a more unified selection
> interface for Org mode
Thanks to Tor-björn, Jonas, Ihor, and everyone else for this work. I've
learned much by following this thread.
> a number of people raised concerns that transient may sometimes be an
> overkill
I agree with others that transient is overkill for most of the menus in
org-mode. A counter argument, going by the patches exchanged here, might
be that transient menus are a clean and scalable approach.
I've not tried the in-dev transient follow processor, but I imagine it
is similar to the old org-ref (John Kitchin) hydra menu. I used org-ref
for years, and enjoyed how its menu united many features, including
- a system analogous to org-cite follow processors for navigating to sources/notes
- a system akin to reftex-mode for org
- a system for downloading new references and making new bibliography entries
With this level of complexity, a transient menu seems like the modern
weapon of choice for a similar feature set. Only, wait, I stopped using
org-ref.
Long story short, I concluded that treating org-mode like a nexus for
these intertwined features was, at least, encouraging my bad habit of
treating org-mode as an "everything app."
I have since delegated the task of populating my personal library to a
dedicated reference manager. I started using latex-mode and reftex to
write papers, thus gaining more typesetting control and making version
management much easier. I still use org to take notes, but now enjoy a
much more stable and focused configuration.
I tell this story as an (anecdotal) case study for how a powerful menu
can be less productive in the long run. Org-ref's hydra menu is not to
blame for my bad decisions but, at least in-part, I used it (and even
extended it) because a greater man put it there.
Scalable design is an invitation to scale. Perhaps the wise know better.
Anyway, the simple tasks of navigating from a citation link to a copy of
the original document, its URL, or an associated note is achievable with
a completing-read (helm, counsel, vertico, etc.) interface.
Transient is overkill.
> This UI flow can be implemented using context menus [...] embark
I like org's context menus, but I like embark better. I do think it
would be very generous of org to delegate its own contextual actions to
embark if so configured.
I'll elaborate:
As is, I like to run org-babel code block functions through embark, I
only wish there were more of them to run. I find this to be far superior
in every way to binding equivalent key chords for the mode.
Also, for me, embark-bindings and embark-prefix-help-command have
completely replaced which-key for discovering key bindings on-the-fly.
> I am wondering if we can work out some universal API to plug the
> described action->menu->selection model into the UI that user prefers.
I support this idea in principle.
> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
> PROPS is a plist defining extra properties like key-binding, display
> string, maybe something else to be used in the future.
I would focus on associating just enough metadata with functions to
enable using them with embark. I really have no idea what the best way
to do this is. This seems to be the biggest missing piece.
Maybe in the short term we just crowd-source some embark configuration
on WORG.
Menus should of course be useful without embark. If the goal here is to
deprecate many of org's ad-hoc interfaces, I think the natural default
replacement for most is completing-read. I may be completely wrong.
> 2. Menu interface to use (transient, context-menu, embark, which-key)
It seems like Tor-björn and Ihor have already laid the groundwork for
using transient in this way. So, I'll just say bravo. Regardless of my
opinion on transient overuse, it looks like great work.
On the other hand, e.g. if the org export dispatch menu isn't transient,
it should be. Seems obvious to me.
> 3. Layout settings for the specific interfaces. For example, transient
> layout definition.
It is important to avoid making more org-mode-specific UI abstractions.
Whatever the solution, it is important that the UI implementations
tapped to take over help share the maintenance burden.
In this way, I reckon most interface customization can be done in hooks.
> WDYT?
Ideally org-mode uses established APIs rather than making another.
Thanks for reading, and thanks for the chance to contribute.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
2024-12-14 1:16 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Panayotis Manganaris
@ 2024-12-14 10:08 ` Ihor Radchenko
2024-12-15 21:20 ` Samuel Wales
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-14 10:08 UTC (permalink / raw)
To: Panayotis Manganaris
Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode,
Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, Justin Burkett
Panayotis Manganaris <panos.manganaris@gmail.com> writes:
> Menus should of course be useful without embark. If the goal here is to
> deprecate many of org's ad-hoc interfaces, I think the natural default
> replacement for most is completing-read. I may be completely wrong.
For the existing interfaces, we are not going to change things in
incompatible ways. The idea is to keep the existing menus working as
similarly as possible compared to the current ad-hoc menus.
So, no, we are not going to replace things with completing-read.
Not by default.
But what I hope to see is a way for users to customize the UI to their
preference. Without touching the defaults.
> On the other hand, e.g. if the org export dispatch menu isn't transient,
> it should be. Seems obvious to me.
Yes. That's where we will have to use transient.
This discussion mostly concerns simpler cases when user needs to choose
from a list.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
2024-12-14 10:08 ` Ihor Radchenko
@ 2024-12-15 21:20 ` Samuel Wales
2024-12-16 17:54 ` Ihor Radchenko
0 siblings, 1 reply; 43+ messages in thread
From: Samuel Wales @ 2024-12-15 21:20 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
Justin Burkett
a couple of quick and somewhat obvious comments. i use VERY large
fonts with a maximized gui emacs [vt / maximized urxvt when needed],
still resulting in, throughout emacs, often, a smaller number of
screen lines or columns than content, even with my usual one window
per frame. most org menus respect this and can be scrolled or
tweaked. just wanted compatibility to be in the specs. especially,
to make sure no functionality is unreachable, but also where possible
to modify column numbers / fill to look ok. i am slowly trying
transient in gptel and still getting used to it.
next, i use org-mouse and think it's wonderful. generally, when using
a computer, i use mouse-only or kb-only, but not the combination.
mouseability was mentioned, but just wanted, where possible, the
ability to do most things using only mouse in addition to only kb.
and, where possible, org-mouse compatibility or replacement, whichever
is deemed best.
On Sat, Dec 14, 2024 at 3:08 AM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Panayotis Manganaris <panos.manganaris@gmail.com> writes:
>
> > Menus should of course be useful without embark. If the goal here is to
> > deprecate many of org's ad-hoc interfaces, I think the natural default
> > replacement for most is completing-read. I may be completely wrong.
>
> For the existing interfaces, we are not going to change things in
> incompatible ways. The idea is to keep the existing menus working as
> similarly as possible compared to the current ad-hoc menus.
> So, no, we are not going to replace things with completing-read.
> Not by default.
>
> But what I hope to see is a way for users to customize the UI to their
> preference. Without touching the defaults.
>
> > On the other hand, e.g. if the org export dispatch menu isn't transient,
> > it should be. Seems obvious to me.
>
> Yes. That's where we will have to use transient.
> This discussion mostly concerns simpler cases when user needs to choose
> from a list.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> 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>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
2024-12-15 21:20 ` Samuel Wales
@ 2024-12-16 17:54 ` Ihor Radchenko
2024-12-17 2:08 ` Samuel Wales
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-16 17:54 UTC (permalink / raw)
To: Samuel Wales
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
Justin Burkett
Samuel Wales <samologist@gmail.com> writes:
> a couple of quick and somewhat obvious comments. i use VERY large
> fonts with a maximized gui emacs [vt / maximized urxvt when needed],
> still resulting in, throughout emacs, often, a smaller number of
> screen lines or columns than content, even with my usual one window
> per frame. most org menus respect this and can be scrolled or
> tweaked. just wanted compatibility to be in the specs. especially,
> to make sure no functionality is unreachable, but also where possible
> to modify column numbers / fill to look ok. i am slowly trying
> transient in gptel and still getting used to it.
Thanks for the important input!
Does transient look fine on your screen? If yes, we should not have a
problem.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
2024-12-16 17:54 ` Ihor Radchenko
@ 2024-12-17 2:08 ` Samuel Wales
2024-12-17 2:24 ` Samuel Wales
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Samuel Wales @ 2024-12-17 2:08 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
Justin Burkett
thanks for interest.
the transient menu i am trying uses more character columns and
lines than window (c-u m-x gptel-send). transient's solution
does not work well for me.
1) wrapping
- 3 text columns. rightmost text column (header: "Response
to") has lines that wrap at rhs (not word) to lhs (not
beginning of that text column), putting lines between items
in first text column.
- (for clarity: by rhs and lhs, i mean where text goes, at
smallest usable font, maximized gui frame, no wm
decoration, one window in frame, 2 fringes)
- BEST SOLUTION FOR ME: wrap at word boundaries, /within each
text column/, as is done when one exports org tables to
html
2) vertical scrolling
- BEST SOLUTION FOR ME: SPC DEL, as is done in org export
menu
- in transient, SPC and DEL make echo area say ? for help.
? makes the message go away but nothing else changes.
another ? brings up the help for function gptel-send.
i'd want scrolling.
- transient is vertically scrollable using up down arrows
and c-v m-v, but those are harder on rsi and harder to
locate on my kb than SPC DEL
- i did not notice that there are lines below window. if
there isn't an indicator, BEST LOCATION FOR ME: left fringe
in cases where fringe exists.
3) transient does not allow changing font size with
text-scale-increase/decrease (but a smaller font would not be
legible)
- transient:
- Archive: gnu
- Version: 0.8.1
- dependency issue before explicitly installing this version.
- emacs 29.4
- org 9.7.16
- gptel ~/.emacs.d/elpa/gptel-0.9.6.0.20241115.83706
some current org menus, although REALLY GOOD, have possibly
regressed in recent years. in any case, for example, export is
scrollable; todo kw is not, so i cannot access some todo kw.
i put a lot of effort into this response, hope it makes sense.
On Mon, Dec 16, 2024 at 10:52 AM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Samuel Wales <samologist@gmail.com> writes:
>
> > a couple of quick and somewhat obvious comments. i use VERY large
> > fonts with a maximized gui emacs [vt / maximized urxvt when needed],
> > still resulting in, throughout emacs, often, a smaller number of
> > screen lines or columns than content, even with my usual one window
> > per frame. most org menus respect this and can be scrolled or
> > tweaked. just wanted compatibility to be in the specs. especially,
> > to make sure no functionality is unreachable, but also where possible
> > to modify column numbers / fill to look ok. i am slowly trying
> > transient in gptel and still getting used to it.
>
> Thanks for the important input!
> Does transient look fine on your screen? If yes, we should not have a
> problem.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> 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>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
2024-12-17 2:08 ` Samuel Wales
@ 2024-12-17 2:24 ` Samuel Wales
2024-12-17 18:04 ` Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)) Ihor Radchenko
2024-12-18 10:47 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Jonas Bernoulli
2 siblings, 0 replies; 43+ messages in thread
From: Samuel Wales @ 2024-12-17 2:24 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
Justin Burkett
thanks for interest.
the transient menu i am trying uses more character columns and
lines than window (c-u m-x gptel-send). transient's solution
does not work well for me.
1) wrapping
- 3 text columns. rightmost text column (header: "Response
to") has lines that wrap at rhs (not word) to lhs (not
beginning of that text column), putting lines between items
in first text column.
- (for clarity: by rhs and lhs, i mean where text goes, at
smallest usable font, maximized gui frame, no wm
decoration, one window in frame, 2 fringes)
- BEST SOLUTION FOR ME: wrap at word boundaries, /within each
text column/, as is done when one exports org tables to
html
2) vertical scrolling
- BEST SOLUTION FOR ME: SPC DEL, as is done in org export
menu
- in transient, SPC and DEL make echo area say ? for help.
? makes the message go away but nothing else changes.
another ? brings up the help for function gptel-send.
i'd want scrolling.
- transient is vertically scrollable using up down arrows
and c-v m-v, but those are harder on rsi and harder to
locate on my kb than SPC DEL
- i did not notice that there are lines below window. if
there isn't an indicator, BEST LOCATION FOR ME: left fringe
in cases where fringe exists.
3) transient does not allow changing font size with
text-scale-increase/decrease (but a smaller font would not be
legible)
- transient:
- Archive: gnu
- Version: 0.8.1
- dependency issue before explicitly installing this version.
- emacs 29.4
- org 9.7.16
- gptel ~/.emacs.d/elpa/gptel-0.9.6.0.
20241115.83706
some current org menus, although REALLY GOOD, have possibly
regressed in recent years. in any case, for example, export is
scrollable; todo kw is not, so i cannot access some todo kw.
i put a lot of effort into this response, hope it makes sense.
[p.s. attempting re-send as reply to all as my first response went to
ihor only. i hope this is not too jarring as a top post and sent to
all recipients. idk which recipients are included 1] because others
included them easrlier in the thread/conversation vs. 2] because they
are not on the emacs devel list or the org list an want copies.]
[p.p.s. this webmail ui drives me nuts and some solecisms are due to
it being inaccessible [e.g. no compose button showing, not clear how
to change subject header.]
> On Mon, Dec 16, 2024 at 10:52 AM Ihor Radchenko <yantar92@posteo.net> wrote:
> >
> > Samuel Wales <samologist@gmail.com> writes:
> >
> > > a couple of quick and somewhat obvious comments. i use VERY large
> > > fonts with a maximized gui emacs [vt / maximized urxvt when needed],
> > > still resulting in, throughout emacs, often, a smaller number of
> > > screen lines or columns than content, even with my usual one window
> > > per frame. most org menus respect this and can be scrolled or
> > > tweaked. just wanted compatibility to be in the specs. especially,
> > > to make sure no functionality is unreachable, but also where possible
> > > to modify column numbers / fill to look ok. i am slowly trying
> > > transient in gptel and still getting used to it.
> >
> > Thanks for the important input!
> > Does transient look fine on your screen? If yes, we should not have a
> > problem.
> >
> > --
> > Ihor Radchenko // yantar92,
> > Org mode maintainer,
> > 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>
>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [flat|nested] 43+ messages in thread* Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-17 2:08 ` Samuel Wales
2024-12-17 2:24 ` Samuel Wales
@ 2024-12-17 18:04 ` Ihor Radchenko
2024-12-18 7:19 ` Samuel Wales
2024-12-18 10:47 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Jonas Bernoulli
2 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-17 18:04 UTC (permalink / raw)
To: Samuel Wales
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, Justin Burkett
Samuel Wales <samologist@gmail.com> writes:
> thanks for interest.
>
> the transient menu i am trying uses more character columns and
> lines than window (c-u m-x gptel-send). transient's solution
> does not work well for me.
Just to be 100% clear, existing Org menus will not disappear any time
soon. Even if we change menus to transient, I will make sure to leave a
customization to switch back.
New menus will probably use transient/other external menu UI though.
As for your response, I will provide some comments, but I also suggest
you to send a bug report to Emacs, so that Jonas has a chance to pay
close attention.
> 1) wrapping
> - 3 text columns. rightmost text column (header: "Response
> to") has lines that wrap at rhs (not word) to lhs (not
> beginning of that text column), putting lines between items
> in first text column.
> - (for clarity: by rhs and lhs, i mean where text goes, at
> smallest usable font, maximized gui frame, no wm
> decoration, one window in frame, 2 fringes)
> - BEST SOLUTION FOR ME: wrap at word boundaries, /within each
> text column/, as is done when one exports org tables to
> html
In other words, you need visual-line-mode inside transient buffers. Do I
understand correctly?
> 2) vertical scrolling
> - BEST SOLUTION FOR ME: SPC DEL, as is done in org export
> menu
> - in transient, SPC and DEL make echo area say ? for help.
> ? makes the message go away but nothing else changes.
> another ? brings up the help for function gptel-send.
> i'd want scrolling.
> - transient is vertically scrollable using up down arrows
> and c-v m-v, but those are harder on rsi and harder to
> locate on my kb than SPC DEL
I think you can bind SPC and DEL in `transient-base-map' to make things
easier for you. I agree that SPC/DEL doing scrolling are expected from a
menu.
> - i did not notice that there are lines below window. if
> there isn't an indicator, BEST LOCATION FOR ME: left fringe
> in cases where fringe exists.
How do you usually know it?
On my side, there is an indication after I customized
(setq-default indicate-buffer-boundaries 'left)
> 3) transient does not allow changing font size with
> text-scale-increase/decrease (but a smaller font would not be
> legible)
This sounds like an omission. Again, you can use `transient-base-map' to
work around, but it is better to be discussed as a dedicated bug report.
> some current org menus, although REALLY GOOD, have possibly
> regressed in recent years. in any case, for example, export is
> scrollable; todo kw is not, so i cannot access some todo kw.
AFAIU, org-fast-todo-selection interface was never scrollable. At least,
it looks like it was the case 17 years ago. May I know more details
about which exact menu you are talking about and when did scroll stopped
working? I may be missing something.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-17 18:04 ` Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)) Ihor Radchenko
@ 2024-12-18 7:19 ` Samuel Wales
2024-12-18 10:52 ` Jonas Bernoulli
2024-12-18 17:59 ` Ihor Radchenko
0 siblings, 2 replies; 43+ messages in thread
From: Samuel Wales @ 2024-12-18 7:19 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, Justin Burkett
On Tue, Dec 17, 2024 at 11:02 AM Ihor Radchenko <yantar92@posteo.net> wrote:
> In other words, you need visual-line-mode inside transient buffers. Do I
> understand correctly?
that sounds similar to current behavior.
my suggestion would wrap to the character column of the beginning of
the third text column.
similar to html for non-first table cells. not lhs.
lorem ipsum akemashite omedetou hello
asjnfaksjdnf ajsk dfnkajsd fkaj sf this line
long
code likely exists someplace in core for this. in org or a browser.
> I think you can bind SPC and DEL in `transient-base-map' to make things
> easier for you. I agree that SPC/DEL doing scrolling are expected from a
> menu.
thank you.
it would make sense, for me, usually, for SPC to wrap around to first
page in menus, so that DEL is not strictly needed. transient wraps
for arrow; idk SPC.
> On my side, there is an indication after I customized
> (setq-default indicate-buffer-boundaries 'left)
you are absolutely right. i have had something similar forever.
the reason i didn't notice it is 1] for me the fringe glyph is small
-- can it be larger? and 2] the cursor is always at bol in transient
in my case for that menu, so the fringe is less noticeable next to a
large block cursor.
also, i just noticed that transient has a dim horizontal line at eob
in that menu which is thoughtful and useful. i don't know what face
it uses.
> which exact menu you are talking about and when did scroll stopped
> working? I may be missing something.
i don't think you're missing anything significant. i didn't mean to
make you do forensics. it was merely a recollection of a possibility;
i'd find it useful if todo kw scrolled, but i cannot say that it
regressed.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-18 7:19 ` Samuel Wales
@ 2024-12-18 10:52 ` Jonas Bernoulli
2024-12-19 1:42 ` Samuel Wales
2024-12-19 1:50 ` Samuel Wales
2024-12-18 17:59 ` Ihor Radchenko
1 sibling, 2 replies; 43+ messages in thread
From: Jonas Bernoulli @ 2024-12-18 10:52 UTC (permalink / raw)
To: Samuel Wales, Ihor Radchenko
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, Justin Burkett
If I understand the below correctly, you prefer noticeable truncation
in combination with convenient scrolling support, over wrapping (which
is bound to look bad and confusing, even if we optimize some more).
That is my own preference (too?), and we can look into further tweaks
in that direction next year.
Jonas
Samuel Wales <samologist@gmail.com> writes:
> On Tue, Dec 17, 2024 at 11:02 AM Ihor Radchenko <yantar92@posteo.net> wrote:
>> In other words, you need visual-line-mode inside transient buffers. Do I
>> understand correctly?
>
> that sounds similar to current behavior.
>
> my suggestion would wrap to the character column of the beginning of
> the third text column.
>
> similar to html for non-first table cells. not lhs.
>
> lorem ipsum akemashite omedetou hello
> asjnfaksjdnf ajsk dfnkajsd fkaj sf this line
> long
>
> code likely exists someplace in core for this. in org or a browser.
>
>> I think you can bind SPC and DEL in `transient-base-map' to make things
>> easier for you. I agree that SPC/DEL doing scrolling are expected from a
>> menu.
>
> thank you.
>
> it would make sense, for me, usually, for SPC to wrap around to first
> page in menus, so that DEL is not strictly needed. transient wraps
> for arrow; idk SPC.
>
>> On my side, there is an indication after I customized
>> (setq-default indicate-buffer-boundaries 'left)
>
> you are absolutely right. i have had something similar forever.
>
> the reason i didn't notice it is 1] for me the fringe glyph is small
> -- can it be larger? and 2] the cursor is always at bol in transient
> in my case for that menu, so the fringe is less noticeable next to a
> large block cursor.
>
> also, i just noticed that transient has a dim horizontal line at eob
> in that menu which is thoughtful and useful. i don't know what face
> it uses.
>
>> which exact menu you are talking about and when did scroll stopped
>> working? I may be missing something.
>
> i don't think you're missing anything significant. i didn't mean to
> make you do forensics. it was merely a recollection of a possibility;
> i'd find it useful if todo kw scrolled, but i cannot say that it
> regressed.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-18 10:52 ` Jonas Bernoulli
@ 2024-12-19 1:42 ` Samuel Wales
2024-12-19 1:50 ` Samuel Wales
1 sibling, 0 replies; 43+ messages in thread
From: Samuel Wales @ 2024-12-19 1:42 UTC (permalink / raw)
To: Jonas Bernoulli
Cc: Ihor Radchenko, Panayotis Manganaris, Tor-björn Claesson,
emacs-devel, emacs-orgmode, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
Justin Burkett
my idea is to wrap within the column of text in the menu. e.g. the
3rd column of text. like reflowing. it seems better than all other
solutions i came up with.
to me, the problem with truncation is that it requires horizontal
scrolling. in my case, vertical scrolling is preferable to horizontal
scrolling.
by analogy, consider websites with pars that do not reflow. if you
use large text, and every line goes past rhs. then you have to
horizontally scroll both right and left for every line of the
paragraph.
with text columns, this can sometimes be less of a problem, if you can
fit a column, but it is a problem if long lines exist in a single
column, or if you want to compare columns line by line.
horizontal scrolling is useful on general principles, if combined with
toggle truncate lines, so i like the idea of adding it, but it does
not solve this particular problem.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-18 10:52 ` Jonas Bernoulli
2024-12-19 1:42 ` Samuel Wales
@ 2024-12-19 1:50 ` Samuel Wales
1 sibling, 0 replies; 43+ messages in thread
From: Samuel Wales @ 2024-12-19 1:50 UTC (permalink / raw)
To: Jonas Bernoulli
Cc: Ihor Radchenko, Panayotis Manganaris, Tor-björn Claesson,
emacs-devel, emacs-orgmode, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
Justin Burkett
my idea is to wrap within the column of text in the menu. e.g. the
3rd column of text. like reflowing. it seems better than all other
solutions i came up with.
to me, the problem with truncation is that it requires horizontal
scrolling. in my case, vertical scrolling is preferable to horizontal
scrolling.
by analogy, consider websites with pars that do not reflow. if you
use large text, and every line goes past rhs. then you have to
horizontally scroll both right and left for every line of the
paragraph.
with text columns, this can sometimes be less of a problem, if you can
fit a column, but it is a problem if long lines exist in a single
column, or if you want to compare columns line by line.
horizontal scrolling is useful on general principles, if combined with
toggle truncate lines, so i like the idea of adding it, but it does
not solve this particular problem.
On Wed, Dec 18, 2024 at 3:53 AM Jonas Bernoulli <jonas@bernoul.li> wrote:
>
> If I understand the below correctly, you prefer noticeable truncation
> in combination with convenient scrolling support, over wrapping (which
> is bound to look bad and confusing, even if we optimize some more).
>
> That is my own preference (too?), and we can look into further tweaks
> in that direction next year.
>
> Jonas
>
>
> Samuel Wales <samologist@gmail.com> writes:
>
> > On Tue, Dec 17, 2024 at 11:02 AM Ihor Radchenko <yantar92@posteo.net> wrote:
> >> In other words, you need visual-line-mode inside transient buffers. Do I
> >> understand correctly?
> >
> > that sounds similar to current behavior.
> >
> > my suggestion would wrap to the character column of the beginning of
> > the third text column.
> >
> > similar to html for non-first table cells. not lhs.
> >
> > lorem ipsum akemashite omedetou hello
> > asjnfaksjdnf ajsk dfnkajsd fkaj sf this line
> > long
> >
> > code likely exists someplace in core for this. in org or a browser.
> >
> >> I think you can bind SPC and DEL in `transient-base-map' to make things
> >> easier for you. I agree that SPC/DEL doing scrolling are expected from a
> >> menu.
> >
> > thank you.
> >
> > it would make sense, for me, usually, for SPC to wrap around to first
> > page in menus, so that DEL is not strictly needed. transient wraps
> > for arrow; idk SPC.
> >
> >> On my side, there is an indication after I customized
> >> (setq-default indicate-buffer-boundaries 'left)
> >
> > you are absolutely right. i have had something similar forever.
> >
> > the reason i didn't notice it is 1] for me the fringe glyph is small
> > -- can it be larger? and 2] the cursor is always at bol in transient
> > in my case for that menu, so the fringe is less noticeable next to a
> > large block cursor.
> >
> > also, i just noticed that transient has a dim horizontal line at eob
> > in that menu which is thoughtful and useful. i don't know what face
> > it uses.
> >
> >> which exact menu you are talking about and when did scroll stopped
> >> working? I may be missing something.
> >
> > i don't think you're missing anything significant. i didn't mean to
> > make you do forensics. it was merely a recollection of a possibility;
> > i'd find it useful if todo kw scrolled, but i cannot say that it
> > regressed.
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-18 7:19 ` Samuel Wales
2024-12-18 10:52 ` Jonas Bernoulli
@ 2024-12-18 17:59 ` Ihor Radchenko
2024-12-19 1:48 ` Samuel Wales
1 sibling, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-18 17:59 UTC (permalink / raw)
To: Samuel Wales
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, Justin Burkett
Samuel Wales <samologist@gmail.com> writes:
> the reason i didn't notice it is 1] for me the fringe glyph is small
> -- can it be larger?
Not easily, but doable. You need to define a new fringe bitmap with
`define-fringe-bitmap' and then set it in `fringe-indicator-alist'.
Here is an example:
(define-fringe-bitmap
'sand-clock
[#b11111111
#b10000001
#b01000010
#b01000010
#b01101110
#b00111100
#b00011000
#b00100100
#b01000010
#b01011010
#b11111111
#b11111111])
It is not allowed to create fridges wider than 16 pixels.
>> which exact menu you are talking about and when did scroll stopped
>> working? I may be missing something.
>
> i don't think you're missing anything significant. i didn't mean to
> make you do forensics. it was merely a recollection of a possibility;
> i'd find it useful if todo kw scrolled, but i cannot say that it
> regressed.
The problem is that SPC in `org-fast-todo-selection' is already used to
clear the todo keyword. (Same for tag menu).
What about making TAB show a normal completion prompt? Will it be usable?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread* Re: Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-18 17:59 ` Ihor Radchenko
@ 2024-12-19 1:48 ` Samuel Wales
0 siblings, 0 replies; 43+ messages in thread
From: Samuel Wales @ 2024-12-19 1:48 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, Justin Burkett
i like the efficient single-key todo kw selection and its colored menu
in org enough that i prefer it to completion.
good point about spc clearing the selection. personally, i would
prefer an option for spc to scroll and wrap around. del or c-k or so
might clear the selection. but i wouldn't want to disrupt other
users's muscle memory.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)
2024-12-17 2:08 ` Samuel Wales
2024-12-17 2:24 ` Samuel Wales
2024-12-17 18:04 ` Transient: accessibility problems for users who need to use large fonts (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)) Ihor Radchenko
@ 2024-12-18 10:47 ` Jonas Bernoulli
2024-12-19 17:42 ` Internal variables and symbols in transient (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)) Ihor Radchenko
2024-12-19 18:11 ` Alternative defaults for visually impaired users? " Ihor Radchenko
2 siblings, 2 replies; 43+ messages in thread
From: Jonas Bernoulli @ 2024-12-18 10:47 UTC (permalink / raw)
To: Samuel Wales, Ihor Radchenko
Cc: Panayotis Manganaris, Tor-björn Claesson, emacs-devel,
emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena,
Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh,
Justin Burkett
Hello!
Samuel Wales <samologist@gmail.com> writes:
> thanks for interest.
I've worked with other users with impaired vision to improve their
experience with Transient before and tend to prioritize that work.
That being said, the end-of-year crunch is upon us, so I likely won't
find the time to do anything beyond what I have already done today.
You should update Transient to the development version. I found two
regressions affecting the features described below and fixed them this
morning. These fixes will make it into the next release, scheduled for
very early 2025.
> the transient menu i am trying uses more character columns and
> lines than window (c-u m-x gptel-send).
I didn't notice that you effectively said "too small in both
dimensions", so the first advice below, might not be as useful as I
initially though. Or it might, let's see.
> transient's solution does not work well for me.
>
> 1) wrapping
> - 3 text columns.
You can tell Transient to only ever use a single column, and
additionally you can always display the menu in a new window on the
right instead of at the bottom.
(setq transient-force-single-column t)
(setq transient-display-buffer-action
'(display-buffer-in-side-window
(side . right)
(dedicated . t)
(inhibit-same-window . t)))
> rightmost text column (header: "Response
> to") has lines that wrap at rhs (not word) to lhs (not
> beginning of that text column), putting lines between items
> in first text column.
> - (for clarity: by rhs and lhs, i mean where text goes, at
> smallest usable font, maximized gui frame, no wm
> decoration, one window in frame, 2 fringes)
> - BEST SOLUTION FOR ME: wrap at word boundaries, /within each
> text column/, as is done when one exports org tables to
> html
> 2) vertical scrolling
> - BEST SOLUTION FOR ME: SPC DEL, as is done in org export
> menu
> - in transient, SPC and DEL make echo area say ? for help.
> ? makes the message go away but nothing else changes.
> another ? brings up the help for function gptel-send.
> i'd want scrolling.
> - transient is vertically scrollable using up down arrows
> and c-v m-v, but those are harder on rsi and harder to
> locate on my kb than SPC DEL
You can add your preferred bindings like so:
(keymap-set transient-map "SPC" #'transient-scroll-up)
(keymap-set transient-map "DEL" #'transient-scroll-down)
Some Transient menus to *not* prevent commands from other keymaps to
be invoked while the menu is active. If you bind "SPC" in all menus
as shown above, then that will shadow the regular binding, making it
hard to insert a space.
[However, I'll have to deeply think about the bindings used for commands
available in all transient menus in general soon, but this is not the
time and place.]
[I'll likely also have to support horizontal scrolling eventually.]
> - i did not notice that there are lines below window. if
> there isn't an indicator, BEST LOCATION FOR ME: left fringe
> in cases where fringe exists.
This enters "I'll look into that next year" territory.
The color of that line actually indicates whether a menu allows
"outside" commands to be invoked while the menu is active.
Most users don't notice this piece of information, myself included.
You can hide it, if you wish, using:
(setq transient-mode-line-format nil)
> 3) transient does not allow changing font size with
> text-scale-increase/decrease (but a smaller font would not be
> legible)
To permanently use a different font size in transient menus use:
(defun transient-i-shrunk-the-glyphs ()
(text-scale-set -1)) ; or 1 to grow
(add-hook 'transient-setup-buffer-hook #'transient-i-shrunk-the-glyphs)
To allow changing the size on demand, use something like:
(defun transient-text-scale-increase (inc)
(interactive "p")
(with-current-buffer transient--buffer
(text-scale-increase inc)))
(defun transient-text-scale-decrease (dec)
(interactive "p")
(with-current-buffer transient--buffer
(text-scale-decrease dec)))
(keymap-set transient-map "C-x +" #'transient-text-scale-increase)
(keymap-set transient-map "C-x -" #'transient-text-scale-decrease)
(keymap-set transient-predicate-map "<transient-text-scale-increase>"
#'transient--do-call)
(keymap-set transient-predicate-map "<transient-text-scale-decrease>"
#'transient--do-call)
You could also remember the size between menu invocations:
(defvar transient-text-scale-amount 0)
(transient-define-suffix transient-text-scale-increase (inc)
:transient t
(interactive "p")
(with-current-buffer transient--buffer
(text-scale-increase inc)
(setq transient-text-scale-amount text-scale-mode-amount)))
(transient-define-suffix transient-text-scale-decrease (inc)
:transient t
(interactive "p")
(with-current-buffer transient--buffer
(text-scale-decrease dec)
(setq transient-text-scale-amount text-scale-mode-amount)))
(keymap-set transient-map "C-x +" #'transient-text-scale-increase)
(keymap-set transient-map "C-x -" #'transient-text-scale-decrease)
(defun transient-restore-text-scale ()
(unless (local-variable-p 'text-scale-mode-amount)
(text-scale-set transient-text-scale-amount)))
I might make a refinement of one of these variants available by default,
but that will require some more though, which I don't have the time for
until next year.
Cheers,
Jonas
> - transient:
> - Archive: gnu
> - Version: 0.8.1
> - dependency issue before explicitly installing this version.
>
> - emacs 29.4
> - org 9.7.16
> - gptel ~/.emacs.d/elpa/gptel-0.9.6.0.20241115.83706
>
>
> some current org menus, although REALLY GOOD, have possibly
> regressed in recent years. in any case, for example, export is
> scrollable; todo kw is not, so i cannot access some todo kw.
>
> i put a lot of effort into this response, hope it makes sense.
>
>
> On Mon, Dec 16, 2024 at 10:52 AM Ihor Radchenko <yantar92@posteo.net> wrote:
>>
>> Samuel Wales <samologist@gmail.com> writes:
>>
>> > a couple of quick and somewhat obvious comments. i use VERY large
>> > fonts with a maximized gui emacs [vt / maximized urxvt when needed],
>> > still resulting in, throughout emacs, often, a smaller number of
>> > screen lines or columns than content, even with my usual one window
>> > per frame. most org menus respect this and can be scrolled or
>> > tweaked. just wanted compatibility to be in the specs. especially,
>> > to make sure no functionality is unreachable, but also where possible
>> > to modify column numbers / fill to look ok. i am slowly trying
>> > transient in gptel and still getting used to it.
>>
>> Thanks for the important input!
>> Does transient look fine on your screen? If yes, we should not have a
>> problem.
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode maintainer,
>> 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>
>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
^ permalink raw reply [flat|nested] 43+ messages in thread* Internal variables and symbols in transient (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-18 10:47 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Jonas Bernoulli
@ 2024-12-19 17:42 ` Ihor Radchenko
2024-12-19 18:11 ` Alternative defaults for visually impaired users? " Ihor Radchenko
1 sibling, 0 replies; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-19 17:42 UTC (permalink / raw)
To: Jonas Bernoulli
Cc: Samuel Wales, emacs-devel, Jonas Bernoulli, karthikchikmagalur,
Visuwesh
Jonas Bernoulli <jonas@bernoul.li> writes:
> (defun transient-text-scale-increase (inc)
> (interactive "p")
> (with-current-buffer transient--buffer
> (text-scale-increase inc)))
> ...
A quick note.
I am wondering if it is by design that transient sometimes recommend
using internal functions and variables. It feels extremely awkward.
Feel free to disregard if this has been discussed.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-18 10:47 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Jonas Bernoulli
2024-12-19 17:42 ` Internal variables and symbols in transient (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)) Ihor Radchenko
@ 2024-12-19 18:11 ` Ihor Radchenko
2024-12-22 4:49 ` Richard Stallman
1 sibling, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-19 18:11 UTC (permalink / raw)
To: Jonas Bernoulli
Cc: Samuel Wales, emacs-devel, emacs-orgmode, Jonas Bernoulli,
karthikchikmagalur, Visuwesh, T.V Raman
Jonas Bernoulli <jonas@bernoul.li> writes:
> I've worked with other users with impaired vision to improve their
> experience with Transient before and tend to prioritize that work.
This actually raises a bigger question:
Does it make sense to provide an alternative set of defaults for blind
or visually impaired users?
Unlike other cases when people ask for "modern" defaults, having
a ready-set configuration for people with accessibility needs may be
something too important to leave lying unattended.
I guess that Emacsspeak already provides some good defaults for blind,
thanks to T.V. Raman's continuous dedication.
But maybe we want things to be available in vanilla Emacs as well? Not
just for blind, but also settings with large font sizes.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-19 18:11 ` Alternative defaults for visually impaired users? " Ihor Radchenko
@ 2024-12-22 4:49 ` Richard Stallman
2024-12-22 9:29 ` Ihor Radchenko
0 siblings, 1 reply; 43+ messages in thread
From: Richard Stallman @ 2024-12-22 4:49 UTC (permalink / raw)
To: Ihor Radchenko
Cc: jonas, samologist, emacs-devel, karthikchikmagalur, visuweshm,
raman
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I guess that Emacsspeak already provides some good defaults for blind,
> thanks to T.V. Raman's continuous dedication.
> But maybe we want things to be available in vanilla Emacs as well?
It depends what "available" means. If it means having a package
that would install suitable different bindings and settings, it sounds
fine in principle -- but does Raman want to maintain them that way?
It might be a bigger change for him than for users of his work.
Not
> just for blind, but also settings with large font sizes.
I have a feeling that the changes for large fonts would be totally
dissimilar to those for screen reading. I'm not an expert, though,
bu does anyone actually _know_ whether they have much in common?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-22 4:49 ` Richard Stallman
@ 2024-12-22 9:29 ` Ihor Radchenko
2024-12-22 12:25 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-22 9:29 UTC (permalink / raw)
To: rms; +Cc: jonas, samologist, emacs-devel, karthikchikmagalur, visuweshm,
raman
Richard Stallman <rms@gnu.org> writes:
> > I guess that Emacsspeak already provides some good defaults for blind,
> > thanks to T.V. Raman's continuous dedication.
> > But maybe we want things to be available in vanilla Emacs as well?
>
> It depends what "available" means. If it means having a package
> that would install suitable different bindings and settings, it sounds
> fine in principle -- but does Raman want to maintain them that way?
> It might be a bigger change for him than for users of his work.
No, I did not mean a package. I meant support and maintenance in Emacs
core. IMHO, these features are too important for third-party package that
might be abandoned.
The initial input about alternative defaults may come from Raman,
Samuel, or other interested users who had to customize Emacs in similar
ways.
> Not
> > just for blind, but also settings with large font sizes.
>
> I have a feeling that the changes for large fonts would be totally
> dissimilar to those for screen reading. I'm not an expert, though,
> bu does anyone actually _know_ whether they have much in common?
I do not think that they have much in common in terms of specific
changes to Emacs defaults. What might be common is the way to enable
accessibility defaults - I have specific API design in mind, but do not
want to discuss it before I see how the general idea is received.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-22 9:29 ` Ihor Radchenko
@ 2024-12-22 12:25 ` Eli Zaretskii
2024-12-22 18:17 ` Ihor Radchenko
0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2024-12-22 12:25 UTC (permalink / raw)
To: Ihor Radchenko
Cc: rms, jonas, samologist, emacs-devel, karthikchikmagalur,
visuweshm, raman
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: jonas@bernoul.li, samologist@gmail.com, emacs-devel@gnu.org,
> karthikchikmagalur@gmail.com, visuweshm@gmail.com, raman@google.com
> Date: Sun, 22 Dec 2024 09:29:00 +0000
>
> Richard Stallman <rms@gnu.org> writes:
>
> > > I guess that Emacsspeak already provides some good defaults for blind,
> > > thanks to T.V. Raman's continuous dedication.
> > > But maybe we want things to be available in vanilla Emacs as well?
> >
> > It depends what "available" means. If it means having a package
> > that would install suitable different bindings and settings, it sounds
> > fine in principle -- but does Raman want to maintain them that way?
> > It might be a bigger change for him than for users of his work.
>
> No, I did not mean a package. I meant support and maintenance in Emacs
> core. IMHO, these features are too important for third-party package that
> might be abandoned.
>
> The initial input about alternative defaults may come from Raman,
> Samuel, or other interested users who had to customize Emacs in similar
> ways.
>
> > Not
> > > just for blind, but also settings with large font sizes.
> >
> > I have a feeling that the changes for large fonts would be totally
> > dissimilar to those for screen reading. I'm not an expert, though,
> > bu does anyone actually _know_ whether they have much in common?
>
> I do not think that they have much in common in terms of specific
> changes to Emacs defaults. What might be common is the way to enable
> accessibility defaults - I have specific API design in mind, but do not
> want to discuss it before I see how the general idea is received.
We do want to have accessibility features in Emacs, if that is what
you are asking. (In some cases we already do: e.g., see the
Windows-specific variable w32-use-visible-system-caret, which aims
specifically at aiding screen-reading software.)
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-22 12:25 ` Eli Zaretskii
@ 2024-12-22 18:17 ` Ihor Radchenko
2024-12-22 18:54 ` Eli Zaretskii
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-22 18:17 UTC (permalink / raw)
To: Eli Zaretskii
Cc: rms, jonas, samologist, emacs-devel, karthikchikmagalur,
visuweshm, raman
Eli Zaretskii <eliz@gnu.org> writes:
>> ... I meant support and maintenance in Emacs
>> core. IMHO, these features are too important for third-party package that
>> might be abandoned.
>> ...
>
> We do want to have accessibility features in Emacs, if that is what
> you are asking. (In some cases we already do: e.g., see the
> Windows-specific variable w32-use-visible-system-caret, which aims
> specifically at aiding screen-reading software.)
Thanks for the clarification. Then, let me expand on the idea I have.
I imagine adding "alternative" default value to `defcustom':
(defcustom variable default-value
:alt-default
(("blind" . value2)
("large-fonts" . value3))
...)
Then, consider custom options like
(defcustom accessibility-blind nil
"When non-nil, Emacs will use defaults suitable for blind users.")
(defcustom accessibility-large-fonts nil
"When non-nil, Emacs will use defaults suitable for large font sizes.")
If any of the above options is non-nil, and custom variable has its
default value (not changed by user explicitly), instead of
"default-value" a suitable alternative value is used.
Third-party packages will also be able to make use of this semantics,
providing better defaults if necessary.
Elisp manual should also encourage package authors to keep these
alternatives in mind.
WDYT?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread* Re: Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))
2024-12-22 18:17 ` Ihor Radchenko
@ 2024-12-22 18:54 ` Eli Zaretskii
[not found] ` <87bjx2ls6k.fsf@localhost>
[not found] ` <CAJcAo8vFHgC=B44_Zpawj=ZOKAW2viFT62cxddq6Q=d7PQF50A@mail.gmail.com>
0 siblings, 2 replies; 43+ messages in thread
From: Eli Zaretskii @ 2024-12-22 18:54 UTC (permalink / raw)
To: Ihor Radchenko
Cc: rms, jonas, samologist, emacs-devel, karthikchikmagalur,
visuweshm, raman
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: rms@gnu.org, jonas@bernoul.li, samologist@gmail.com,
> emacs-devel@gnu.org, karthikchikmagalur@gmail.com, visuweshm@gmail.com,
> raman@google.com
> Date: Sun, 22 Dec 2024 18:17:40 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> ... I meant support and maintenance in Emacs
> >> core. IMHO, these features are too important for third-party package that
> >> might be abandoned.
> >> ...
> >
> > We do want to have accessibility features in Emacs, if that is what
> > you are asking. (In some cases we already do: e.g., see the
> > Windows-specific variable w32-use-visible-system-caret, which aims
> > specifically at aiding screen-reading software.)
>
> Thanks for the clarification. Then, let me expand on the idea I have.
>
> I imagine adding "alternative" default value to `defcustom':
>
> (defcustom variable default-value
> :alt-default
> (("blind" . value2)
> ("large-fonts" . value3))
> ...)
>
> Then, consider custom options like
>
> (defcustom accessibility-blind nil
> "When non-nil, Emacs will use defaults suitable for blind users.")
> (defcustom accessibility-large-fonts nil
> "When non-nil, Emacs will use defaults suitable for large font sizes.")
>
> If any of the above options is non-nil, and custom variable has its
> default value (not changed by user explicitly), instead of
> "default-value" a suitable alternative value is used.
>
> Third-party packages will also be able to make use of this semantics,
> providing better defaults if necessary.
>
> Elisp manual should also encourage package authors to keep these
> alternatives in mind.
>
> WDYT?
If this means that, for example, each face and defcustom we define
will need to have such alternatives defined in advance, I think it's a
non-starter. People will forget to define those, and having such a
definition for each face/defcustom is extremely inconvenient and hard
to maintain.
(We had a similar problem long ago, when TTY frames learned to display
colors, back when they only supported 8 colors. Originally, the idea
was that each face will have a separate definition for TTYs, but this
idea crashed and burned very fast, and instead we added transparent
conversion of X colors to TTY colors, see tty-colors.el.)
If you mean something else, please explain how (via which mechanisms)
will accessibility-* options affect Emacs, once turned on.
What I think we need is some infrastructure which will automatically
react to a setting from the accessibility set. For "large fonts",
this is almost trivial, but other settings might be harder.
Perhaps a useful first step would be for someone to see what other
systems and applications offer in this department, and post the
findings. Then we could discuss how to incorporate the relevant parts
into Emacs.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-13 18:41 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Ihor Radchenko
` (2 preceding siblings ...)
2024-12-14 1:16 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Panayotis Manganaris
@ 2024-12-14 10:50 ` indieterminacy
2024-12-14 17:53 ` Juri Linkov
2024-12-15 18:23 ` Kierin Bell
5 siblings, 0 replies; 43+ messages in thread
From: indieterminacy @ 2024-12-14 10:50 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode,
Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov,
karthikchikmagalur, Visuwesh, charles.choi, Justin Burkett,
rswgnu
Hello Ihor,
On 2024-12-13 19:41, Ihor Radchenko wrote:
> TL;DR: We are in the process of designing a more unified selection
> interface for Org mode and want to see if there is some way to unify
> context-menu-mode, transient, which-key and embark together. The idea
> is
> to (1) avoid too many customizations; (2) allow users to decide how to
> choose between multiple options - by mouse, keyboard, and using
> customizable UIs.
> ...
I would consider an `actions -> menu` functionality to be something
which should be a distinct tool,
albeit heavily configured to suit Orgmode functionality.
I think its great how Transient was able to emerge from Magit's
activities and its clearly providing opportunities for scaling the
utility.
If I may widen the topic a little, your RFC could be an opportunity to
examine the overlaps between Orgmode and Hyperbole.
For instance, the use of implicit buttons could be examined:
https://www.gnu.org/software/hyperbole/man/hyperbole.html#Implicit-Buttons
I reckon what you are proposing (greater fluency and flow for menus
dependent on context) could benefit Hyperbole's functionality too (the
action utility for that environment seems more focused on one action
rather than prompting a selection of actions).
Ive CC'd Robert Weiner (who leads Hyperbole), incase that is of use.
Kind regards,
Jonathan McHugh
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-13 18:41 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Ihor Radchenko
` (3 preceding siblings ...)
2024-12-14 10:50 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? indieterminacy
@ 2024-12-14 17:53 ` Juri Linkov
2024-12-15 9:07 ` Ihor Radchenko
2024-12-15 18:23 ` Kierin Bell
5 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2024-12-14 17:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-devel, emacs-orgmode
> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
> PROPS is a plist defining extra properties like key-binding, display
> string, maybe something else to be used in the future.
> 2. Menu interface to use (transient, context-menu, embark, which-key)
This looks like the best design. Any part of the org buffer could have
text properties with a list of its available actions. Such a property
could be similar to 'context-menu-functions' handled by 'context-menu-map'.
But since it will be a plain generic list, it could be transformed to any
menu interface such as transient, context-menu, etc.
To transform it to context-menu, org-mode should provide a function
like 'context-menu-minor' that will create a corresponding menu
that will be added as a submenu of the default context menu.
Such integration with existing menus would be better than the current
implementation of context menus in org-mouse-context-menu that completely
replaces the context menu with its own.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-14 17:53 ` Juri Linkov
@ 2024-12-15 9:07 ` Ihor Radchenko
2024-12-16 7:46 ` Juri Linkov
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-15 9:07 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel, emacs-orgmode
Juri Linkov <juri@linkov.net> writes:
>> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
>> PROPS is a plist defining extra properties like key-binding, display
>> string, maybe something else to be used in the future.
>> 2. Menu interface to use (transient, context-menu, embark, which-key)
>
> This looks like the best design. Any part of the org buffer could have
> text properties with a list of its available actions. Such a property
> could be similar to 'context-menu-functions' handled by 'context-menu-map'.
> But since it will be a plain generic list, it could be transformed to any
> menu interface such as transient, context-menu, etc.
I am a bit lost.
Maybe I did not describe the use cases I had in mind well.
What I have in mind is a menu UI for various commands:
1. org-open-at-point (one set of actions)
2. org-ctrl-c-ctrl-c (another set of action)
3. some other command
4. ...
Then, "actions" will be various options a given command can do.
In such scenario, the usefulness of text properties is elusive to me.
I'd rather link the menu items to a command, not to place in buffer.
> To transform it to context-menu, org-mode should provide a function
> like 'context-menu-minor' that will create a corresponding menu
> that will be added as a submenu of the default context menu.
>
> Such integration with existing menus would be better than the current
> implementation of context menus in org-mouse-context-menu that completely
> replaces the context menu with its own.
What do you mean by "default context menu"?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-15 9:07 ` Ihor Radchenko
@ 2024-12-16 7:46 ` Juri Linkov
2024-12-16 18:06 ` Ihor Radchenko
0 siblings, 1 reply; 43+ messages in thread
From: Juri Linkov @ 2024-12-16 7:46 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-devel, emacs-orgmode
>>> 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...)
>>> PROPS is a plist defining extra properties like key-binding, display
>>> string, maybe something else to be used in the future.
>>> 2. Menu interface to use (transient, context-menu, embark, which-key)
>>
>> This looks like the best design. Any part of the org buffer could have
>> text properties with a list of its available actions. Such a property
>> could be similar to 'context-menu-functions' handled by 'context-menu-map'.
>> But since it will be a plain generic list, it could be transformed to any
>> menu interface such as transient, context-menu, etc.
>
> I am a bit lost.
> Maybe I did not describe the use cases I had in mind well.
>
> What I have in mind is a menu UI for various commands:
> 1. org-open-at-point (one set of actions)
> 2. org-ctrl-c-ctrl-c (another set of action)
> 3. some other command
> 4. ...
>
> Then, "actions" will be various options a given command can do.
>
> In such scenario, the usefulness of text properties is elusive to me.
> I'd rather link the menu items to a command, not to place in buffer.
Indeed, in this case text properties are not needed.
Then you can use something like the buffer-local variable with the
same name 'context-menu-functions' (handled in 'context-menu-map').
The main point is that these functions return a menu.
But instead of a menu, an org function could return
a more high-level data structure like
((name1 . action1 props) (name2 . action2 ...) ...)
IOW, this means adding an abstraction layer on top of the existing
user interfaces such as transient and context-menu.
>> To transform it to context-menu, org-mode should provide a function
>> like 'context-menu-minor' that will create a corresponding menu
>> that will be added as a submenu of the default context menu.
>>
>> Such integration with existing menus would be better than the current
>> implementation of context menus in org-mouse-context-menu that completely
>> replaces the context menu with its own.
>
> What do you mean by "default context menu"?
The default context menu is the menu constructed from many different
context-menu functions. Some of them add Undo/Redo entries,
some add Select/Copy/Paste, some add Global submenus, etc.
I meant to keep all these existing menu items, and also append
the submenu items returned by Org-mode.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-16 7:46 ` Juri Linkov
@ 2024-12-16 18:06 ` Ihor Radchenko
2024-12-22 12:16 ` Tor-björn Claesson
0 siblings, 1 reply; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-16 18:06 UTC (permalink / raw)
To: Juri Linkov; +Cc: emacs-devel, emacs-orgmode
Juri Linkov <juri@linkov.net> writes:
> Then you can use something like the buffer-local variable with the
> same name 'context-menu-functions' (handled in 'context-menu-map').
> The main point is that these functions return a menu.
>
> But instead of a menu, an org function could return
> a more high-level data structure like
> ((name1 . action1 props) (name2 . action2 ...) ...)
>
> IOW, this means adding an abstraction layer on top of the existing
> user interfaces such as transient and context-menu.
Yeah. I am not 100% sure if adding an abstraction layer is a great idea.
Another idea I was considering is similar to what you propose: have some
kind of hook like `context-menu-functions', but accepting an extra
argument - menu type (context menu, transient, which-key, etc.). Then, it
should produce appropriate menu spec.
However, this will require Elisp to customize things. Also not ideal.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-16 18:06 ` Ihor Radchenko
@ 2024-12-22 12:16 ` Tor-björn Claesson
[not found] ` <87h66ult46.fsf@localhost>
0 siblings, 1 reply; 43+ messages in thread
From: Tor-björn Claesson @ 2024-12-22 12:16 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Juri Linkov, emacs-devel, emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]
Hi!
Thanks all for the great discussion!
Just so I understand: we are talking about simple cases of offering
multiple actions (possibly on objects),
and not more complex things such as the export menu, with async options etc?
> Tentatively, I am thinking about the following:
>
> For a given Emacs "prefix" command (e.g. org-open-at-point), we define a
> set of customizations:
>
> 1. List of possible actions: ((name1 . action1 props) (name2 . action2
...) ...)
> PROPS is a plist defining extra properties like key-binding, display
> string, maybe something else to be used in the future.
> 2. Menu interface to use (transient, context-menu, embark, which-key)
> 3. Layout settings for the specific interfaces. For example, transient
> layout definition.
Do we need 3? Could we decide on a way to specify layout properties in
props?
We could have e.g. a group name which would translate to a transient column.
The citation follower prototype works similarly to right click menus of
mainstream desktop environments - i.e. it allows the user to optionally
select an alternative action while providing a default.
You "right click" by -4 prefix, and can also invert this behavior to show
the menu by default, and invoking the default action if called with a -4
prefix.
Den mån 16 dec. 2024 kl 20:06 skrev Ihor Radchenko <yantar92@posteo.net>:
>
> Yeah. I am not 100% sure if adding an abstraction layer is a great idea.
> Another idea I was considering is similar to what you propose: have some
> kind of hook like `context-menu-functions', but accepting an extra
> argument - menu type (context menu, transient, which-key, etc.). Then, it
> should produce appropriate menu spec.
>
> However, this will require Elisp to customize things. Also not ideal.
>
My naive take:
Should we make a macro for creating this kind of simple menu? It would take
a name, a docstring, parameters passed to the action, a default action
name, and a default list of actions.
It would then create
1. a function that invokes the menu, passing the parameters.
2. a customization group with options for:
2.1. the actions list.
2.2. the default action.
2.3. whether to show menu by default (or by -4 prefix)
2.4. the menu system to invoke (default transient)?
3. a transient menu.
Does this sound reasonable? I probably miss something. I would be happy to
try to make this, but am a bit swamped with the holidays, so it would have
to wait a bit.
Cheers,
Tor-björn
[-- Attachment #2: Type: text/html, Size: 3314 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-13 18:41 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) Ihor Radchenko
` (4 preceding siblings ...)
2024-12-14 17:53 ` Juri Linkov
@ 2024-12-15 18:23 ` Kierin Bell
2024-12-17 17:23 ` Ihor Radchenko
5 siblings, 1 reply; 43+ messages in thread
From: Kierin Bell @ 2024-12-15 18:23 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode,
Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi,
Justin Burkett
Hi Ihor,
Ihor Radchenko <yantar92@posteo.net> writes:
> TL;DR: We are in the process of designing a more unified selection
> interface for Org mode and want to see if there is some way to unify
> context-menu-mode, transient, which-key and embark together. The idea
> is to (1) avoid too many customizations; (2) allow users to decide how
> to choose between multiple options - by mouse, keyboard, and using
> customizable UIs.
I think that the built-in Emacs thingatpt.el should not be overlooked
here.
Instead of implementing an entire system specific to Org, imagine a
generic action-at-point interface that works on "things" from
thingatpt.el. For the various targets, Org could add new "providers" to
`thing-at-point-provider-alist', `forward-thing-provider-alist', and
`bounds-of-thing-at-point-provider-alist'. [ Org actually does already
register its own 'url' provider for links. ]
Then, Org could implement a number of action selection interfaces that
act on the various classes of "thing". An exemplary package would be
Philip Kaludercic's great =do-at-point= package, which provides a simple
action selection menu for the thing-at-point using
`read-multiple-choice', which I find elegant and intuitive.[1]
I have gone as far as implementing a 'heading' provider for Org and
`outline-mode' (for use with =do-at-point.el=). I don't see any reason
why Org couldn't define a 'citation' provider, a 'source-block'
provider, etc.
The only downside that I have found with adding lots of thingatpt.el
providers is that it can be difficult to write providers efficient
enough for `forward-thing' in particular
(`forward-thing-provider-alist').
I may also be misunderstanding the proposed interface. For example,
instead of a generic interface for acting on a single thing at point,
maybe you are describing more of an interface for associating commands
with multiple potential targets that must be located (e.g., in a
subtree), which are then each associated with actions.
Even if that's the case, there is a good case for implementing
thingatpt.el providers for the targets, so that users could bring our
own action-at-point packages/interfaces. [ I would be willing to help
write some of those providers. ] And if thingatpt.el isn't generalized
or fast enough, then there is a case for creating a new, more flexible
/de facto/ library like this for Emacs.
[1] https://codeberg.org/pkal/do-at-point
Thanks,
Kierin
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark?
2024-12-15 18:23 ` Kierin Bell
@ 2024-12-17 17:23 ` Ihor Radchenko
0 siblings, 0 replies; 43+ messages in thread
From: Ihor Radchenko @ 2024-12-17 17:23 UTC (permalink / raw)
To: Kierin Bell
Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode,
Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli,
Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi,
Justin Burkett
Kierin Bell <fernseed@fernseed.me> writes:
> I think that the built-in Emacs thingatpt.el should not be overlooked
> here.
>
> Instead of implementing an entire system specific to Org, imagine a
> generic action-at-point interface that works on "things" from
> thingatpt.el. For the various targets, Org could add new "providers" to
> `thing-at-point-provider-alist', `forward-thing-provider-alist', and
> `bounds-of-thing-at-point-provider-alist'. [ Org actually does already
> register its own 'url' provider for links. ]
This is actually not what I had in mind in this thread. I was only
hoping to get input about customizing menu interface in a way that menu
UI can be chosen by user.
As for `thing-at-point', it is not enough for Org's needs.
Let me show you an example of one of the Org "action" commands.
org-ctrl-c-ctrl-c does the following:
1. If performs specific actions depending on Org syntax element at point
2. It performs alternative action in Org edit buffers where
org-finish-function is defined.
3. It performs different things depending on context around thing at
point. For example, first paragraph inside a list will trigger a
different action compared to just a paragraph.
While (1) can be easily ported to thing-at-point, (2) is much harder,
and (3) will involve creating artificial "things" just for the purposes
of specific Org command.
> Then, Org could implement a number of action selection interfaces that
> act on the various classes of "thing". An exemplary package would be
> Philip Kaludercic's great =do-at-point= package, which provides a simple
> action selection menu for the thing-at-point using
> `read-multiple-choice', which I find elegant and intuitive.[1]
I'd like Org _not to implement interfaces_. Instead, I want to reuse the
existing interfaces - transient, menus, which-key, etc. My main question
is whether we can do such thing cleanly.
> I may also be misunderstanding the proposed interface. For example,
> instead of a generic interface for acting on a single thing at point,
> maybe you are describing more of an interface for associating commands
> with multiple potential targets that must be located (e.g., in a
> subtree), which are then each associated with actions.
Yup, something more like this.
> Even if that's the case, there is a good case for implementing
> thingatpt.el providers for the targets, so that users could bring our
> own action-at-point packages/interfaces. [ I would be willing to help
> write some of those providers. ] And if thingatpt.el isn't generalized
> or fast enough, then there is a case for creating a new, more flexible
> /de facto/ library like this for Emacs.
Better interoperability with thingatpt.el will be certainly welcome.
I even coined this idea in the context of tree-sitter in the past.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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] 43+ messages in thread
