If you have a prompt preceded by a new line, you'll get a line full of spaces instead of an empty line above your prompt. This doesn't make a difference in normal usage, but copying and pasting your terminal log becomes a pain. This commit clears that line, making it an actual empty line.
The random builtin command may or may not produce values with a truly
random distribution. So make the documentation reflect that reality. Also,
make the command consistent with similar shells (e.g., bash, zsh) which
produce a range of [0..32767].
Resolves issue #1272.
Before this change, `fish ./test.fish` would fully resolve the
relative paths and symlinks of test.fish, as reported by `status -f`.
However `source` would not. With this change, both cases return relative
paths. `realpath` may be used by scripts to resolve them.
Fixes#2643
This patch is currently floated from the NixOS side as part of
https://github.com/NixOS/nixpkgs/pull/12000, but prior versions of the
hook ignore anything but the first argument anyway, so this is
backwards-compatible.
* Add a note to the `--wrap` docs saying that wrapping only works when
specifying completions for commands, not for paths.
* Add more info about how `--arguments` is handled.
* Indicate which options can be repeated in the usage lines.
* Reorder the options in usage slightly to group better.
* Reorder the option descriptions to match the order as seen in usage.
* Update some of the option descriptions.
* Fix the documentation for -C to show that it must be `-CSTRING`
instead of `-C STRING`.
* Document the behavior of `-C` with no argument.
* Tweak some of the explanatory text after the option list.
* Delete `--authoritative` and `--unauthoritative` from the
documentation entirely. Those options appear to not actually do
anything in the new parser.
This skips the weird dance where we'd define a simple handler and then
later overwrite with a fancier one, once the first event came in.
It turns out that isn't necessary, as it doesn't actually improve
startup speed because the checks needed to define fancier handlers are fast.
In case we are non-interactive, still define the simple handler, and
keep the default handler for users to switch to.
My PR #2578 had the unexpected side-effect of altering the tty modes of
commands run via "fish -c command" or "fish scriptname". This change fixes
that; albeit incompletely. The correct solution is to unconditionally set
shell tty modes if stdin is attached to a tty and restore the appropriate
modes whenever an external command is run -- regardless of the path used to
run the external command. The proper fix should be done as part of addressing
issues #2315 and #1041.
Resolves issue #2619
Increase the delay between seeing an escape character and giving up on
whether additional characters that match a key binding are seen. I'm
setting the value to 500 ms to match the readline library. We don't need
such a large window for sequences transmitted by a terminal (even over ssh
where network delays can be a problem). However, we can't expect humans to
reliably press the escape key followed by another key with an inter-char
delay of less than ~250 ms based on my testing and research. A value of
500 ms provides a nice experience even for people using "fish_vi_mode"
bindings as a half second to switch from insert to normal mode is still
fast enough that most people won't even notice.
Resolves#1356
While investigating issue #2619 my first thought was that the problem
had something to do with the "is_interactive_session" global variable.
That preliminary conclusion appears to be wrong (i.e., the problem
lies elsewhere). However, that hypothesis caused me to look at function
"fish_parse_opt" and other mentions of "is_interactive_session".
I decided to take the opportunity to simplify and improve the style of
"fish_parse_opt" since I just spent an hour reviewing the code that
references "is_interactive_session". For example, the "has_cmd" variable
isn't really needed. And there is inconsistent whitespace not to mention
confusion about bool's versus int's and zero versus NULL.
Rather than returning a list of productions and an index,
return the relevant production directly from the rule function.
Also introduce a tag value (replacing production_idx) which tracks
information like command decorations, etc. with more clarity.
That's probably the part where commit hashes are most used, we can add
the other subcommands later.
This generates a _lot_ of options, so hooking it up everywhere would be
unwise, though our pager helps quite nicely with filtering - typing
"Branch" will filter out the commits, and typing other things will
filter the subjects, which is quite cool.
