Re: [BRLTTY] Feature request: configurable prompt pattern

[Aura Kelloniemi]

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

Re: [BRLTTY] Feature request: configurable prompt pattern

[Nicolas Pitre]

On Thu, 15 Mar 2018, Dave Mielke wrote:

> [quoted lines by Nicolas Pitre on 2018/03/14 at 23:30 -0400]
> 
> >This arrangement lasted for a couple years and went undetected all that time.
> 
> I had no problem being totally open about it. It just meant that I had to be 
> prepared for the battle (should one arise, as it eventually did).

Well, my boss on site lost that battle. So I had little hope winning it 
while being remote. He just installed a back door so we could go back to 
actual work. And that was the end of the fight.

> I don't remember what he asked, but my response was, "You clearly have no 
> idea 
> how to do your job. I do, so I'm telling you. You wouldn't listen to me under 
> any other circumstances, but you have to listen to me now, so I'm using this 
> oportunity to teach you how to provide real network security."

Being responsible for network security is a stressful job. Someday, 
someone will know about a vulnerability that IT people don't know about 
and they'll get hacked, and they'll be blamed for it of course. That 
makes for very paranoid people.

> >Maybe that could be useful if someone wants to move between two 
> >different types of prompts. But I think that for now, simply providing 
> >the ability to change the current prompt matching should actually cover 
> >most advanced use cases.
> 
> We do have two cases, and I'm not yet sure how to provide both of them. Maybe 
> using short/long presses is the way to do it. The two cases are moving to the 
> next/previous prompt when not on a prompt, and moving to the next/previous 
> prompt based on the prompt you're currrently on.

Well, a prompt based on the line you're currently on is just an easy way 
to have a generic feature without having to configure anything. Once you 
have the ability to define your prompt search match then maybe there 
isn't much need for basing it off of the current line. So I don't think 
that distinction has to be made at the UI level.


Nicolas
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

