It's reasonable since this is only checking to see that the history file
contains the expected format and if it's corrupted but we at least got what we
expect to be the correct key/value pairs, then that's all we can do.
Of course the real motivation is to speed up this very hot function in any way
possible!
On the completions and history thread, the parent function
HistoryFileContents::decode_item() is responsible for ~60% of the CPU time, and
extract_prefix_and_unescape_yaml() alone comprising 14% (of the total).
This change removes allocations in the event that the history item is either
fully or partially plain yaml with no escapes to begin with, and brings down the
execution time of this function to only 7% of the total execution time.
The bulk of the remaining time is spent in wcs2string(), which is called
unconditionally and is naturally alloc-heavy.
- Remove duplicated options - we had `-type` 9 times!
- Remove deprecated options and synonyms
- Make descriptions shorter, even removing some - when they're inscrutable they might as well not be there.
Really, 99.8% of these options are of interest to nobody except possibly (a subset of) gcc developers, so it pays to have *less* on your screen that you don't use anyway.
We ignore typed control characters 33a7172ee (Revert to not inserting control
characters from keyboard input, 2024-03-02).
We used to do the same for bracketed paste but that changed in 8bf8b10f6
(Extended & human-friendly keys, 2024-03-30) which made bracketed paste
behave like fish_clipboard_paste; it inserts the exact input (minus leading
whitespace etc). At that time it wasn't clear to me which behavior was the
right one (because of the inconsistency between terminal and bracketed paste).
As reported in
https://matrix.to/#/!YLTeaulxSDauOOxBoR:matrix.org/$PEEOAoyJY-644amIio0CWmq1TkpEDdSy2QnfJdK-dco
trailing tabs in pasted text can be confusing.
There seems to be not real need to insert raw control characters into the
command line, so let's strip them when pasting.
Now the only way to insert a raw control character into the command line is
to recall it from command history. Not sure what the behavior should be for
that case, we can revisit that later. If we get rid of raw control characters
entirely, then we can also delete the new "control pictures" rendering :)
This allows running `set` without triggering any event handlers.
That is useful, for example, if you want to set a variable in an event
handler for that variable - we could do it, for example, in the
fish_user_path or fish_key_bindings handlers.
This is something the `block` builtin was supposed to be for, but it
never really worked because it only allows suppressing the event for
the duration, they would fire later. See #9030.
Because it is possible to abuse this, we only have a long-option so
that people see what is up.
Commit a583fe723 ("commandline -f foo" to skip queue and execute immediately,
2024-04-08) fixed the execution order of some bindings but was partially
backed out in 5ba21cd29 (Send repaint requests through the input queue again,
2024-04-19) because repainting outside toplevel yields surprising results
(wrong $status etc).
Transient prompts wants to first repaint and then execute some more readline
commands, all within a single binding. This was broken by the second commit
because that one defers the repaint until after the binding has finished.
Work around this problem by deferring input events again while a readline
event was queued. This is closest to the historical behavior.
The implementation feels hacky; we might find odd situations.
For example,
commandline -f repaint end-of-line
set token (commandline -t)
sets the wrong token.
Probably not a very important case. We could throw an error or make it work
by letting "commandline -t" drain the input queue.
That seems too complicated, better change repaints to not use the input queue
(and fake $status etc). Let's try to do that in future.
Closes#10492
[w]open_dir does not pass O_CREAT, so the mode argument to open is never used.
also, O_CREAT | O_DIRECTORY could not be used (portably) to create a directory.
(on POSIX does not specify what should happen, on Linux it is EINVAL.)
This new feature in rsconf 0.2.0 resolves the compile-time warnings we get under
rustc 1.80+ about unrecognized cfg names by informing cargo of all valid cfg
names/values even when the cfg in question isn't enabled.
rustc 1.80 now complains about features not declared in Cargo.toml and cfg
keys/values not declared by build.rs to protect against typos or misuse (you
think you're using the right condition but you're not). See
rust-lang/cargo#10554 and rust-lang/rust#82450.
(We're not actually using TSAN under CI at this time, but I do want to re-enable
it at some point — especially if we get multithreaded execution going — using
the rust-native TSAN configuration.)
I'll be updating the `rsconf` crate and patching `build.rs` accordingly to also
handle the warnings about unknown cfg values, but tsan is a feature and not a
cfg and these can be dealt with in `Cargo.toml` directly.
We were passing a slice (and not a vec) to `CString::new()`, meaning it would
allocate a new Vec internally to hold the bytes.
Also document that the resulting CString will be silently truncated at the first
interior NUL.
The function was repeatedly calling `s.char_at(n)` which is O(1) only for UTF-32
strings (so not a problem at the moment). But it was also calling `hex_digit(n)`
twice for each `n` in the 3-digit case, causing unnecessary repeated parsing of
individual characters into their radix-16 numeric equivalents, which could be
avoided just by reusing the already calculated result.
CARGO_NET_GIT_FETCH_WITH_CLI uses the `git` executable instead of the rust
git2 crate/lib, which speeds things up and is known to resolve some issues
fetching the registry or individual crates.
This is to work around a specific issue with git-resident Cargo.toml
dependencies (e.g. terminfo) that keep randomly failing to download under macOS
CI.
