[BRLTTY] Feature request: configurable prompt pattern

[Nicolas Pitre]

On Wed, 14 Mar 2018, Dave Mielke wrote:

> [quoted lines by Nicolas Pitre on 2018/03/14 at 15:49 -0400]
> 
> >Good, I agree with that part. But keeping the same analogy: what if one 
> >of your kid wants to be a race car driver? You could say to your kid: 
> >"you can't because the family car is suitable for casual driving only" 
> >or "a race car is dangerous and your brothers/sisters might never have 
> >the skills to drive it, so for their safety you can't drive one."
> 
> Yes, I understand that, and, in fact, have personally used that exact line of 
> reasoning on one of my employers (back in the '90s). Back in the days before 
> VPNs were understood very well by bosses, that employer had a rule that, from 
> home, we could connect either to their network or to the internet, but not to 
> both at the same time. I connected to both and was very open about it. One day, 
> they kind of arrested me and tried to get me in serious trouble.
> 
> At one point, the guy actually said that, even if I knew what I was doing, they 
> couldn't allow it because it wouldn't be fair to the others who didn't. To 
> this, I asked him (my exact question), "Do you have children?" He answered, 
> "Yes." I then asked, "If one of them is really good at something but the others 
> aren't, do you deny him in order to be fair to the others?" He went quite 
> silent, gave up his attempt to bully me into submission, and tried a different 
> tactic the next day (which he also lost). Perhaps that's a story for another 
> time, unless you (or anyone else) would like to hear it now.

Please entertain us!

> >You must cater to the fact that one of your kids might be a big power 
> >user, and that some advanced features simply won't be accessible or even 
> >interesting to the other kids.
> 
> I completely agree. Regarding NX/PRPROMPT, however, we do have a conflict. I 
> don't want to play the game of trying to find a new binding pair on every 
> braille device so we can't break what's alreayd there and useful to a lot of 
> people as is. This means that we must extend the current commands in the best 
> possible way.

Oh absolutely.  We do have too many functions that can be bound already.

> >This is why my proposal had a default regexp that maintained current 
> >functionality.
> 
> Sure, but it's not all that easy for most to understand. I'd rather just say 
> that no pattern means current behaviour.

Well, obviously that default regexp is an internal detail. It is just 
the default value when the config file option is not provided. This way 
the implementation is kept simple with only one method.

> Also, there's a subtle problem with your proposal. Let's say that the first 
> word on the current line contains a character that's meaningful to a regular 
> expression. It'd get substituted into the replacement, which would then make it 
> become part of the pattern used for matching. That'd cause all kinds of odd 
> behaviour that an average user may likely never figure out.

Indeed. But like the initial proposer suggested, the content from all 
backref substitutions would have to be filtered so regexp special 
characters are turned into literals..


Nicolas