On 10/9/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > On 10/5/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > On 10/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Multiline editing rocks. Here are some thoughts. > > > > > > The ellipsis (…) at the start and end of lines is cool and makes clear > > > that the line was wrapped. But it also complicates pasting commands > > > into an editor, as you have to delete all the ellipses. Granted, > > > pasting would require re-formatting anyway if a word or string is > > > continued on a new line. But when indentation is implemented, wrapped > > > words or strings should not be indented, only commands starting on the > > > new line. > > > > I disagree. As you note, you have to edit the commands regardless of > > the ellipsis to remove the additional line breaks. The ellipsis mean > > that can quickly tell what line breaks should be removed, and if you > > do a lot of pasting, you can define a command to remove all instances > > of '\u2026\n *\u2026' to automate the task. > > > > Also, though I just noticed that ^K is currently broken (kills to end > > of command, not end of line), using the fish clipboard integration > > should be a much simpler way of copying and pasting between > > applications. > > > > That said, I don't know how to best mix indentation and wrapping yet, > > but I suspect that your suggestion is a good one, since it makes > > clearer the distinction between line breaks and wrapped lines. > > > > > > > > Also, ellipsis may make editing a little confusing, because it looks > > > like an ordinary character, but actually you can't delete it. Would > > > it be better without ellipses? If they stay, can they be color of > > > comments or something? > > > > Yes, coloring them makes sense. Will do. > > > > > > > > Perhaps it would be better to ignore multiple newlines, as they take > > > too much space. For example, > > > > > > for x in 1 2 3 > > > echo hello > > > > > > end > > > > > > Once entered, a command with an empty line takes terminal space every > > > time you browse the history. And I don't think a need to use empty > > > lines arises amlost ever. And if it really does, you can use a line > > > with an empty comment instead. So the rationale is similar to that > > > for disapplowing re-printing the prompt after an empty line. > > > > Fish allows you to have newlines insed quotes, for example the > > following is perfectly valid fish code, though the multiline reader > > doesn't know it yet (works in a script): > > > > printf " > > GET foo.html HTTP/1.1 > > some-server.com > > > > " | whatever > [...] > > Rght. I was talking about things other than strings. Fish knows a > string when it sees one.
I really don't want the history loader to understand shellscript. Aside from code interdependency and other 'beauty'-issues, it would also mean that the 'read' builtin would be broken, since it uses the same code, but 'read' is for reading general purpose text, not shellscript. Also parsing shellscript to determine where blocks end would mean that you can't insert unfinished commands into the history, as discussed before. (Though I will note that you don't like that ferature, so this is not a big problem for you) Lastly, this would make the history file format very fragile. A single bug or clumsy user edit could make fish unable to parse the remainder of the file. File formats should be simple and robust. > > > Also, if the user entered a command with an empty line, s/he probably > > had some reason for doing it (Possibly to group the code into logical > > segments, or to create nice ASCII art to beautify the history browsing > > experience, both of which are valid use cases), and hence the computer > > should not second guess the user. > > In my experience, the reason is usually a nervous twitch. As with the > empty command line, people have a habit of hitting Enter while > composing. They don't think about the fact that their history would > be more usable without it, but it would be. To say that the user > should always have control is to reject auto-indentation in editors, > > Other times it's a slip of the hand. So users have to be careful not > to hit the key. If Enter can only make one consecutive newline > (outside strings), the system will feel more stable (less fragile). > > ASCII art works with comments. We are trying to make a shell that is > easy to use for normal use. > You have to weigh the valid use cases against the benefits gained from disallowing something. In this case I see the benefit as very small, since as per my reasoning above, I don't think it helps you implement a sane history file format. > > > > (Unfortunately, Axel must not have liked this feature because he did > > > away with it; I really liked it.) > > > > I liked it too, though not passionately. There was a long discussion > > (should be in the mailing list archives) and most people felt the > > other way. I'm way to keen on listening to other people to be a good > > dictator. :( > > With me it was fiery love that burned. I can do the dictating on your > behalf, if that would help... I don't know if I should be happy or afraid. But by all means, feel free to speak your mind, as long as you agree with me. >:-P -- Axel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
