Dave Mielke <[email protected]> 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@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 _______________________________________________ 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.com/mailman/listinfo/brltty
