[BRLTTY] Feature request: configurable prompt pattern

[Aura Kelloniemi]

Hello,

Dave Mielke <dave at mielke.cc> writes:
 > [quoted lines by Aura Kelloniemi on 2018/03/13 at 13:49 +0200]
 > >I'm missing a feature which would allow me to define a regular expression
 > >pattern that would be matched to decide what content on screen is a prompt and
 > >what is not for NXPROMPT/PRPROMPT commands. This would most likely be
 > >defined in brltty.conf.

 > I think you'd discover, very quickly, that it wouldn't work very well because 
 > you'd only be able to configure it, for all practical purposes, for one command 
 > environment (presumably your favourite shell). The moment you're within some 
 > other command environment this approach would become entirely useless.

Which is the case even now. Prompt searching is currently completely unusable
for me in DOSEMU and Ruby, and only partially useful in GHCi where the prompt
changes based on what modules are being loaded.

 > >The default prompt could be set to be something like "^[^ ]+ " to match
 > >current behaviour, 

 > That wouldn't match current behaviour at all. In fact, it'd match any line at 
 > all whose first space isn't in column 1. Current behaviour considers the 
 > content of the current line in order to know exactly what to match.

Oh, sorry, you are absolutely right.

What I would want to have is a Perl-style (or sed-style) regex substitution,
where the original string is the current line. Like this:

s/^([^ ]+ ).*/\1/

Then the result of the substitution is compared to screen contents to find
other prompts.

That would match current behaviour. If the substitution fails, there is no
prompt on current line.

 > >or something more complicated, e.g. "^[^ >]*[ >]".

 > Maybe your shell prompt looks like that, but, since a shell's prompt is 
 > configurable, I'm sure it's far from a common case. Would we really want every 
 > single brltty user to need to understand the complexities and pitfalls of 
 > regular expressons in order to benefit from the PR/NXPROMPT functionality?

No, not at all. This sed-like behaviour would resolve the problem. It does not
need action from anybody, but allows for great configurability. libpcre
supports doing this substitution out of the box. libpcre is anyways installed
on almost all systems. I feel this would not be very difficult to add, and
being able to use NXPROMPT and PRPROMPT in irb, GHCi, DOSEMU, Debian chroots
(with their default PS1 settings), etc. would really make my life easier. And
these are quite common applications.

-- 
Aura