[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. I disagree that the current paradigm is anywhere close to that.

I've already mentioned that it made little sense to move to a prompt when the 
screen isn't reasonably stable, which is the case while a command is still 
running. Now that we have Track Screen Scroll, however, it does make sense. 
Since the Track Screen Scroll feature is new in 5.6, so just a little over a 
month old, claiming that a rather old feature which isn't all that useful 
without the new feature is a "hack" is, at least to me, rather unfair.

I forget how old NX/PRPROMPT is, but they go back quite a way. Until not all 
that long ago, we had an unofficial requirement to stay away from too many 
dependencies because brltty had to be able to be squeezed onto a boot disk. 
While this is no longer true, again, something not being enhanced just because 
the thought of revisiting it hasn't yet come up doesn't make its current 
implementation a "hack".

So, please, let's stay away from making judgements. They simply aren't 
necessary, don't add anything useful to any discussion, and, more often than 
not, rghtly or wrngly, they come off as self exultation. I don't like it, and 
will push back against it.

>There is no perfect solution, because TTY is not a system which can carry 
>metadata about semantics of applications.

Sure. Another such issue, which impacts brltty's linear copy feature, is when 
the end of a line within a multi-line copy isn't blank. Is it, or isn't it, 
line continuation (wrapping). It's impossible to know without a bit of human 
judgement. Of course we could add tons of code to try to get it right, but 
would all that complexity justify such little gain?

>I don't know what is good for others, nor do I pretend to. 

Yes, so let's please choose a way of expressing ourselves that assumes 
usefulness to others.

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

>If this ability was available in BRLTTY, I would have scripted my own movement 
>commands long time ago. 

But, then, the idea of providing more powerful functionality within brltty 
itself may never have come up. You may be interpreting my challenging your 
choice of words and my questioning of your ideas as resistence, but you'd be 
wrong. Your idea is good. A few days worth of my challenges are just because I 
want to get it right rather than implement a "hack".

>The only kind of benefit from this approach would be that then the
>context-sensitive and the context-insensitive behaviour would be both
>available at the same time, if somebody wants them. 

That may not be true. I can think of a way to do it and am wondering what you 
think about it.

We could allow several patterns to be specified. For example:

   prompt-pattern pattern1
   prompt-pattern pattern2
   prompt-pattern pattern3

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, and, if it 
doesn't, then we join them, e.g.:

   (pattern1|pattern2|pattern3)

and do the context-independent thing. 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.

-- 
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: d...@mielke.cc | 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: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

[quoted lines by Nicolas Pitre on 2018/03/14 at 18:23 -0400]

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

The very first thing I did, of course, after that phone call was to call my 
manager and alert him to the issue. My guess, which turned out to have been 
right, was that the guy would himself call my manager and give him a biased 
account, and I also didn't want my manager to be caught by surprise without 
knowing what to say.

The guy first tried to put the fear of termination into my manager if he didn't 
get me under control. My manager told him that there was nothing to worry 
about, and that they should get over it, stop threatening people, and pursue 
actual problems. That brought on the new tactic which I referred to above.

The next day, they sent my manager a list of six conditions that they ordered 
him to agree to. I suspect they were hoping that he'd simply cave and comply, 
but, instead, he forwarded those conditions to me and asked me what I thought. 
I then responded to the network security dudes directly, copying my manager, 
with my thoughts. I suspect that already really bothered them because they were 
no longer dealing secretly behind my back.

This was maybe 25 or so years ago, so I only remember three of the six 
conditions. As I recall, though, the other three were boring and things I could 
readily agree to, anyway. The three I remember were:

They demanded the right to probe my home network address any time they wanted 
to, without warning, to comfort themselves that I hadn't become a way around 
their firewall. Being one who believes in always being comletely up front with 
everyone, I, of course, readily agreed, and even encouraged them to do so.

They demanded that if they ever, even just once, found a problem in shis area 
that I'd have to immediately cease what I was doing forever. My response to 
this one was an emphatic NO! I told them that, should they ever detect a 
problem, then I'd stop temporarily while they and I worked together, as a 
priority item, to find the problem and resolve it.

The last one that I remember was their demand that I keep them up-to-date 
regarding my home network's configuration. I had some fun with this one. I told 
them that I'd offer them something even better than that - I'd create them an 
account on my network that they could log into any time and check for 
themselves. So what was the fun I had with this one? Two things:

The account I created was named xxspyman (xx being the company's initials). So, 
using my own initials as an example, dmspyman. I won't give their actual 
initials away, but, of course, my résumé is online and anyone could figure it 
out. If you do, though, please don't fault the company as a whole. It was a 
good company. It's just that network security wasn't understood very well back 
then so the higher management was putting too much trust in the people who had 
that job at the time.

I set up the login profile for their account with a prompt which stated that I 
believe Bible reading to be good for people so would they please first read one 
chapter from the Bible and then enter into the prompt which chapter it was. The 
prompt stated that this was all on the honour system, and that I was assuming 
them to be honourable people who'd answer truthfully.

What happened after all of this? Absolutely nothing! Neither my manager or me 
heard from them ever again. The issue seemed to have more than quietly just 
gone away.

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

Well ... we could start using long presses. The problem with this, however, is 
that some braille devices don't support them. What I mean is that pressing a 
key on some of them immediately sends the release so we can't tell how long it 
was pressed for. So long presses are useful for devices that support them, but 
we can't use them as a general solution.

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

I prefer if-then-else, i.e. if it's set then use it else use the current code. 
There are two reasons for this. One is that we need fallback code, anyway, in 
the case that autoconf says that we can't use regular expressions. The other is 
that it prevents surprises from creeping into the default case.

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

I missed that one. In any case, I don't think that the comlexity of creating a 
dynamic regular expression would really give us all that much extra.

-- 
I believe the Bible 

Re: [BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

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

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

Additionally: What's been requested is entirely reasonable and definitely very 
useful. This, at least to me, means that it should be done in a way that 
doesn't require anyone who wants to use it to maintain a private key subtable. 
We should be making the new functionality as easy as possible for anyone to use 
so that inexperienced people can easily choose to grow into it, at their own 
individual pace, without having to learn more than absolutely necessary in 
order to get there.

>There is a point where you can't have a more powerful tool without 
>assuming bigger risks.  If I am blind and I acquire a chainsaw (which I 
>actually am and actually did) because I want more power than a hand saw, 
>then I must be trained for it and prepared to assume the risks. 

Yes, I agree. That doesn't mean, though, that we should barrel ahead without 
careful forethought. Also, as I eluded to earlier, I don't want to end up with 
a careless design.

>Yet there are people saying that blind people should be effectively isolated 
>from using a chainsaw. 

Not me! People should be free to do things. But, if a small change to a 
chainsaw would make it easier for a blind person to use, then why not ask for 
it. In most cases, such considerations actually benefit sighted people, too.

Wheelchair ramps, for example, were most likely initially implemented as a 
special needs consideration. The fact is, however, that those very same ramps 
make it so much easier for parents with strollers, pedestrians with grocery 
carts, etc. The right considerations tend to benefit everyone.

Here in Ottawa, the buses now have audio announcements that, among other 
things, tell you what the next stop is. That came about because of a bunch of 
whiny blind people (an approach I don't like). Our transit company, however, 
took some time imlementing it, and did it in a way that's made everyone happy. 
One thing they did, for example, was to also add easy-to-see screens that also 
show what the next stop is. Now, sighted people are even happy because they 
don't have to look through crowds, dirty or snow-covered windows, etc to figure 
out where they are.

>One thing I fully agree with, though, is the fact that chainsaws aren't for 
>everyone, blind or not, and most people will be happy buying lumber already 
>cut by default and that's OK.

Which is ultimately all I'm wanting to do, too, with this feature.

>Hence the need for an extended tool that provides the same results as 
>the simple one by default. 

Yes. The main point of mine that you're responding to was to challenge an 
attitude - not to resist the feature. I didn't like the way a few things were 
stated so I chose to speak up.

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

Also, there's a subtle problem with your proposal. Let's say that the first 
word on the 

Re: [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 14:18 -0400]
> 
> >My turn to challenge your interpretation.  ;-)
> 
> Sure. We can have lots of fun with this one. :-)

I'm up to the challenge.  ;-)

> >The great responsibility raising your children is incumbent on you. That 
> >means *your* life becomes more complex, not necessarily theirs.
> 
> Yes, but (rather simplistically) let's complete the analogy. Our children are 
> stuck with our home and our rules. My wife and I are the ones who establish 
> our 
> home and make those rules. That makes my wife and I like the develoeprs and 
> our 
> children like the users. We establish the way things work and they're stuck 
> with the results of our decisions. To me, this illustrates that the 
> responsibility is on the developers to make things as easy as possible for 
> the 
> users.

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

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.

> >Same thing here: if you want to use a powerful tool or feature, it can't 
> >be simple. 
> 
> But it isn't fair that some users wanting to use a more powerful tool means 
> that others should be effectively isolated from using it. Note that I'm not 
> saying that it shouldn't be done - I'm just pushing the discussion a bit the 
> other way in order to encourage discussion such that the needs of both 
> communities can best be met.

There is a point where you can't have a more powerful tool without 
assuming bigger risks.  If I am blind and I acquire a chainsaw (which I 
actually am and actually did) because I want more power than a hand saw, 
then I must be trained for it and prepared to assume the risks. Yet 
there are people saying that blind people should be effectively isolated 
from using a chainsaw. One thing I fully agree with, though, is the fact 
that chainsaws aren't for everyone, blind or not, and most people will 
be happy buying lumber already cut by default and that's OK.

> The initial requst was "I want it to work this way because the way it works 
> now 
> is useless and a hack". I'm pushing back. The way it works now isn't a hack, 
> and it works perfectly fine for most users.

I agree. And whatever improvements/extensions to that feature must 
retain the current behavior by default for those users.

> Now, sure, let's make it work better for those with greater needs. No 
> problem with that, but let's not get it into our heads that our innate 
> cleverness gives us the right to summarily dismiss the needs of the 
> rest.

But the needs of the rest are already fulfilled as you stated yourself 
above.

> >Yet, if you want to use a powerful tool, it is your responsibility to deal 
> >with its complexity.
> 
> But that's exactly my point! Lots of people want to use NX/PRPROMPT, but that 
> doesn't mean they want to use a complex tool. Most people want to use a 
> simple 
> tool, and it isn't fair for us to impose a more complex tool on them. So, 
> sure, 
> some of us want to use a more powerful tool, so let's develop it in a way 
> that 
> doesn't alienate those who don't.

Hence the need for an extended tool that provides the same results as 
the simple one by default. Those who are satisfied with the simple 
behavior simply have to ignore the new extension and they won't be 
alienated.

> My goal, here, is to try to figure out what the best design is - to 
> capture the right balance between maintaining current functionality 
> and introducing new functionality. That needs discussion, not just an 
> "I want" followed by a "here you go".

This is why my proposal had a default regexp that maintained current 
functionality.

> >This prompt matching feature gets complex with the use of regexp. It 
> >provides tremendous power over the current implementation. If you don't 
> >need that power, stick to the default and forget that regexps exist.
> 
> Yes, and that's what configuration/preferences are designed to achieve. To 
> get 
> them right, though, is what the actual issue is. I don't want to just go for 
> it, and then end up with a basic design that we'll regret forever.

All this being said, what is your concern about the current proposal?



Nicolas
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Nicolas Pitre]

On Wed, 14 Mar 2018, Dave Mielke wrote:

> [quoted lines by Nicolas Pitre on 2018/03/13 at 22:10 -0400]
> 
> I accidentally lost a quote that I wanted to challenge. It was something like:
> 
> >With great power comes great responsibility (complexity).
> 
> I agree with the first part, but not with the second. In other words, I don't 
> equate responsibility with complexity. Let's look at an example. As a parent, 
> I 
> indeed have a great responsibility insofar as raising our children is 
> concerned. Does that justify me making the principles by which they're to 
> live 
> be complex? No way! I do my best to make things as easy for them to 
> understand 
> and grasp since that maximizes their ability to remember and easily apply 
> them, 
> and, therefore, to be able to grow up properly.

My turn to challenge your interpretation.  ;-)

