Move away from fish_greeting for initialization

[sagebind]

Using fish_greeting to define functions and run initialization code for themes should be considered unreliable and breaks in the following cases:

• User switches themes during the middle of a terminal session. The shell is not reloaded, and so fish_greeting is not executed.
• User has a custom fish_greeting variable or function, overriding the theme's default greeting. Again, the theme's fish_greeting is not executed.

The recommended approach is to lazy-load defaults using set -q ...; or set -g ... and to place functions in individual files in a functions directory.

See the discussion in https://github.com/oh-my-fish/oh-my-fish/issues/483.

[pantuza]

@sagebind, thank you for the advise.

Some notes: fishbone greetings file do not create helper functions to other files. The functions inside that file are used only and exclusively in that file.

Through the following steps you can see that, for fishbone, there is no problem in switching or overriding greetings functions/file:

$> omf theme fishbone # Do not breaks. Also do not prints our greetings message
$> fish_greeting # Prints our message
$> omf reload # Prints our message 

A friend of mine uses fishbone, and customizes his greetings function because he doesn't like the default one.

Since we keep fish_greeting.fish self contained and do not 'export' its functions to a global scope, I think it is not necessary to refactor it.

Based on that, I would like to close this issue. What do you think? Is there any other consideration?

Thank you for the issue.

[sagebind]

@pantuza Yep, looks like I misread how fish_greeting.fish helper functions were being used. (I basically grepped for themes with functions other than fish_greeting in fish_greeting.fish and opened the above issue on each matching project.)

Everything looks good, closing this issue.