On 8/25/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > On Fri, Aug 25, 2006 at 06:04:35PM +0200, Axel Liljencrantz wrote: > > I am quite happy with this addition to the syntax. The only drawback I > > can see with it is that it only works in interactive mode. You still > > have to do a full begin/end in non-interactive mode. > > hmm, that's not really good. > > lines should be lines either way. > like sourcing something, should be identical in behaviour to pasting the > lines into the shell with the mouse. > > consider writing some instructions somewhere: > to do x, just type the following commands... > > now the user learned about scripts somewhere, and figures: > hey i do this so often, let me make a script out of it. > > and then the script will not work, because interactive and script > behaviour is different. > > or the other way around: > someone finds a script, and thinks, ah, i just need this once, why bother > putting it in a file? i'll just copy and paste it into the shell.
I hadn't thought of it that way. Unfortunatly, there is no way around this problem that I can see. So one has to weigh the benefit against the drawbacks. Hard call. > > well, currently that does not work because blocks can not span multiple > lines. (and this is not necesarily about multiline editing) > > btw: while we were wondering what good it could be to edit a commandline > in an editor, well, here might actually be a use for it (even if it is > unconvenient): start an editor, paste commands, exit, and have the > pasted command in the commandline, or optionally directly executed. True. But what I meant was that it is a silly default action for a history manipulation command, not that it is always a useless action. > > in general, copying and pasting commands is something that especially > beginners do a lot, and i think that should be easy for them. Absolutely. > > (provisions to catch someone pasting bash code by somehow ignoring any > input as soon as something wrong comes in until there is no more input > for some time (so it can pe concluded that the pasting stopped) would > probably also be helpful) Fish already does quite a lot of cleverness when it comes to keyreading: * If more data is already available after reading a character, it will be read before repainting the screen or redoing syntax highlithing ion order to reduce flicker. This greatly reducxes flicker when pasting text. * Fish checks the timing of the keytstrokes to differentiate between a user pressing the escape key and a terminal escape sequence or the user using a Meta-keybinding. If fish didn't do this, you would need to press escape twice to simulate a single keystroke like you do in many curses-based programs. > > greetings, martin. > -- > cooperative communication with sTeam - caudium, pike, roxen and unix > offering: programming, training and administration - anywhere in the world > -- > pike programmer travelling and working in europe open-steam.org > unix system- bahai.or.at iaeste.(tuwien.ac|or).at > administrator (caudium|gotpike).org is.schon.org > Martin Bähr http://www.iaeste.or.at/~mbaehr/ > -- Axel ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