The great responsibility raising your children is incumbent on you. That 
means *your* life becomes more complex, not necessarily theirs.

> I also disagree wth applying a truism for people to non-people. Software, 
> after 
> all, isn't responsible for anything. Those who implement software, however, 
> are 
> indeed responsible for what their software does, how it works, etc. Doing all 
> they can to ensure that those who use their software get into as little 
> trouble 
> as possible is the responsibility of those who've been granted the power of 
> providing software that others use.

Same thing here: if you want to use a powerful tool or feature, it can't 
be simple. Yet, if you want to use a powerful tool, it is your 
responsibility to deal with its complexity.  Doesn't mean it is wrong 
not wanting any complexity, but then you need to live with preconfigured 
features and that's OK (I do it all the time).

This prompt matching feature gets complex with the use of regexp. It 
provides tremendous power over the current implementation. If you don't 
need that power, stick to the default and forget that regexps exist.

And this is not a critical feature either, meaning that if someone 
messes up the prompt matching option, then only PRPROMPT / NXPROMPT will 
be crippled, but that won't cause real trouble to the unfortunate 
user given that the display and basic navigation functions are still 
available.


Nicolas
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

[quoted lines by Nicolas Pitre on 2018/03/13 at 22:10 -0400]

I accidentally lost a quote that I wanted to challenge. It was something like:

