Arthur Miller <arthur.mil...@live.com> writes:
> Ihor Radchenko <yanta...@gmail.com> writes: > >> Arthur Miller <arthur.mil...@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.
