[BRLTTY] Feature request: configurable prompt pattern

[Aura Kelloniemi]

Dave Mielke <dave at mielke.cc> writes:
 > [quoted lines by Aura Kelloniemi on 2018/03/15 at 08:26 +0200]
 > >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. 

 > I don't personally take offense to much, including this issue. To me, though, 
 > the term "hack" means carelessly thrown together without much, if any, 
 > forethought.

OK. Then I understand your reaction. To me hack means a solution which uses a
feature in a non-intended way - e.g. matches a prompt based on how that prompt
is represented in text - instead of just knowing what is a prompt and what is
not.

 > I disagree that the current paradigm is anywhere close to that.

Me too.

 > >I particularly like applications which can be scripted. 

 > That's yet another, entirely separate, potentially useful feature. We can 
 > discuss that, too. I'm not sure how much bloat and inefficiency it might add to 
 > brltty, but, as with anything else, we won't know until we discuss it. Do you 
 > have any particular scripting language and/or approach in mind?

Many - all with their own pros, cons and uncertainties. Maybe I'll start a new
thread one day, if I have time. This is a huge topic.

 > We could allow several patterns to be specified. For example:

 >    prompt-pattern pattern1
 >    prompt-pattern pattern2
 >    prompt-pattern pattern3

I like this part a lot. It makes separation of patterns very clear.

 > We could then check the current line to see if it matches any of them. If it 
 > does then we do the context-dependent thing with just that pattern,

Very good too for those who want it context-sensitive way.

 > and, if it doesn't, then we join them, e.g.:
 >    (pattern1|pattern2|pattern3)
 > and do the context-independent thing.

Wouldn't mixing these two types of behaviours be confusing to users. To me it
would. If a line on which I am matches a pattern I did not mean it to match,
then I end up in a weird place instead of having it do the context-free
matching.

Context-sensitive by default prevents me from moving between different types
of prompts, unless I use the regex alternation syntax to join all my patterns
together thus preventing brltty from noticing that I have kinda multiple
patterns.

 > We could even also have command modifiers that could be added within the
 > key table (like how +on and +off work for toggle commands) to force it one
 > way or the other.

This sounds very good. My personal preference is always context-free. Nicolas
explained this in a good way in his latest post (before me posting this one).

My opinion is that if prompt matching is sometimes context-free and sometimes
context-sensitive (based on some patterns), it can feel unpredictable from the
user's point of view.

I compile all the proposals here. They are not necessarily exclusive:

1. Make NXPROMPT/PRPROMPT context-free and configure them with regex patterns
in brltty.conf.
2. Make NXPROMPT/PRPROMPTconfigurable using sed-style regex
patterns/substitutions (in brltty.conf), providing currently displayed line as the initial
string on which the substitution is run. All back-references are escaped
before substitution and the resulting string is used to check whether a
particular line is a prompt or not.
3. Modify NXPROMPT/PRPROMPT to be context-sensitive by default and
context-free, if that fails. Configuration is with a list of regex patterns in
brltty.conf.
4. Allow modifiers to choose whether NXPROMPT/PRPROMPT should behave in
context-free or context-sensitive way. This is applicable to proposal 3, but
proposal 1 could be extended with this one somehow.
5A. Create new NXMATCH/PRMATCH commands which behave the same way as
NXPROMPT/PRPROMPT would behave in proposal 1.
5B. The same as 5A but the substitutions would be done instead of simple
pattern matching, as in proposal 2.
6. Create new commands for transfering the prompt pattern from/to clipboard.
This is applicable to proposals 1 2 and 5A/B.
7. Make a configuration option which controls the behaviour of
NXPROMPT/PRPROMPT.

Proposals 1, 2 and 5A/B could be extended such that instead of a single
pattern/substitution the user could provide a list of these substitutions.
That would be the most powerful option, and I think that it could make (the
otherwise a bit complicated) proposals more comprehensible to a new user.

So here they are:
1X. Same as 1 with lists of patterns instead of just one pattern.
2X. Same as 2 but with lists of substitutions as configuration.
5AX. NXMATCH/PRMATCH with lists of patterns.
5BX. NXMATCH/PRMATCH with lists of substitutions.

For the variants 1X and 5AX the configuration would look identical to how Dave
showed it for proposal 3.

For variants 2X and 5BX it would look like this:
  prompt-pattern //^irb\([^)]+\):\d+:\d+. / # context-free IRB
  prompt-pattern /^(irb)\([^)]+\):\d+:\d+. /^\1\([^)]+\):\d+:\d+. / # context-sensitive irb
  prompt-pattern /^(>>> |\.\.\. )/^\1/ # context-sensitive Python
  prompt-pattern //^(>>>|\.\.\.) / # context-free Python

And as a bonus:
8. Instead from reading pattern/substitution lists from brltty.conf, there
could be a separate configuration file for prompt patterns. Then BRLTTY could
be shipped with a set of built-in prompt matching patterns for the most common
shells and REPLs.

Even though the variants 2, 2X 5B and 5BX provide the most power and
flexibility, I think that the extra power provided over variants 1*, 3 and 5A*
is not worth the complexity. These proposals would allow user's to do things
like this:

  prompt-pattern /^\[[^@]+@([^ ]+) [^]]+][$#] /^\[[^@]+@\1 [^]]+][$#] /

This monster allows a user to move only between prompts which are of the form
'[user at host dir]$ ', but such that it only moves to another prompt if that
prompt has the same host-name as the current one. But does anybody really want
to do this?

So here is my preference: I would like to see implemented in brltty either the
proposal 5AX or 1X, or proposals 3 with either of proposals 4 or 7. I would
not want to see only proposal 3 implemented without 4 or 7 for configuration.
Proposal 8 would be a nice addition in any case.

In other words I would want to have lists of patterns, and
context-insensitive matching. Perl-style regex is my favourite. What is yours?

-- 
Aura