Re: [BRLTTY] Feature request: configurable prompt pattern
[quoted lines by Aura Kelloniemi on 2018/03/16 at 17:45 +0200] >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. But I'd argue that it currently works exactly as it was originally intended. Lack of foresight, or any otehr consideration(s) at the time, doesn't mean unintended. And, as I've already mentioned, until we (recently) got screen scroll tracking, navigating to a moving target didn't make all that much sense. So you're still imposing your own view on how others see things. I don't think that's right. What's wrong with allowing for the possibility that others, for reasons you perhaps can't imagine, did something sensible? In my opinion, it's far more important to listen, and to allow for the possible intelligence of others, than it is to lecture and to judge. >I like this part a lot. It makes separation of patterns very clear. Yes. It's also part of my desire to look for ways to make things easier to use, understand, etc. > > 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. I don't think so. After all, the user knows if he/she is on a prompt or not. Besides, we could, for those braille devices that support long presses, make a long press force the context insensitive way. >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. But, as the one who configured your own set of patterns, I'd think you'd be aware of what those patterns are. I don't think, therefore, that you'd be caught all that much by surprise. >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. Or imlement the long press paradigm mentioned above so you have that choice. >My personal preference is always context-free. We can have a preference or two to customize behaviour. The issue, to me, is what should the default behaviour be. What I mean is not just the default if no patterns are defined, but also what it should be if patterns are defined. I strive to make defaults be what most users would want and/or intuitively expect. >Nicolas explained this in a good way in his latest post (before me posting >this one). Sure, but that was before my recent suggestions. I'm also not certain that the fact that a user has begun to define his/her own patterns necessarily means that intuition matches the expected preferences of an expert user. >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. But that's an expert speaking. I personally think that the much more common case is to go to another of the same kind of prompt, with defined patterns providing a way for navigation to make an intelligent guess when not on a prompt. >In other words I would want to have lists of patterns, I prefer the separate file approach, with a single (new) way to reload it, than the clipboard stuff. brltty.conf could have a prompt-file directive to specify it. >Perl-style regex is my favourite. What is yours? Mine is Posix extended regular expressions as they're the most likely ones to be supported on all platforms, and, at least to me, consistency is worth something. Maybe, if it's in high enough demand, a configure option, e.g. --with-regex-package, could be implemented to choose something else. Maybe we could include lots of them and have a selector within the menu to choose which one a user wants to 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
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 Python prompt-patt
Re: [BRLTTY] Feature request: configurable prompt pattern
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
[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
Dear Dave, and the list! Dave Mielke writes: > [quoted lines by Aura Kelloniemi on 2018/03/14 at 10:54 +0200] > >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. Yes, of course, that is is a limitation as well. It is something which with I can live more easily thatn with the current behaviour, but it does not say anything about anybody else's preferences. > Call the current scheme a hack, if you must, but I personally think that's > being a bit arrogantly judgemental. 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. There is no perfect solution, because TTY is not a system which can carry metadata about semantics of applications. > 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 don't know what is good for others, nor do I pretend to. And the current behaviour is certainly not useless. If it is a hack, it is a useful 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? Not at all. I can speak just for myself. That's exactly why I made two proposals. I particularly like applications which can be scripted. If this ability was available in BRLTTY, I would have scripted my own movement commands long time ago. There is no clearly "right way" to do this particular command in a predefined way, and that's why I would have implemented it for myself only. > >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. 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. And maybe somebody finds some other use for NXMATCH and PRMATCH than finding prompts - something that I haven't considered at all. I'm not trying to argue, I'm trying to explain my personal and limited views. > >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. Agreed. -- 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
[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). In the really early days I maintained a 1200 baud dial-in modem at my desk with its own phone number. This, too, was done with my manager's knowledge, and even with the knowledge of whoever was responsible for providing us phones at the time. Once, after we moved from one building to another, I'd made a late evening appointment with her to get that modem up and running as quickly as possible. Then, at almost the last minute, I cancelled on her because one of our children "decided" that it was time to be born. >Did they ever log in? I have no idea. Even though they wanted to spy on me, it wasn't my goal to spy on them. My goal was to put before them a very important question: My conscience is totally clear. Is yours? This reminds me of yet another event when they came after me, and which they also lost. Long before the company had a centralized way to do authentication, NIS was the only way to do it. Globally, they had somewhere around 30 NIS servers, each with its own domain. We, on the other hand, were the first (I think) to have a centralized web server that, among other things, gave access to the company's source repository. Parts of what it gave access to did need decent authentication, especially since people from other companies were often on sight. I figured the best way to do it was to build a list of which NIS domains were in use within each subnet. How to do that? I ran a job over a weekend that used 64 processes in parallel to ask every single host in the company which NIS domain it was bound to. Since that question couldn't be asked directly, the only way to do it was to ask each node if it was bound to each domain. That meant about 30 requests to each host throughout the company. This method worked out extremeloy well. Whenever our server would get a request for protected data, it'd calculate the subnet address and then authenticate the user with the correct NIS domain server. There was something, however, that I didn't know. When you ask a host if it's bound to an NIS server that it isn't bound to, it writes a log to that host's console. So, on Monday morning when everyone came in to work, every single console had 30 less 1 of those nasty-looking logs on its console. Now that seriiosly alarmed the security dudes. :-) So, while everything was running so nicely and I was feeling pretty good about it, my manager came by and told me I had to go with him. I asked, "Where?" He siad that it'd be best if I found out when I got there. This wasn't his normal style with me so I figure they'd ordered him not to tell me. We walked into this room and the main security dude got up and gave me a supposedly friendly handshake. Of course, it was a test to see how sheepishly or boldly I'd return the gesture. Then he sat down, invited me to sit down, and got to business. He told me that I was being acused of trying to crack passwords all over the company. That, of course, wasn't true at all but he wouldn't accept my denials. He then proceeded to ask me stupid questions, and, to each one, I gave an answer that drove him crazy. Remember that he's doing this, and I'm responding, in front of his colleagues, an HR person, and my manager. This whole thing took, literally, about two hours. Here are a few of the highlights that I remember: He asked me to show him the software that I'd run. I responded, "You're asking the criminal to produce the evidence? That's ridiculous. For all you know, I'll show you something completely different." He told me that I had to stay out of my office for the afternoon. I asked why. He said that it was so that they could look through my files. I told him, "That's stupid. This is a network. For all you know, I'll just go home and log in. Aren't you much better off with me sitting at my desk so that you can see what I'm up to?" Lots of this kind of stuff. He finally got frustrated with the fact that I wasn't responding to his crap like others must have, and asked me, "So why do you think you deserve special treatment?" I responded, "That's an excellent question. Tell me! Why do you think you deserve special treatment? If my management (remember, my manager is sitting right there) has a stupid idea, I tell them. You're asking stupid questions so I'm telling you!" 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." That was the very last time they tried to come after me. :-) >Maybe that could be useful
Re: [BRLTTY] Feature request: configurable prompt pattern
On Wed, 14 Mar 2018, Dave Mielke wrote: > 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. My boss at a former job had to put a PC under his desk. That PC would establish an outbound ssh connection to a few remote employees with port forwarding so we could effectively connect back into the company's network. This backdoor was the only way to do it as the IT people would simply refuse to provide any incoming access, not even with VPN boxes. And the ssh connection would use the https port of course, as anything else was blocked. This arrangement lasted for a couple years and went undetected all that 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. Did they ever log in? > >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. 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. > >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. Fair enough. > >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. Maybe not. That could be extended eventually if need be. For example: prompt_match = || # that's a direct match prompt_match = ||| # that's the ultimate match No need to implement the later initially. 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
[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 to
Re: [BRLTTY] Feature request: configurable prompt pattern
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 ___ 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
[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 curre
Re: [BRLTTY] Feature request: configurable prompt pattern
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
[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. :-) >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. >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. 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. 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. >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. >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). As do I. 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 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. >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. > Sure, but you should know me by now. I strive to get things right even if they may be perceived as less important. -- 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
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
[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
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
[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
[quoted lines by Shérab on 2018/03/14 at 15:21 +0100] >Would it make sense to have a preference to configure the prompt search >strategy? Its default could be to the current algorithm (use current >line as reference for what the prompt is) and then there could be >another option which would be regexp-based? Sure. It could even be used to specify which type of regular expression (basic, extened, advanced, ...) to 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
Hi, Would it make sense to have a preference to configure the prompt search strategy? Its default could be to the current algorithm (use current line as reference for what the prompt is) and then there could be another option which would be regexp-based? Shérab. ___ 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
[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
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
On Tue, 13 Mar 2018, Dave Mielke wrote: > [quoted lines by Aura Kelloniemi on 2018/03/13 at 14:59 +0200] > > > > 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. > > 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. 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
Aura Kelloniemi writes: > 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. No, even that does not work. It would allow for some extensibility, but would not work when the prompt itself is changing, like it is doing in IRB. It should be such that the result of the substitution is treated as a new regular expression which is matched against other lines on the screen to find other prompts. (This would require that the back-references are escaped before substitution, which makes libpcre routines less useful.) And this admittedly makes the whole feature complex to use, even for intermediate users. But at least those who have experience doing programming could benefit from it and the default setting could be tweaked such that it would take into account some common cases, like irb. Is there any other way to make NXPROMPT and PRPROMPT more generic? -- 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
[quoted lines by Aura Kelloniemi on 2018/03/13 at 14:59 +0200] > > 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/ You're helping me prove my point because even that isn't correct. If an expert has to work so hard and still get it wrong then I wouldn't want to inflict it on a regular user. > > 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. 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. -- 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
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
[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
[BRLTTY] Feature request: configurable prompt pattern
Hi 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. 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. 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.). Therefore I wish that a user-defined regex could be matched against screen content to decide whether something is a prompt or not. The default prompt could be set to be something like "^[^ ]+ " to match current behaviour, or something more complicated, e.g. "^[^ >]*[ >]". Thank you all for your input! -- 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
