[BRLTTY] Prompt matching.

[Dave Mielke]

[quoted lines by Aura Kelloniemi on 2018/10/09 at 14:17 +0300]

> > I'm wondering, though, if we should just maybe insist on the use of pcre2
> > because it supports wchar_t which brltty uses. Then we wouldn't have to do any
> > parsing, character reencoding, etc, and it should just work. Brltty even
> > already converts the UTF-8 characters in data files to wchar_t for processing.
>
>My personal opinion would be yes.

Done. Prompt matching via regular expressions is now working via pcre2. Should
we also support the older pcre1 if pcre2 isn't available?

If no patterns are defined then the original scheme of matching against the
start of the current line is used. If at least one pattern is defined then only
the patterns are used. They're forced to match at the start of a line (so you
don't need to use ^).

Define as many patterns as you'd like via the (new) brltty.conf prompt-pattern
directive. Since brltty.conf parsing already uses backslash escaping, you'll
need to double a backslash to get it into the regular expression. For example,
\s means a literal blank (brltty.conf) whereas \\s means match any whitespace
character (pcre).

Since brltty.conf parsing doesn't (yet) allow whitespace within a directive's
operand, they'll need to be escaped. In addition to \s for a blank, all the
other normal escapes (\a, \e, \f, \n, \r, \t, \v, \\) are also supported. To
specify a character in hex, use \x for two digits, \u for four digits, and \U
for eight digits.

At the moment (though this may change), this mechanism uses the -z short
command line option (because I haven't thought of a more appropriate free
letter yet). You can, of course, also use the --prompt-pattern long option.
While the brltty.conf escape parsing doesn't apply to command line options,
ou'll of course need to fight with the shell's parsing instead. Using single
quotes is the simplest way because the only special character you'll need to
worry about when using them is the single quote itself (which can't be
escaped).

As discused earlier, the "comma restriction" is still there. If you specify
commas, whether in brltty.conf or on the command line, the operand will be
interpreted as a comma-separated list of separate patterns.

Please let me know how it's working.

>I never liked Perl either. The only thing that I like about Perl though is its
>regular expression syntax. Its escaping rules are more consistent than
>POSIX's, it has many very convenient additional matchers, like \d for
>[[:digit:]] and \s for [[:space:]]. It supports unicode properties - for
>example \w can be configured to take into account all Unicode letters. I
>personally like comments a lot in PCRE (?# Because they make long regexes
>comprehensible again). 

I learned enough Perl to know that it actually has a couple of other useful
features. One is the redo statement, which goes to the top of the current loop
without iterating. The other is the ability to choose whether a local variable
is or isn't visible to the functions that are called.

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