>With great power comes great responsibility (complexity).

I agree with the first part, but not with the second. In other words, I don't 
equate responsibility with complexity. Let's look at an example. As a parent, I 
indeed have a great responsibility insofar as raising our children is 
concerned. Does that justify me making the principles by which they're to live 
be complex? No way! I do my best to make things as easy for them to understand 
and grasp since that maximizes their ability to remember and easily apply them, 
and, therefore, to be able to grow up properly.

I also disagree wth applying a truism for people to non-people. Software, after 
all, isn't responsible for anything. Those who implement software, however, are 
indeed responsible for what their software does, how it works, etc. Doing all 
they can to ensure that those who use their software get into as little trouble 
as possible is the responsibility of those who've been granted the power of 
providing software that others use.

-- 
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: d...@mielke.cc | 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: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Nicolas Pitre]

On Wed, 14 Mar 2018, Dave Mielke wrote:

> [quoted lines by Nicolas Pitre on 2018/03/13 at 22:10 -0400]
> 
> >But the inexperienced wouldn't have to do anything if the default 
> >mimics the current behavior, no?
> 
> Yes, for sure.
> 
> >However such a feature i.e. the ability to modify what NXPROMPT matches, 
> >could be very useful to those who are experienced enough to tweak their 
> >prompt.
> 
> Yes. I think my issue is with the complexity of overriding the default. I'd 
> still like that, if possible, to be simple enough to be usable by more peolpe 
> than just the super experienced.

