In the fish AST, each node falls into one of three "categories":
1. A branch: contains child nodes
2. A leaf: no child nodes, contains a source range
3. A list: a sequence of child nodes and nothing more
Prior to this commit the category was explicit in the code for each Node type;
make it instead derived from the node's type. This continues to shrink our
macros.
No functional change expected.
Commit f38646593c (Allow `export` to set colon-separated `PATH`, `CDPATH`
and `MANPATH`., 2017-02-10)
did something very weird for «export PATH=foo».
It essentially does
set -gx PATH (string replace -- "$PATH" (string join ":" -- $PATH) foo)
which makes no sense. It should set PATH to "foo", no need to involve the
existing value of $PATH.
Additionally, the string split / string join dance is unnecessary. Nowadays,
builtin set already handles path variables as is needed here, so get rid of
this special case.
Fixes#11434
Specifically, the width and precision format specifiers are interpreted as
referring to the width of the grapheme clusters rather than the byte count of
the string. Note that grapheme clusters can differ in width.
If a precision is specified for a string, meaning its "maximum number of
characters", we consider this to limit the width displayed.
If there is a grapheme cluster whose width is greater than 1,
it might not be possible to get precisely the desired width.
In such cases, this last grapheme cluster is excluded from the output.
Note that the definitions used here are not consistent with the `string length`
builtin at the moment, but this has already been the case.
This should prevent occurrences of the search string from being found in other
locations (e.g. in a comment).
The whole approach of string extraction from Rust sources is sketchy,
but this at least prevents producing garbage when the content of a string
appears somewhere else unquoted.
The previous version generates files which do not preserve the line number from
the original fish script file, resulting in translation not working.
The new approach is quite ugly, and might have some issues,
but at least it seems to work in some cases.
Extracting explicit and implicit messages works essentially the same way, which
is also reflected in the code being identical, except for the regex.
Extract the duplicated code into a function.
- Apply lint config to entire workspace
- Inherit workspace config for fish-printf
- Allow stdlib printing in fish-printf tests
The current problem which is addressed by this is that warnings about C-String
literals are generated by clippy for code in fish-printf. These literals are not
available with the current MSRV 1.70, but previously the MSRV setting was not
inherited by fish-printf, causing the warning to appear.
Commit b00899179f (Don't indent multi-line quoted strings; do indent inside
(), 2024-04-28) changed how we compute indents for string tokens with command
substitutions:
echo "begin
not indented
end $(
begin
indented
end)"(
begin
indented
end
)
For the leading quoted part of the string, we compute indentation only for
the first character (the opening quote), see 4c43819d32 (Fix crash indenting
quoted suffix after command substitution, 2024-09-28).
The command substitutions, we do indent as usual.
To implement the above, we need to separate quoted from non-quoted
parts. This logic crashes when indent_string_part() is wrongly passed
is_double_quoted=true.
This is because, given the string "$()"$(), parse_util_locate_cmdsub calls
quote_end() at index 4 (the second quote). This is wrong because that function
should only be called at opening quotes; this is a closing quote. The opening
quote is virtual here. Hack around this.
Fixes#11444
As reported in
https://matrix.to/#/!YLTeaulxSDauOOxBoR:matrix.org/$n20_uqiMqatEQcPG79Ca0c2_YvHBHTr-yCVXTEuze_Y
commit f5fac096c0 (Don't move cursor in delete-char, 2017-04-19) fixed the
behavior of Vi mode keys "delete" and "x" when the cursor is at the end of
the buffer, and commit d51f669647 (Vi mode: avoid placing cursor beyond
last character, 2024-02-14) generalized this fix.
This means that the delete-specific fix is no longer necessary. Remove it.
Note that if the cursor is at end of a line but not the last line, the
behavior of "delete" in Vi mode is still wrong. It should stay on the line.
This is a weird confusion between the "end" and "terminate" token
types.
"end" is the end of the "line" - a newline or ";".
"terminate" is the end of the "file" - like pressing newline
interactively or having the file end.
So this would count things like `if` and `switch` as a "help"
invocation even if followed by a newline, e.g.
```fish
if; echo foo
```
and
```fish
switch
case foo
```
The result of that was that a naked "if" in a script file isn't an
error, but doesn't start a block either, so if you complete the block
it would count the "end" as superfluous, which sends you on a bit of a
hunt to figure out where the block start is missing.
This script was broken by the changes to profiling output in
9d904e1113.
The new version works with both the old and new profiling output, even when
mixed. The script output has been adjusted to match the new profiling style
better.
This also adds basic error handling for situations where the script is invoked
incorrectly and makes the file executable.
