On 10/30/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > On Mon, Oct 30, 2006 at 04:44:45PM +0100, Axel Liljencrantz wrote: > > Not sure that's a good idea. For example, when you are searching the > > history, if you come across a multiline entry, you will be stuck. > > not really. > you only have to hit the arrow a few more times to get to the next > entry.
I have used it on other systems, (Matlab?) and it is very annoying. To bring up a 6-line command that was executed 5 commands ago, you have to press the arrow 30 times, and either count or scrutinize every time whether this is the line you want. > the current way is verry annoying, it makes me lose work, because i keep > forgetting that i can not switch lines in multiline mode. > i start writing, then i want to go back a line, and then oops, and my > half written command is gone. bad. > > it would not be so bad if the half written command did not get lost. Huh? It is not lost, as far as I can see. Start typing, hit UpArrow several times, hit DownArrow until the end of the history. You have the command you started typing. > and maybe instead of the arrow keys some other keys can be provided to > switch lines. You mean move to the next or previous line within the same command? Control+UpArrow and +DownArrow would parallel Control+LeftArrow and +RightArrow which by default move by one word. But we are approaching the state of too many key combinations to remember, so we should unify functionality whenever possible. You can make UpArrow move the cursor to the previous line of the command unless it is already at the first line, in which case search the history. But then you might have to hit UpArrow many times to search; and you would have to pay attention to what mode (line) you are on when editing. > in that same area: ctrl-a and ctrl-e should only move within one line. > and essentially, all the editing features of a single line command > should be available within a line of a multiline command. And how do I move to the start of the command? > just today i wanted to build a look and within it reuse a command that i > had used before. being able to activate a search at that point would > have been ideal. I am working on a proposal that may let you do that without having to explicitly search. > and, while i am at it: <enter> should not execute the command unless you > are at the end. otherwise it is not possible to add more lines to an old > command without first going to the end, to remove something to make sure > the command is incomplete, because the enter will run the command if it > is complete. I think you mean <Enter> should not execute the command unless the cursor is at the end of the command. Maybe so, not sure. The tradeoff is obvious -- it makes it harder to actually execute the command, which is a much more common operation than indenting. You can move the cursor to where you want to indent, cut the line and press <Enter> then. I would prefer if the user did not have to worry about indentation. If the command gets too long to fit on one line, Fish should indent it automatically. A Pascal editor for the Mac which I used about 10 years ago worked like that. It was wonderful! You did not have to worry about formatting, only about the content. But I know some people who have never tried it will complain on religious grounds. > all arguments about modality aside: > multiline editing already IS a different mode. How? We should change that. It should not be. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
