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.
Sure. > 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. Thanks! > 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? Shérab. _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.com/mailman/listinfo/brltty
