Do not tombstone a function when it is evicted normally from the LRU cache.
This broke changing `fish_function_path`, since that would evict all nodes,
resulting in accidental tombstones, which caused autoloaded functions to
never be reloaded.
See #213.
In 73f344f41b, we allowed autoloaded functions to be deleted.
For some reason, funcsave immediately deletes the function it
creates. This previously did very little, since the function would
immediately be re-autoloaded, but with the fix for 73f344f41b
the function gets tombstoned. So the effect is that funcsave
makes the function disappear! This simply removes the erase call,
which dates back to fish 1.x.
As suggested by @ridiculousfish, when removing autoloaded functions, add them
to a tombstones set. These functions will never be autoloaded again in the
current shell, not even when the timestamp changes.
Tested as per comment 1 of #1033. `~/.config/fish/functions/ls.fish` contains
the function definition. `function -e ls` removes the redefined `ls` (and
reverts back to the built-in command). `touch .../ls.fish` does not cause the
function to be reloaded.
Works also if tok->show_comments (for highlighting and auto completion) and
with multi-line comments:
function my_function
echo "hello" | \
#remove 'l'
#and more
tr -d 'l'
end
$ my_function
heo
Fixes#983
It seems that `ul` can't handle the escape sequences for bold text that `nroff` generates on my system. Fixed by either removing `| ul`, or adding `-c` to the `nroff` command.
Needs testing for old (OSX?) versions of nroff.
Fixes a bug where generating a lot of autoloaded functions from
syntax highlighting would result in evicting nodes on background threads,
resulting in a thread error.
Fixes#1989
Unfortunately, list-unit-files doesn't understand --state=loaded
This needs a new function to explicitly use list-units
This reverts commit 9f521b7694.
e340baf6cc introduced a bug where fish would not exit from job_continue
when receiving a signal like SIGHUP. This means that it would not in turn
deliver SIGHUP to its children, who would therefore never exit. Those
children may attempt to write to stdout, in which case they would receive
EIO; this can cause other weird issues, like telnet using 100% CPU.
Fixes#1958