With great power comes great responsibility (or complexity).
When it is too simple, it is usually not all that useful either.

The optimal solution as mentioned already would be:

prompt_match = |||

where  is applied to the current line to produce  
which is then used to find a matching line. The default to preserve 
current behavior would then be:

prompt_match = |^([^ ]+ ).*|^\1|

But someone not acquainted with regexp still can use it simply, e.g.:

prompt_match = ||^my_custom_prompt: |

And to make things simpler, you could make the initial ^ implicit so the 
trivial form becomes:

prompt_match = ||my_custom_prompt: |

And the implicit ^ can be overridden with .* at the beginning for those 
advanced users who might want special prompt tracking located in the 
middle of the screen, so no flexibility is lost.

Here I used | as a separator, but any character should be usable just 
like with sed.


Nicolas
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

[quoted lines by Aura Kelloniemi on 2018/03/14 at 10:54 +0200]

>I consider the current behaviour to be a little bit of a hack itself. I
>consider it to be a big limitation that in order to be able to move from one
>prompt to another I have to first position the braille window on a line which
>already has a prompt. 

Perhaps, but before we had Track Screen Scroll (new in 5.6) the previous prompt 
line was a moving target unless the screen was stable. Now that we have Track 
Screen Scroll, of course, the situation has changed.

>Another big limitation is that I can't move between two different types of 
>prompts.

But, in fairness, a regular expression wouldn't support an arbitrary prompt, 
i.e. one that wasn't foreseen. Call the current scheme a hack, if you must, but 
I personally think that's being a bit arrogantly judgemental. I myself prefer 
to steadily move toward something that's the most useful rather than to simply 
assume that I know what's best for others. And, again to me, it's perfectly 
okay to view the current method as a step along that way rather than as a 
useless hack.

>I would prefer to have PRPROMPT/NXPROMPT commands which are totally
>context-insensitive - i.e. regex-match based. 

You do, but the feature doesn't exist just for you. There are others who prefer 
the context-sensitive way. Are they wrong?

>First proposal - add prompt-pattern configuration option: This option is a
>string, which is a regular expression pattern. NXPROMPT and PRPROMPT commands
>move the window down and up respectively until the contents of the line on
>which the window is matches this regular expression. THe expression can be
>arbitrarily complex, and because regex supports alternatives, it can easily
>recognize many different types of prompts. 

Yes, if optional, that'd be reasonable.

>If prompt-pattern was not defined or was set to a specific value (e.g. empty
>string), then BRLTTY's current context-sensitive behaviour would be invoked
>instead of pattern matching.

Yes, that'd be essential. I'd go for the "is empty" paradigm as that's the way 
unspecified options work and also because I ahate special, magic values.

>Second proposal - add new matching commands: Don't modify NXPROMPT or PROMPT
>commands. Instead add NXMATCH and PRMATCH commands which match a regex pattern
>in a way described in the previous section. This command would use a pattern
>defined in brltty.conf with default-pattern option. 

