Dear Dave, and the list! Dave Mielke <[email protected]> writes: > [quoted lines by Aura Kelloniemi on 2018/03/14 at 10:54 +0200] > >Another big limitation is that I can't move between two different types of > >prompts.
> But, in fairness, a regular expression wouldn't support an arbitrary prompt, > i.e. one that wasn't foreseen. Yes, of course, that is is a limitation as well. It is something which with I can live more easily thatn with the current behaviour, but it does not say anything about anybody else's preferences. > Call the current scheme a hack, if you must, but I personally think that's > being a bit arrogantly judgemental. I'm very sorry if I made an offense. I said, "a bit of a hack", and I consider my own proposal to be such too. There is no perfect solution, because TTY is not a system which can carry metadata about semantics of applications. > I myself prefer to steadily move toward something that's the most useful > rather than to simply assume that I know what's best for others. And, again > to me, it's perfectly okay to view the current method as a step along that > way rather than as a useless hack. I don't know what is good for others, nor do I pretend to. And the current behaviour is certainly not useless. If it is a hack, it is a useful hack. > >I would prefer to have PRPROMPT/NXPROMPT commands which are totally > >context-insensitive - i.e. regex-match based. > You do, but the feature doesn't exist just for you. There are others who > prefer > the context-sensitive way. Are they wrong? Not at all. I can speak just for myself. That's exactly why I made two proposals. I particularly like applications which can be scripted. If this ability was available in BRLTTY, I would have scripted my own movement commands long time ago. There is no clearly "right way" to do this particular command in a predefined way, and that's why I would have implemented it for myself only. > >Second proposal - add new matching commands: Don't modify NXPROMPT or PROMPT > >commands. Instead add NXMATCH and PRMATCH commands which match a regex > >pattern > >in a way described in the previous section. This command would use a pattern > >defined in brltty.conf with default-pattern option. > I don't like this approach so much for at least these reasons. There might > be > some braille devices for which a new pair of bindings is difficut to find. > Maintaining a private key table is, again, something that most users > shouldn't > need to do. While I'm against implementing a facility that's too complex for > most people, I'm also against "hiding" new features - specifying a pattern > (as > in your first proposal) is enough to make it optional and usable. The only kind of benefit from this approach would be that then the context-sensitive and the context-insensitive behaviour would be both available at the same time, if somebody wants them. And maybe somebody finds some other use for NXMATCH and PRMATCH than finding prompts - something that I haven't considered at all. I'm not trying to argue, I'm trying to explain my personal and limited views. > >There could be additional commands for modifying this pattern - e.g. > >SETPATTERN (which sets the pattern from the current contents of clipboard), > >RESETPATTERN (which resets it back to the default value) and CLIP_PATTERN > >(which would copy the pattern to clipboarrd for pasting and editing it). > this, to me, is an entirely separate feature. It should be implemented on > top > of, rather than embedded within, however the first one is implemented. Agreed. -- Aura _______________________________________________ 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
