A long standing issue is that bindings cannot mix special input functions
and shell commands. For example,
bind x end-of-line "commandline -i x"
silently does nothing. Instead we have to do lift everything to shell commands
bind x "commandline -f end-of-line; commandline -i x"
for no good reason.
Additionally, there is a weird ordering difference between special input
functions and shell commands. Special input functions are pushed into the
the queue whereas shell commands are executed immediately.
This weird ordering means that the above "bind x" still doesn't work as
expected, because "commandline -i" is processed before "end-of-line".
Finally, this is all implemented via weird hack to allow recursive use of
a mutable reference to the reader state.
Fix all of this by processing shell commands the same as both special input
functions and regular chars. Hopefully this doesn't break anything.
Fixes#8186Fixes#10360Closes#9398
Call fish_should_add_to_history to see if a command should be saved
If it returns 0, it will be saved, if it returns anything else, it
will be ephemeral.
It gets the right-trimmed text as the argument.
If it doesn't exist, we do the historical behavior of checking for a
leading space.
That means you can now turn that off by defining a
`fish_should_add_to_history` that just doesn't check it.
documentation based on #9298
Fish functions are great for configuring fish but they don't integrate
seamlessly with the rest of the system. For tasks that can run outside fish,
writing scripts is the natural approach.
To edit my scripts I frequently run
$EDITOR (which my-script)
Would be great to reduce the amount typing for this common case (the names
of editor and scripts are usually short, so that's a lot of typing spent on
the boring part).
Our Alt+o binding opens the file at the cursor in a pager. When the cursor
is in command position, it doesn't do anything (unless the command is actually
a valid file path). Let's make it open the resolved file path in an editor.
In future, we should teach this binding to delegate to "funced" upon seeing
a function instead of a script. I didn't do it yet because funced prints
messages, so it will mess with the commandline rendering if used from
a binding. (The fact that funced encourages overwriting functions that
ship with fish is worrysome. Also I'm not sure why funced doesn't open the
function's source file directly (if not sourced from stdin). Persisting the
function should probably be the default.)
Alternative approach: I think other shells expand "=my-script" to
"/path/to/my-script". That is certainly an option -- if we do that we'd want
to teach fish to complete command names after "=". Since I don't remember
scenarios where I care about the full path of a script beyond opening it in
my editor, I didn't look further into this.
Closes#10266
This is the last remnant of the old percent expansion.
It has the downsides of it, in that it is annoying to combine with
anything:
```fish
echo %self/foo
```
prints "%self/foo", not fish's pid.
We have introduced $fish_pid in 3.0, which is much easier to use -
just like a variable, because it is one.
If you need backwards-compatibility for < 3.0, you can use the
following shim:
```fish
set -q fish_pid
or set -g fish_pid %self
```
So we introduce a feature-flag called "remove-percent-self" to turn it
off.
"%self" will simply not be special, e.g. `echo %self` will print
"%self".
Issue #10194 reports Cobra completions do
set -l args (commandline -opc)
eval $args[1] __complete $args[2..] (commandline -ct | string escape)
The intent behind "eval" is to expand variables and tildes in "$args".
Fair enough. Several of our own completions do the same, see the next commit.
The problem with "commandline -o" + "eval" is that the former already
removes quotes that are relevant for "eval". This becomes a problem if $args
contains quoted () or {}, for example this command will wrongly execute a
command substituion:
git --work-tree='(launch-missiles)' <TAB>
It is possible to escape the string the tokens before running eval, but
then there will be no expansion of variables etc. The problem is that
"commandline -o" only unescapes tokens so they end up in a weird state
somewhere in-between what the user typed and the expanded version.
Remove the need for "eval" by introducing "commandline -x" which expands
things like variables and braces. This enables custom completion scripts to
be aware of shell variables without eval, see the added test for completions
to "make -C $var/some/dir ".
This means that essentially all third party scripts should migrate from
"commandline -o" to "commandline -x". For example
set -l tokens
if commandline -x >/dev/null 2>&1
set tokens (commandline -xpc)
else
set tokens (commandline -opc)
end
Since this is mainly used for completions, the expansion skips command
substitutions. They are passed through as-is (instead of cancelling or
expanding to nothing) to make custom completion scripts work reasonably well
in the common case. Of course there are cases where we would want to expand
command substitutions here, so I'm not sure.
This prefers `-s` to `-v` - we have a *lot* more uses of `command -s`, it's the easier
mnemonic *and* the more compatible-with-fish option.
Also we don't really need the separate section that explains what
these options do *again*.
Update the pydoctheme.css file to add support for print media.
The code was adapted from the existing support for screens that are less than
700px wide, with the following changes:
- Remove the documents and sections index
- Remove the quick search
- Remove dead CSS code
Additionally, add section numbers and ensure that code blocks are never split
across multiple pages.
This can be bound like `bind \cl clear-screen`, and is, by default
In contrast to the current way it doesn't need the external `clear`
command that was always awkward.
Also it will clear the screen and first draw the old prompt to remove
flicker.
Then it will immediately trigger a repaint, so the prompt will be overwritten.
This was the remaining immediately actionable part of #7375.
It's not definitely the last word, but a change here would require a
bigger plan.
Fixes#7375
This used to print all codepoints outside of the ASCII range (i.e.
above 0x80) in \uXXXX or \UYYYYYYYY notation.
That's quite awkward, considering that this is about keys that are
being pressed, and many keyboards have actual symbols for these on
them - I have an "ö" key, so I would like to use `bind ö` and not
`bind \u00F6`. So we go by iswgraph.
On a slightly different note, `\e` was written as `\c[ (or \e)`. I do
not believe anyone really uses `\c[` (the `[` would need to
be escaped!), and it's confusing and unnecessary to even mention that.
This cleans up the CSS, reduces the number of different colors and special settings we use.
It increases contrast so we now pass WCAG AAA (according to chromium), and switches to css variables for colors to make dark mode simpler to implement.
During development, for a while `path change-extension` would return 0
when it found an extension to change.
This was later changed to returning 0 if there are any path arguments.
Neither of which is *super* useful, I admit, but we've picked one and
the docs shouldn't contradict it.
This was accidentally changed in 3.2.0, when type was made a builtin.
Since it's been 4 releases and nobody has noticed, rather than
breaking things again let's leave it as it is, especially because the
option is named "--no-functions", not "--no-functions-or-builtins".
After accidentally running a command that includes a pasted password, I want
to delete command from history. Today we need to recall or type (part of)
that command and type "history delete". Let's maybe add a shortcut to do
this from the history pager.
The current shortcut is Shift+Delete. I don't think that's very discoverable,
maybe we should use Delete instead (but only if the cursor is at the end of
the commandline, otherwise delete a char).
Closes#9454
* docs: Add "Writing your own prompt" doc
* Remove a space from the "output"
* some teensy adjustments
* Address feedback
* envvar one more PWD
* More html warning
This was always extremely weasel-wordy and I have no idea which one
here is a good choice.
OMF is basically inactive at this point, so we might be doing people a
disservice by linking to it.
