On Fri, Oct 10, 2008 at 7:18 AM, Philip Ganchev <[EMAIL PROTECTED]> wrote: > Couldn't the parsing be more sensitive to the possible errors, thus > avoiding a second pass? For example, if '$' is followed by an illegal > character, check which character that is; if it's "!", print an error > message like " > > The '$' character begins a variable name. The character '!', > which directly followed a '$', is not allowed as a part of a variable > name. To access words from the command history, press "Alt+up". > For more information about command history, type "help history". > > If there's a space or no character after the "$", print the message: > > The '$' character begins a variable name. Variable names must be > longer than zero characters. To learn more about variable expansion > in fish, type "help expand-variable". > > And so on. > Actually, your example happens to be a good counter-example. It's "!$", not "$!", so it's not necessarily illegal, and if illegal it'll because the "$" is not followed by anything, so the normal parser won't detect it.
Other examples where a string suggests a user is applying a construct from another shell, but the error it causes is unrelated: "while...; do ...; done" no "do" in path; moreover, you can't even press enter to execute it and see the error until you guess the magic "end" word! "du `find -name '*.c'`" legal in fish, du will print obscure errors that "`find" was not found "ls foo.[ch]" again legal in fish, "file not found" from ls This is why I think the hints should be (a) matched orthogonally from the normal parser, and (b) displayed while editing. (b) is more helpful, and safely tolerates false positives. > Those are great ideas, and I have submitted to the list a detailed > design for the transient messages. But it requires lots of > programming. An orthogonal pass against a set of strings requires less programming than special-casing the existing parser, and allows unskilled people to contribute hints. The transient display of messages will require much programming, but I think is very important. > I think it's better to avoid allowing the user to control the hints, though. > On second thoughts, I tend to agree. > You are free to write one, but I don't think it's a good idea. I > having a tutorial for something makes potential users feel overwhelmed > by the effort required to learn it. If possible, we should make the > use of Fish in itself be an interactive tutorial, as you said. This > is possible even without the complicated modifications you suggested > above. > Hmm, yes, you are probably right. -- Beni Cherniavsky <[EMAIL PROTECTED]> (I read email only on weekends) ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
