Hey all! I have been on editor walkabout learning what tools exist in the industry, how stuff is generally sewn together and I have even contributed patches to Emcaspeak! I am talking to some Neovimmers about getting an accessibility mode up and running there and … you guys know me, I am starting a blind tech community discourse and discord server … but I digress.
Anyway, Emacs has some great features and honestly, Emacspeak is the best tool I have found for coding with vision impairments, but … it isn’t Kakoune! Armed with enough information to be dangerous and mildly clueful now I am likely to embark (and look for assistance) at getting Kakoune all the way tooled up for the visual impaired.
Here are my random thoughts so far … as much for myself as you folks…
The Emacspeak model is very simple, text over stdin is how emacspeak talks to its “servers” which can be written in any language. It has a very simple wire protocol that has many years of use and multiple servers which are written to link to the TTS engines. TTS Servers (Emacspeak User’s Manual — 2nd Edition.)
At a basic level, it only does a few things…
- Speak text (letters or sentences, different speeds and intonations, etc)
- “Altered” text (special effects like echo not directly supported by the TTS engine which requires using a library like Sox). I am have convinced this isn’t worth the complexity at this point.
- Playing “audio icons” which are simply sound files, aiff, ogg, mp3, wav, etc
- Playing “tones” – exactly what it sounds like, a tone.
That is basically it. One nice thing about this simple interface is with a port forward and a bit of redirection it works over SSH!
So, I don’t think we need to recreate the wheel here, I would love to see both Neovim and Kakoune using the same servers as Emacspeak so they can grow more robust. Which goes into what is needed… hooks hooks and hooks!
I have high hopes with hooks, and some elbow grease the basic Kakoune package can be made usable in relatively short order, might find some hooks we need to add, some other cracks and crevices that need to be filled in to help identify location and context.
My biggest concern for this in regards to plugins, one of the magic bits of Emacspeak is lisp and the fact that Emacspeak can modify other plugins without any direct touching of them, just with the defadvice system and other stuff. That is incredibly powerful and lets Emacspeak work with a large number of plugins by just hooking into when the functions they use are run.
On the basic untouched Kakoune front, with no plugins. It will just be about if we have the hooks to emit the audio information that is required. The goal of what is emitted should be useful and timely, unlike visual editing, we can not just toss a bunch of stuff on screen.
Due to multiple cursors, going to have some unique challenges, but I think all of them are overcomable, just need to start digging into kakoune to see how we launch and keep to STDIN open to a subprocess for an entire editor session.
Core implementation will of course be:
- Read line on line switch
- Read selected content
- Read selected content with multiple cursors, with an ident for which copy you are on
- Read chars as they are typed or deleted (with speed multiplier)
- Read by movements without selecting (this might be impossible now?)
- Read by word as completed
- Read autocomplete options (in editing or like file picker)
- Read help options (needs to be skippable to next one, prev one)
- Read file name
- Read position in file
- … a lot of other corners and things that will have to be looked at.