[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: [email protected] | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
