Dear Aura,

> Thanks. There have been some API changes in Python's regex module which I have
> to update my program for. I also need to do some checking, and make the key
> bindings somehow customizable - probably by editing a bunch of constants in a
> Python script, but that's better than no customizability.


> There are dreadful confessions about crimes that I did in my past lives
> written into the doc strings of methods... No, not really. I will release it
> when I have time to do some cleanup on the code.


> I consider my program to be useful for reading files, but it has some inherent
> limitations, e.g. the file being read has to fit in RAM at once. I don't think
> that it would either be a good idea to start duplicating features of other
> applications (like web browsers, directory managers, text editors, etc.) in
> it, because it would be a huge effort. Also my program does not support
> keyborad input from the TTY, so it is not very useful with braille devices
> which don't have a braille keyboard.

Yeah it was the same with bless and I didn't even go as far as you did.

> As a result I'm not interested to develop this code very much. I would instead
> want to write a BrlAPI interface for emacs, because emacs already supports a 
> lot
> of functionality. Emacs is pretty usable with braille display already, but it
> could see a little bit of enhancement (e.g. using routing keys as a
> replacement for the mouse).

Sure. Itmakes much more sense htan re-inventing the wheel.

It would also be great if we could somehow achieve continuous reading,
not having to do the Page Donw / CMd_TOP_LEFT sequence while reading,
since that was the initial topic of this conversation.

> But definitely I don't have anything against somebody else developing my code
> further. Be warned though, that it has not been designed with extensibility in
> mind.

Your wise remark about developing an emacs interface to BrlAPI
gave me a pause. I fully agree it's way better to develop such things
than to spend time writing too specific code nobody will maintain.

>  > It would also be nice if you could bemore precise about the kind of
>  > improvemnets you would like to see in BrlAPI regarding the handling of
>  > keys and commands.
> You can read about this from a thread titled "[BRLTTY] BrlAPI Raw key code
> mode?" started by Mario Lang on this mailing list on 23 Jul 2017
> 00:12:56.

Yeah I remember this thread. One thing has happened since then: BrlAPI
can now return the model identifier. So it is possible for a client to
get this model identifier and then ask for raw key codes that it can
then interpret as it wishes. I realise I should have announced this on
the list and apologize for not having done so.

From what I remember from the thread you mention, there was a consensus
around this feature of being able to get the model identifier. The other
thing I remember from it is that the next steps were not as obvious. I
don't think there was a consensus on what should happend beyond this
model identifier feature. Or was there one?

This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to:
For general information, go to:

Reply via email to