Re: Proposal: 'executable' org-capture-templaes

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> However before I continue, I am thinking of ditching the 'read-key' 
>>> completely
>>> and switching to "standard" Emacs way of implementing interactivity via 
>>> mode and
>>> mode-map. I am currently playing with such implementation, which to me 
>>> appears
>>> both simpler (code reduction) and more flexible, but it does change the 
>>> mental
>>> model of how clients of org-mks are used, for example org-capture.
>>>
>>> I don't think it should be a deal-breaker, but that is my personal opinion, 
>>> so I
>>> would like to hear if that change would be acceptable or not?
>>
>> Could you provide a bit more details? How exactly will the usage differ
>> from read-key?
>
> I just wrote a much more detailed descrpition of what I have done so far, and
> some dificulties I have to solve before I continue, and some discussion of how
> it might work in answer to Mikulins question and concerns.
>
> Short here: it will be ordinary text buffer, read only of course, with its own
> major mode derived from special mode and buffer local key maps, instead of 
> major
> mode global maps, so user can just press a key in the buffer itself instead of
> being prompted.
>
> Single task workflow, I believe, can be guaranteed by allowing
> only one menu buffer per application, for example one org-capture menu at a
> time, but multiple applications could work since they will have different 
> named
> buffers.
>
> This is a suggestions. I really dislike the read-key implementation of 
> org-mks,
> I don't think it is very easy to hack it in order to extend it, but I don't 
> know
> if it is possible to block Emacs when using ordinary key map mechanism. If
> someone knows how to do it, I am all ears :).
>
> Hope it explains a bit.
>
> Thanks for the help!


I'm not sure I really understand the exact goal you have here. To me, it
feels like yet another input selection/menu/completion scheme and I'm
not clear on how it will be an improvement or why do something
'different' in org compared to other modes etc. However, I also don't
have any problems using the existing capture interface, so perhaps I
just don't have the number or complexity of capture choices to expose
issues/limitations wiht the existing approach. 

The main 'concern' (well, not really a concern, but ....) I have is that
Emacs already has far too many solutions along this line, which makes it
harder to get a consistent UI. I also feel this is one of those areas
which appears to be really easy to 'fix' or improve, but also has a lot
of hidden complexity which only becomes evident once lots of different
users and workflows try to use it. 

One very big warning I would like to raise to ensure it is taken into
consideration is accessibility. This can have two significant effects
with respect to the types of things you are doing -

1. I am a vision impaired user. While considered legally to be blind, I
do have some very limited vision (less than 5%). I use very large fonts.
(assume a 25 x 80 screen). 

2. I use Emacspeak to provide text-to-speech support. Emacspeak works
primarily by adding 'advice' to key functions which take the core bit of
text and send it to a text-to-speech synthesizer to generate spoken
output. One thing which is important with any 'menu' or selection
solution is that we can move through the choices so that they get spoken
again i.e. review the choices. 

Choice review is very important, especially when there are lots of
choices or when there are nested choices. Some solutions are better at
this than others. Sometimes, this is only possible by selecting the
'prompt' window and using normal emacs navigation keys to move around
and get the options spoken - clunky, but usable. Others solutions are
structured such that when you move to a new option, it is spoken and you
can just move up/down or in/out of selections to hear them spoken. The
key point here is that in some situations, you may need to allow the
user to switch windows and then switch back (i.e. switch to the window
displaying the choices, move around to listen to them, switch back to
the minibuffer and enter the choice or provide key bindings which will
allow the 'choices' buffer to be scrolled up/down and have the contents
spoken without leaving the minibuffer etc. The key point is that for
blind and VI users, the ability to 'scan' the choices is more limited.
Often you will need to go down one selection tree, come back up and go
down a different branch. You cannot just glance at the screen and get an
overview which helps to give context. As an example, the org export
'menu' is not good for most blind/VI users. The choices quickly exceed
the number you can fit on a 25.80 screen and it is difficult to review
choices. 

One reason I like it when modes stick to core or built-in modes/packages
to provide UI elements is that typically, they will already have
emacspeak support. When a mode does something fundamentally different,
it requires someone to implement the advice to make it work with
Emacspeak. Most 'popular' approaches have already got support i.e. helm,
ivy, company, transient mode, vertico, embark, ido, etc. Some modes are
easier to support than others. 

It can be difficult for someone unfamiliar with accessibility
requirements to know how to ensure these are met and met adequately.
Unfortunately, there is no simple answer. However, when ti comes to
emacs, one approach which might help is to see if you can make your
implementation echo choices to the message buffer and/or echo area when
the user moves between options or requests a review of available
options. While not perfect, in general, if you can do this then it won't
be too difficult to add Emacspeak support.