Re: Please accept M-p as well as C-p
Maybe not as convenient, but there's always (vi-mode) [fF]^j[lj] If it gets to be that jumping between lines is important I usually invoke the editor. If you are going to get into making a mini-editor that allows jumping between lines moving completion to something like Meta-tab or ctrl-tab would be more useful. Chet Ramey wrote: On 2/13/14, 12:03 PM, Andreas Schwab wrote: Chet Ramey writes: On 2/13/14 11:29 AM, Andreas Schwab wrote: AIUI there is no readline command the moves vertically within the commandline (in readline a line always includes any embedded newlines). That's true. How should such a command work? Move point forward and backward by a multiple of the screenwidth? It should work like previous-line/next-line in Emacs: move over the previous/next newline and then forward to the same column as before. That's kind of a problem. The editing and display engines in readline are more or less separate, and that has consequences on implementation. The editing engine sees the world as a character array of potentially infinite length. Text adds and deletes, and moving the location of point, all happen within this buffer. There are very few cases where a line has embedded newlines, so your previous message about a command to move between lines with embedded newlines would be relatively easy to do but of limited usefulness. The display engine takes this array of characters and handles all aspects of screen presentation: displaying the prompt, handling invisible and multibyte characters, and wrapping the line according to the current screen dimensions. The reason I mention this is that the much more frequently-encountered case is the one where a long line is wrapped at the screen width. How should a command that moves vertically between lines behave in such a situation? It looks to me like emacs, which handles line wrapping itself in shell mode, treats C-p and C-n very similarly to C-a and C-e. If you want this hypothetical future command to move vertically between lines that are wrapped at the screen width, which I believe is going to be the much more useful case, then we should talk about how you specify and implement that. Chet
Re: Please accept M-p as well as C-p
On 2/13/14, 12:03 PM, Andreas Schwab wrote: > Chet Ramey writes: > >> On 2/13/14 11:29 AM, Andreas Schwab wrote: >> >>> AIUI there is no readline command the moves >>> vertically within the commandline (in readline a line always includes >>> any embedded newlines). >> >> That's true. How should such a command work? Move point forward and >> backward by a multiple of the screenwidth? > > It should work like previous-line/next-line in Emacs: move over the > previous/next newline and then forward to the same column as before. That's kind of a problem. The editing and display engines in readline are more or less separate, and that has consequences on implementation. The editing engine sees the world as a character array of potentially infinite length. Text adds and deletes, and moving the location of point, all happen within this buffer. There are very few cases where a line has embedded newlines, so your previous message about a command to move between lines with embedded newlines would be relatively easy to do but of limited usefulness. The display engine takes this array of characters and handles all aspects of screen presentation: displaying the prompt, handling invisible and multibyte characters, and wrapping the line according to the current screen dimensions. The reason I mention this is that the much more frequently-encountered case is the one where a long line is wrapped at the screen width. How should a command that moves vertically between lines behave in such a situation? It looks to me like emacs, which handles line wrapping itself in shell mode, treats C-p and C-n very similarly to C-a and C-e. If you want this hypothetical future command to move vertically between lines that are wrapped at the screen width, which I believe is going to be the much more useful case, then we should talk about how you specify and implement that. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Please accept M-p as well as C-p
Bob Proulx writes: > In emacs 24 this is the new feature controlled by the line-move-visual > variable. Call me a Luddite if you want but in emacs 24 I turn that > feature off. I am very much "used to using" the traditional behavior > and like it. I do as well. > Thinking about it I think that the recent addition of line-move-visual > to emacs and not to libreadline is probably the reason for the request > for this feature. I have always missed that feature, though not desperately enough to bother asking for it or implementing it myself. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Please accept M-p as well as C-p
Andreas Schwab wrote: > Chet Ramey writes: > > Andreas Schwab wrote: > >> AIUI there is no readline command the moves > >> vertically within the commandline (in readline a line always includes > >> any embedded newlines). > > > > That's true. How should such a command work? Move point forward and > > backward by a multiple of the screenwidth? > > It should work like previous-line/next-line in Emacs: move over the > previous/next newline and then forward to the same column as before. In emacs 24 this is the new feature controlled by the line-move-visual variable. Call me a Luddite if you want but in emacs 24 I turn that feature off. I am very much "used to using" the traditional behavior and like it. Thinking about it I think that the recent addition of line-move-visual to emacs and not to libreadline is probably the reason for the request for this feature. Bob
Re: Please accept M-p as well as C-p
Chet Ramey writes: > On 2/13/14 11:29 AM, Andreas Schwab wrote: > >> AIUI there is no readline command the moves >> vertically within the commandline (in readline a line always includes >> any embedded newlines). > > That's true. How should such a command work? Move point forward and > backward by a multiple of the screenwidth? It should work like previous-line/next-line in Emacs: move over the previous/next newline and then forward to the same column as before. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Please accept M-p as well as C-p
On 2/13/14 11:29 AM, Andreas Schwab wrote: > AIUI there is no readline command the moves > vertically within the commandline (in readline a line always includes > any embedded newlines). That's true. How should such a command work? Move point forward and backward by a multiple of the screenwidth? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Please accept M-p as well as C-p
Chet Ramey writes: > My point is that before making it the default, which ends up being > difficult to change, we try to get some data on whether or not that > would be the right default binding. Maybe people who want that binding > could do it using the existing mechanisms and see how it works. There should at least be an easier way to move between lines of multiline commands. AIUI there is no readline command the moves vertically within the commandline (in readline a line always includes any embedded newlines). Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Please accept M-p as well as C-p
On 2/13/14 10:20 AM, Ed Avis wrote: > Thanks for your reply. I don't mean people running bash inside Emacs. > I just mean that when running bash standalone, you use C-p to go backwards > in the history, but when running Emacs standalone, you use Alt-p. Sure, I understand. I also argue that the two programs use different mental models. > Since currently Alt-p doesn't do anything in bash, it could usefully be bound > to previous-history, so that those who flip back and forth between these > two GNU programs could keep using the same key sequence. My point is that before making it the default, which ends up being difficult to change, we try to get some data on whether or not that would be the right default binding. Maybe people who want that binding could do it using the existing mechanisms and see how it works. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
RE: Please accept M-p as well as C-p
Thanks for your reply. I don't mean people running bash inside Emacs. I just mean that when running bash standalone, you use C-p to go backwards in the history, but when running Emacs standalone, you use Alt-p. Since currently Alt-p doesn't do anything in bash, it could usefully be bound to previous-history, so that those who flip back and forth between these two GNU programs could keep using the same key sequence. -- Ed Avis __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Please accept M-p as well as C-p
On 2/13/14 6:35 AM, Ed Avis wrote: > Bash accepts the Emacs keybinding C-p to go back in the history, and C-n to > go forward. > But most of the time in Emacs (when using its minibuffer) the keys you use > are Meta-p > and Meta-n, or on a modern PC keyboard Alt-p and Alt-n. I am not convinced that Alt-p and Alt-n are any more widely used than C-p and C-n, but in any event, it's easy to bind whatever key sequence those key combinations produce to the same editing functions as C-p and C-n. I would further argue that the number of people using an emacs minibuffer to run their shell commands is a small fraction of the total number of bash users. The folks doing that are more than capable of adding a key binding or two. > Currently entering M-p at the bash prompt gives some control characters. Because that key sequence is unbound. Take the key sequence that you see and bind it to previous-history, e.g., "\e[A":previous-history (where \e is ESC, or meta) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Please accept M-p as well as C-p
Bash accepts the Emacs keybinding C-p to go back in the history, and C-n to go forward. But most of the time in Emacs (when using its minibuffer) the keys you use are Meta-p and Meta-n, or on a modern PC keyboard Alt-p and Alt-n. Currently entering M-p at the bash prompt gives some control characters. It could more usefully go back in the history instead. Then if you flip between GNU emacs and GNU bash you wouldn't keep typing the wrong thing. -- Ed Avis __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Please accept M-p as well as C-p
On Thu, Feb 13, 2014 at 1:35 PM, Ed Avis wrote: > Bash accepts the Emacs keybinding C-p to go back in the history, and C-n > to go forward. > But most of the time in Emacs (when using its minibuffer) the keys you use > are Meta-p > and Meta-n, or on a modern PC keyboard Alt-p and Alt-n. > > Currently entering M-p at the bash prompt gives some control characters. > It could more usefully go back in the history instead. Then if you flip > between GNU > emacs and GNU bash you wouldn't keep typing the wrong thing. > > -- > Ed Avis > > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __ > > You can add in your ~/.inputrc "\ep": previous-history "\en": next-history
