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. On Thu, Oct 9, 2008 at 7:55 PM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: >> On Thu, Oct 9, 2008 at 5:39 AM, Suraj N. Kurapati <[EMAIL PROTECTED]> wrote: >> As was already discussed at least once, if we want to automatically >> offer hints to users from other shells, we want a system orthogonal to >> the normal parser. For starters, triggering hints by simple string >> search against the command should be enough (if needed we can extend >> it to [...] > * If the command parsing/execution fails, any matching hints should be > shown of course. > * Normally, hints should be displayed transiently while typing and then go > away. > * An easy way to say "don't show this hint again" might be useful. > And perhaps otherwise inspect/manage hint status. Those are great ideas, and I have submitted to the list a detailed design for the transient messages. But it requires lots of programming. I think it's better to avoid allowing the user to control the hints, though. > If properly done, this could become a built-in learn-as-you-go tutorial. > > BTW, do we want an interactive tutorial for fish? Perhaps encouraging > people to spend several minutes early on to learn the basics of fish > is the most useful thing to do. > > I'm ready to write one, it there is agreement that it's a good idea. > I think I'd start with targeting it at complete shell newbies. Later, > I might add a "which shells are you familiar with" question at the > start which would add the relevant transition notes. 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. ------------------------------------------------------------------------- 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
