[BRLTTY] Feature request: configurable prompt pattern

[Aura Kelloniemi]

Dear Dave, and the list!

Dave Mielke <dave at mielke.cc> 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