I don't like this approach so much for at least these reasons. There might be 
some braille devices for which a new pair of bindings is difficut to find. 
Maintaining a private key table is, again, something that most users shouldn't 
need to do. While I'm against implementing a facility that's too complex for 
most people, I'm also against "hiding" new features - specifying a pattern (as 
in your first proposal) is enough to make it optional and usable.

>There could be additional commands for modifying this pattern - e.g. 
>SETPATTERN (which sets the pattern from the current contents of clipboard), 
>RESETPATTERN (which resets it back to the default value) and CLIP_PATTERN 
>(which would copy the pattern to clipboarrd for pasting and editing it).

this, to me, is an entirely separate feature. It should be implemented on top 
of, rather than embedded within, however the first one is implemented.

-- 
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: d...@mielke.cc | 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: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

[quoted lines by Nicolas Pitre on 2018/03/13 at 22:10 -0400]

>But the inexperienced wouldn't have to do anything if the default 
>mimics the current behavior, no?

Yes, for sure.

>However such a feature i.e. the ability to modify what NXPROMPT matches, 
>could be very useful to those who are experienced enough to tweak their 
>prompt.

Yes. I think my issue is with the complexity of overriding the default. I'd 
still like that, if possible, to be simple enough to be usable by more peolpe 
than just the super experienced.

>I think this would be a worthwhile feature if the default preserves 
>existing functionality for those who don't care about the extra 
>flexibility.

I'm not opposed to the concept at all - just pushing for ideas to try to keep 
it as easy to use as possible.

-- 
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: d...@mielke.cc | 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: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Aura Kelloniemi]

Hi

Nicolas Pitre  writes:
 > On Tue, 13 Mar 2018, Dave Mielke wrote:
 > > I completely understand your reason and the convenience. I'm just not 
 > > convinced 
 > > that it'd actually work all that well as a general facility for the 
 > > inexperienced.

 > But the inexperienced wouldn't have to do anything if the default 
 > mimics the current behavior, no?

 > However such a feature i.e. the ability to modify what NXPROMPT matches, 
 > could be very useful to those who are experienced enough to tweak their 
 > prompt.

 > I think this would be a worthwhile feature if the default preserves 
 > existing functionality for those who don't care about the extra 
 > flexibility.


I consider the current behaviour to be a little bit of a hack itself. I
consider it to be a big limitation that in order to be able to move from one
prompt to another I have to first position the braille window on a line which
already has a prompt. Another big limitation is that I can't move between two
different types of prompts.

I would prefer to have PRPROMPT/NXPROMPT commands which are totally
context-insensitive - i.e. regex-match based. I suggest here two alternative
implementations:

First proposal - add prompt-pattern configuration option: This option is a
string, which is a regular expression pattern. NXPROMPT and PRPROMPT commands
move the window down and up respectively until the contents of the line on
which the window is matches this regular expression. THe expression can be
arbitrarily complex, and because regex supports alternatives, it can easily
recognize many different types of prompts. Here is an example, which matches a
normal [user@host dir]$ shell prompt in addition to python, gdb and irb.
"^\[[^ ]+@[^ ]+ [^]]+\][$#] |^>>>|^\.\.\.|^\(gdb\) |^irb\([^)]+\):\d+:\d+. "

If prompt-pattern was not defined or was set to a specific value (e.g. empty
string), then BRLTTY's current context-sensitive behaviour would be invoked
instead of pattern matching.

Second proposal - add new matching commands: Don't modify NXPROMPT or PROMPT
commands. Instead add NXMATCH and PRMATCH commands which match a regex pattern
in a way described in the previous section. This command would use a pattern
defined in brltty.conf with default-pattern option. There could be additional
commands for modifying this pattern - e.g. SETPATTERN (which sets the pattern
from the current contents of clipboard), RESETPATTERN (which resets it back to
the default value) and CLIP_PATTERN (which would copy the pattern to
clipboarrd for pasting and editing it).

These NXMATCH and PRMATCH commands could be unbound by default, so that they
are really available to power users only.

I'm actually up for the second proposal, because it would allow me to
dynamically change the pattern.

-- 
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Aura Kelloniemi]

Hello,

