[BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

[quoted lines by Aura Kelloniemi on 2018/03/14 at 10:54 +0200]

>I consider the current behaviour to be a little bit of a hack itself. I
>consider it to be a big limitation that in order to be able to move from one
>prompt to another I have to first position the braille window on a line which
>already has a prompt. 

Perhaps, but before we had Track Screen Scroll (new in 5.6) the previous prompt 
line was a moving target unless the screen was stable. Now that we have Track 
Screen Scroll, of course, the situation has changed.

>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. Call the current scheme a hack, if you must, but 
I personally think that's being a bit arrogantly judgemental. 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 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?

>First proposal - add prompt-pattern configuration option: This option is a
>string, which is a regular expression pattern. NXPROMPT and PRPROMPT commands
>move the window down and up respectively until the contents of the line on
>which the window is matches this regular expression. THe expression can be
>arbitrarily complex, and because regex supports alternatives, it can easily
>recognize many different types of prompts. 

Yes, if optional, that'd be reasonable.

>If prompt-pattern was not defined or was set to a specific value (e.g. empty
>string), then BRLTTY's current context-sensitive behaviour would be invoked
>instead of pattern matching.

Yes, that'd be essential. I'd go for the "is empty" paradigm as that's the way 
unspecified options work and also because I ahate special, magic values.

>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.

>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.

-- 
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke           | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Dave at Mielke.cc | Ottawa, Ontario   | Twitter: @Dave_Mielke
Phone: 1-613-726-0014 | Canada  K2A 1H7   |