[BRLTTY] Prompt matching, again

Aura Kelloniemi kaura.dev at sange.fi
Thu Sep 10 10:05:22 EDT 2020


Hello again,

Aura Kelloniemi <kaura.dev at sange.fi> writes:
 > There are problems in the current prompt matching implementation.
[--]
 >         while (length < scr.cols) {
 >             if (characters[length].text == WC_C(' ')) break;
 >             length += 1;
 >         }

 > This code essentially defeats all my attempts to match against a prompt which
 > contains spaces. This code should be disabled, when the regex matching feature
 > is in use.

I am actually wrong here. This code just finds the first word on the currently
selected line so that it can be used by the old prompt matching algorithm. So
it does not do any harm in the regex matching case, and my problem is not
about matching spaces. It wouldn't hurt though to make this code conditional.

 > Also, it seems that BRLTTY still falls back to the original prompt matching
 > strategy when I use the PRPROMPT command (but not when I use NXPROMPT). When
 > at least one prompt pattern is defined, PRPROMPT moves the braille window to
 > the previous line which either matches a prompt pattern or matches the first
 > word on the cursor line. For me this is highly undesirable. This prevented me
 > from noticing for a long time that my patterns don't actually work correctly.

This point remains valid though. In cmd_navigation.c on line 224, there is
this code:

    if (rgxMatchTextCharacters(promptPatterns, text, length, NULL, NULL)) return 1;

It clearly implements the fallback to the original algorithm, which confuses
me and makes it difficult to debug the problem that I'm having with my prompt
patterns.

It could be turned into

    return rgxMatchTextCharacters(promptPatterns, text, length, NULL, NULL) != 0;

to disable the fallback.

-- 
Aura


More information about the BRLTTY mailing list