Dave Mielke  writes:
 > [quoted lines by Aura Kelloniemi on 2018/03/13 at 13:49 +0200]
 > >I'm missing a feature which would allow me to define a regular expression
 > >pattern that would be matched to decide what content on screen is a prompt 
 > >and
 > >what is not for NXPROMPT/PRPROMPT commands. This would most likely be
 > >defined in brltty.conf.

 > I think you'd discover, very quickly, that it wouldn't work very well 
 > because 
 > you'd only be able to configure it, for all practical purposes, for one 
 > command 
 > environment (presumably your favourite shell). The moment you're within some 
 > other command environment this approach would become entirely useless.

Which is the case even now. Prompt searching is currently completely unusable
for me in DOSEMU and Ruby, and only partially useful in GHCi where the prompt
changes based on what modules are being loaded.

 > >The default prompt could be set to be something like "^[^ ]+ " to match
 > >current behaviour, 

 > That wouldn't match current behaviour at all. In fact, it'd match any line 
 > at 
 > all whose first space isn't in column 1. Current behaviour considers the 
 > content of the current line in order to know exactly what to match.

Oh, sorry, you are absolutely right.

What I would want to have is a Perl-style (or sed-style) regex substitution,
where the original string is the current line. Like this:

s/^([^ ]+ ).*/\1/

Then the result of the substitution is compared to screen contents to find
other prompts.

That would match current behaviour. If the substitution fails, there is no
prompt on current line.

 > >or something more complicated, e.g. "^[^ >]*[ >]".

 > Maybe your shell prompt looks like that, but, since a shell's prompt is 
 > configurable, I'm sure it's far from a common case. Would we really want 
 > every 
 > single brltty user to need to understand the complexities and pitfalls of 
 > regular expressons in order to benefit from the PR/NXPROMPT functionality?

No, not at all. This sed-like behaviour would resolve the problem. It does not
need action from anybody, but allows for great configurability. libpcre
supports doing this substitution out of the box. libpcre is anyways installed
on almost all systems. I feel this would not be very difficult to add, and
being able to use NXPROMPT and PRPROMPT in irb, GHCi, DOSEMU, Debian chroots
(with their default PS1 settings), etc. would really make my life easier. And
these are quite common applications.

-- 
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty

Re: [BRLTTY] Feature request: configurable prompt pattern

[Dave Mielke]

[quoted lines by Aura Kelloniemi on 2018/03/13 at 13:49 +0200]

>I'm missing a feature which would allow me to define a regular expression
>pattern that would be matched to decide what content on screen is a prompt and
>what is not for NXPROMPT/PRPROMPT commands. This would most likely be
>defined in brltty.conf.

I think you'd discover, very quickly, that it wouldn't work very well because 
you'd only be able to configure it, for all practical purposes, for one command 
environment (presumably your favourite shell). The moment you're within some 
other command environment this approach would become entirely useless.

>Currently I think that when using the above mentioned commands, brltty uses
>whatever there is on the currently displayed line (from the beginning up to
>the first space) as the prompt string which it then compares to beginnings of
>other lines.

Yes, that's correct.

>This approach does not work, if the prompt does not end in a space, or if the
>prompt is constantly changing (e.g. if it displays a line number, time, exit
>status of last process, etc.).

Yes, I understand.

>The default prompt could be set to be something like "^[^ ]+ " to match
>current behaviour, 

That wouldn't match current behaviour at all. In fact, it'd match any line at 
all whose first space isn't in column 1. Current behaviour considers the 
content of the current line in order to know exactly what to match.

>or something more complicated, e.g. "^[^ >]*[ >]".

Maybe your shell prompt looks like that, but, since a shell's prompt is 
configurable, I'm sure it's far from a common case. Would we really want every 
single brltty user to need to understand the complexities and pitfalls of 
regular expressons in order to benefit from the PR/NXPROMPT functionality?

Additionally, do we really want to make it extremely difficult, if not entirely 
impossible, for an average brltty user to benefit from PR/NXPROMPT 
functionality within more than just a single command environment?

-- 
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: d...@mielke.cc | 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: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty