I've incorporate the changes discussed above and a couple of others.

  o Colorized the output (see below).

  o Use column instead of ls for listing browsers that were tried.
    Thanks Philip.

  o Error out if we can't find the topic/command the user entered.
    Also print out brief instructions on using tab completion so
    we can use the mistake as a teaching moment:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Help Error: Could not find a topic or command called: xxx

Help info:
You can see a list of help topics and built-in commands by typing help
followed by a space and the <tab> key:

    help <tab>

Or type help followed by a space and a letter then the <tab> key to see
topics and built-ins that start with that letter.  For example, type:

    help s<tab>

to see topics and commands that start with the letter s.

For more details type: help completion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


  o Added a brief message before we try to print out a man page:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    
No HTML help available for "$cmd" but it is a valid command
on this system.  Looking for a manual page via "man $cmd" ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


  o The browser selection message deals with $CONSOLE_BROWSER
    as well as $BROWSER.

  o Added a few more instructions on setting the $BROWSER variable.

  o Made the major comments more visible so it is easier to follow
    the flow by just reading the comments.


About the colorized output
--------------------------
I used existing $fish_color_* colors instead of hard coding
colors or making up my own $fish_color_* variables.  I figured
users would need to make sure these colors show up on the
background of their terminal so I'm not creating extra work.  The
downside is that changing colors will now have unexpected side
effects on the output of the help command.  I think the colors
make the output more clear but I'm uneasy about hijacking colors
that were meant for other things.

Commands are colored with with $fish_color_commands and "Help
Error" is colored with $fish_color_error. These both seem
appropriate.  I use $fish_color_quote for variables and command
parameters while $fish_color_escape is used to hightlighting
"<tab>" which seems not too unreasonable.  Finally, $fish_color_match
is used to color both "Help Warning" and "Help info" which are pretty
unrelated.  I use the color "normal" (instead of $fish_color_normal)
for normal text.

Other alternatives include defining all my own color variables and
then having defaults in help.fish such as:

    if test -z "$fish_help_color_xxx"
        set fish_help_color_xxx (set_color red)
    end

Or I could just add a few new variables (with defaults) such as
$fish_color_warning and $fish_color_info.  I'm open to suggestions.

Overall, I think the new help.fish is a big improvement over the version
that came with fish-1.23.1.  It should work more often and do a better
job of letting the user know what is going on.  I think it is a good
mini-introduction to fish.  Ideally, new users will be glad they
followed the suggestion in fish_greeting to:

   Type help for instructions on how to use fish.


Peace, James

Attachment: help.fish
Description: Binary data

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Fish-users mailing list
Fish-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fish-users

Reply via email to