2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell synced 2025-02-15 13:38:38 +00:00
Commit graph

4617 commits

Author SHA1 Message Date
ridiculousfish
3eae0a9b6a clang-format all C++ files
This mostly re-sorts headers that got desorted after the IWYU
application in 14d2a6d8ff.
2022-08-21 15:02:19 -07:00
ridiculousfish
c260c1259e Stop exporting kDefaultPath
This is used only within path.cpp; make it a static.
2022-08-21 14:43:28 -07:00
ridiculousfish
1d0c22b390 Remove unused 'vars' variable in path_get_path_core
This became unused deliberately in 40733ca25b.
2022-08-21 14:42:59 -07:00
Aaron Gyes
8b14ac4a9c don't even set up a fish_use_posix_spawn handler if unsupported
Also remove extern 'C' { gnu_get_libc_version }, it's no longer
used. allow_use_posix_spawn is determined true or false at
compile time.
2022-08-21 14:19:34 -07:00
Aaron Gyes
1198a05299 assert: identify the hot path
Does result in code that branches a little differently.
2022-08-21 05:55:34 -07:00
Aaron Gyes
14d2a6d8ff IWYU-guided #include rejiggering.
Let's hope this doesn't causes build failures for e.g. musl: I just
know it's good on macOS and our Linux CI.

It's been a long time.

One fix this brings, is I discovered we #include assert.h or cassert
in a lot of places. If those ever happen to be in a file that doesn't
include common.h, or we are before common.h gets included, we're
unawaringly working with the system 'assert' macro again, which
may get disabled for debug builds or at least has different
behavior on crash. We undef 'assert' and redefine it in common.h.

Those were all eliminated, except in one catch-22 spot for
maybe.h: it can't include common.h. A fix might be to
make a fish_assert.h that *usually* common.h exports.
2022-08-20 23:55:18 -07:00
Fabian Boehm
7988cff6bd Increase the string chunk size to increase performance
This is a *tiny* commit code-wise, but the explanation is a bit
longer.

When I made string read in chunks, I picked a chunk size from bash's
read, under the assumption that they had picked a good one.

It turns out, on the (linux) systems I've tested, that's simply not
true.

My tests show that a bigger chunk size of up to 4096 is better *across
the board*:

- It's better with very large inputs
- It's equal-to-slightly-better with small inputs
- It's equal-to-slightly-better even if we quit early

My test setup:

0. Create various fish builds with various sizes for
STRING_CHUNK_SIZE, name them "fish-$CHUNKSIZE".
1. Download the npm package names from
https://github.com/nice-registry/all-the-package-names/blob/master/names.json (I
used commit 87451ea77562a0b1b32550124e3ab4a657bf166c, so it's 46.8MB)
2. Extract the names so we get a line-based version:

```fish
jq '.[]' names.json | string trim -c '"' >/tmp/all
```

3. Create various sizes of random extracts:

```fish
for f in 10000 1000 500 50
    shuf /tmp/all | head -n $f > /tmp/$f
end
```

(the idea here is to defeat any form of pattern in the input).

4. Run benchmarks:

hyperfine -w 3 ./fish-{128,512,1024,2048,4096}"
    -c 'for i in (seq 1000)
            string match -re foot < $f
        end; true'"

(reduce the seq size for the larger files so you don't have to wait
for hours - the idea here is to have some time running string and not
just fish startup time)

This shows results pretty much like

```
Summary
'./fish-2048     -c 'for i in (seq 1000)
          string match -re foot < /tmp/500
      end; true'' ran
  1.01 ± 0.02 times faster than './fish-4096     -c 'for i in (seq 1000)
          string match -re foot < /tmp/500
      end; true''
  1.02 ± 0.03 times faster than './fish-1024     -c 'for i in (seq 1000)
          string match -re foot < /tmp/500
      end; true''
  1.08 ± 0.03 times faster than './fish-512     -c 'for i in (seq 1000)
          string match -re foot < /tmp/500
      end; true''
  1.47 ± 0.07 times faster than './fish-128     -c 'for i in (seq 1000)
          string match -re foot < /tmp/500
      end; true''
```

So we see that up to 1024 there's a difference, and after that the
returns are marginal. So we stick with 1024 because of the memory
trade-off.

----

Fun extra:

Comparisons with `grep` (GNU grep 3.7) are *weird*. Because you both
get

```
'./fish-4096 -c 'for i in (seq 100); string match -re foot < /tmp/500; end; true'' ran
11.65 ± 0.23 times faster than 'fish -c 'for i in (seq 100); command grep foot /tmp/500; end''
```

and

```
'fish -c 'for i in (seq 2); command grep foot /tmp/all; end'' ran
66.34 ± 3.00 times faster than './fish-4096 -c 'for i in (seq 2);
string match -re foot < /tmp/all; end; true''
100.05 ± 4.31 times faster than './fish-128 -c 'for i in (seq 2);
string match -re foot < /tmp/all; end; true''
```

Basically, if you *can* give grep a lot of work at once (~40MB in this
case), it'll churn through it like butter. But if you have to call it
a lot, string beats it by virtue of cheating.
2022-08-15 20:16:12 +02:00
Fabian Boehm
40733ca25b If relative path was used, use it
This was inadvertently changed in
ed78fd2a5f

Fixes 
2022-08-15 20:01:50 +02:00
Aaron Gyes
2b2f772790 clarify "…variable is shadowed by the global variable of the same name"
Rephrase this to more explicitly indicate that the uvar actually
was successfully set. I believe the prior phrasing can leave some
ambiguity as far as wether set just failed with an error, whether it
has done anything or not.
2022-08-14 16:16:38 -07:00
Aaron Gyes
aacc71e585 builtin set: make error messages more consistent.
Now uses the same macro other builtins use for a missing -e arg,
and the error message show the short or long option as it was used.

e.g. before
    $ set -e
    set: Erase needs a variable name

after
    $ set --erase
    set: --erase: option requires an argument
    $ set -e
    set: -e: option requires an argument
2022-08-14 15:34:58 -07:00
ridiculousfish
2a0e0d6721 Remove the intern'd strings component
Intern'd strings were intended to be "shared" to reduce memory usage but
this optimization doesn't carry its weight. Remove it. No functional
change expected.
2022-08-13 12:51:36 -07:00
ridiculousfish
082f074bb1 Switch filenames from intern'd strings to shared_ptr
We store filenames in function definitions to indicate where the
function comes from. Previously these were intern'd strings. Switch them
to a shared_ptr<wcstring>, intending to remove intern'd strings.
2022-08-13 12:51:36 -07:00
Johannes Altmanninger
3dfacf4b39 builtin printf: suppress warnings about unused variables
No functional change.
2022-08-13 21:11:54 +02:00
Johannes Altmanninger
c031e6f193 Highlight shell commands in history pager
This solution is quite hacky. I added a comment that suggests a better
solution, which shouldn't be hard to implement.
2022-08-13 21:11:31 +02:00
Johannes Altmanninger
b64cec1d7e Use Unicode symbols for rendering control characters in pager
The history pager will show multiline commands in single-line cells.
We escape newline characters as \\n but that looks awkward if the next line
starts with a letter. Let's render control characters using their corresponding
symbol from the Control Pictures Unicode block.

This means there is also no need to escape backslashes, which further improves
the history pager - now the rendering has exactly as many backslashes as
the eventual command.

This means that (multiline) commands in the history pager will be rendered
with the same amount of characters as are in the actual command (unless
they contain funny nonprintables).  This makes it easy for the next commit
to highlight multiline commands correctly in the history pager.

The font size for these symbols (for example ␉) is quite small, but that's
okay since for the proposed uses it's not so important that they readable.
The important thing is that the stand out from surrounding text.
2022-08-13 21:11:31 +02:00
Fabian Boehm
5fe43accef Add special error for set -o 2022-08-12 21:28:11 +02:00
Fabian Boehm
8d7416048d Don't skip caret for some errors
This checked specifically for "| and" and "a=b" and then just gave the
error without a caret at all.

E.g. for a /tmp/broken.fish that contains

```fish
echo foo

echo foo | and cat
```

This would print:

```
/tmp/broken.fish (line 3): The 'and' command can not be used in a pipeline
warning: Error while reading file /tmp/broken.fish
```

without any indication other than the line number as to the location
of the error.

Now we do

```
/tmp/broken.fish (line 3): The 'and' command can not be used in a pipeline
echo foo | and cat
           ^~^
warning: Error while reading file /tmp/broken.fish
```

Another nice one:

```
fish --no-config -c 'echo notprinted; echo foo; a=b'
```

failed to give the error message!

(Note: Is it really a "warning" if we failed to read the one file we
wer told to?)

We should check if we should either centralize these error messages
completely, or always pass them and remove this "code" system, because
it's only used in some cases.
2022-08-12 18:38:47 +02:00
Fabian Boehm
232ca25ff9 Add length to the parse_util syntax errors 2022-08-12 18:38:47 +02:00
Fabian Boehm
4b921cbc08 Clamp error carets to the end instead of refusing to print
This skipped printing a "^" line if the start or length of the error
was longer than the source.

That seems like the correc thing at first glance, however it means
that the caret line isn't skipped *if the file goes on*.

So, for example

```fish
echo "$abc["
```

by itself, in a file or via `fish -c`, would not print an error, but

```fish
echo "$abc["
true
```

would. That's not a great way to print errors.

So instead we just.. imagine the start was at most at the end.

The underlying issue why `echo "$abc["` causes this is that `wcstol`
didn't move the end pointer for the index value (because there is no
number there). I'd fix this, but apparently some of
our recursive variable calls absolutely rely on this position value.
2022-08-12 18:38:47 +02:00
Fabian Boehm
c1bf06d5b1 Print "^^" for a 2-wide error 2022-08-12 18:38:47 +02:00
Fabian Boehm
eaf92918e6 Fix error offset for command (foo)
This used the decorated statement offset when the expansion errors
refer to the command without decoration.
2022-08-12 18:38:47 +02:00
Fabian Boehm
a4fd3c194e Pass location of the *command* node without decorators
Fixes error location for unknown commands
2022-08-12 18:38:47 +02:00
Fabian Boehm
5ef457cfd3 Make tokenizer delimiter errors one long
This makes the awkward case

	    fish: Unexpected end of string, square brackets do not match
	    echo f[oo # not valid, no matching ]
	          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

(that `]` is simply the last character on the line, it's firmly in a comment)

less awkward by only marking the starting brace.

The implementation here is awkward mostly because the tok_t
communicates two things: The error location and how to carry on.

So we need to store the error length separately, and this is the first
time we've done so.

It's possible we can make this simpler.
2022-08-12 18:38:47 +02:00
Fabian Boehm
bf47d469d4 Add command substitution error length 2022-08-12 18:38:47 +02:00
Fabian Boehm
3f27febc4c Mark the entire error location with a squiggle
This makes it so instead of marking the error location with a simple
`^`, we mark it with a caret, then a run of `~`, and then an ending `^`.

This makes it easier to see where exactly an error occured, e.g. which
command substitution was meant.

Note: Because this uses error locations that haven't been exposed like
that, it's likely to shake out weirdnesses and inaccuracies. For that
reason I've not adjusted the tests yet.
2022-08-12 18:38:47 +02:00
Fabian Boehm
7b2f4f666d expand: If skip_variables is given, put back quoted $ as well
Actually fixes 
2022-08-12 17:51:59 +02:00
Fabian Boehm
db20356a6c Add wcwidth non_characters
These were added to widechar_width kinda late.

Fixes 
2022-08-12 17:25:31 +02:00
Fabian Boehm
b2eea4b46f complete: Don't load completions if command isn't in $PATH
This stops us from loading the completions for e.g. `./foo` if there
is no `foo` in path.

This is because the completion scripts will call an unqualified `foo`,
and then error out.

This of course means if the script would work because it never calls
the command, we still don't load it.

Pathed completions via `complete --path` should be unaffected because
they aren't autoloaded anyway.

Workaround for 
Fixes 
2022-08-11 17:05:32 +02:00
Fabian Boehm
37f7818bbb printf: Ignore any options
This was misguidedly "fixed" in
9e08609f85, which made printf error out
with any "-"-prefixed words as the first argument.

Note: This means currently `printf --help` doesn't print the help.
This also matches `echo`, and we currently don't have anything to make
a literal `--help` execute a builtin help except for keywords. Oh well.

Fixes 
2022-08-10 16:55:56 +02:00
Fabian Boehm
7d8009e9d6
Disclose pager to half of screen height immediately ()
* Disclose pager to screen height immediately

This removes that bit where we only show 4 rows at most at first,
instead we disclose between half of terminal height up to the full terminal height (but still at least 4 rows).

This results in less pressing of tab to get the other results, and
better visibility of results.

Unlike moving it to the actual top of the screen, it's not as jarring and doesn't push terminal history off-screen as much.

Fixes 
2022-08-09 20:05:08 +02:00
Fabian Boehm
b89249de98 Reset the read byte limit to the default when unset
This used to be kept, so e.g. testing it with

    fish_read_limit=5 echo (string repeat -n 10 a)

would cause the prompt and such to error as well.

Also there was no good way to get back to the default value
afterwards.
2022-08-09 19:59:10 +02:00
Fabian Boehm
eac808a819
string repeat: Don't allocate repeated string all at once ()
* string repeat: Don't allocate repeated string all at once

This used to allocate one string and fill it with the necessary
repetitions, which could be a very very large string.

Now, it instead uses one buffer and fills it to a chunk size,
and then writes that.

This fixes:

1. We no longer crash with too large max/count values. Before they
caused a bad_alloc because we tried to fill all RAM.
2. We no longer fill all RAM if given a big-but-not-too-big value. You
could've caused fish to eat *most* of your RAM here.
3. It can start writing almost immediately, instead of waiting
potentially minutes to start.

Performance is about the same to slightly faster overall.
2022-08-09 19:58:56 +02:00
ridiculousfish
e0a4d49ef3 Bravely stop appending a newline in reader_shell_test
This newline apparently dates back to when we required all statements to
be terminated; but our AST no longer requires that so we can remove
this. No functional change expected here.
2022-08-07 14:03:33 -07:00
ridiculousfish
1dff1cb2c4 Factor out handling of readline_cmd_t::execute
This reduces the size of handle_readline_command.
No functional change.
2022-08-07 13:37:56 -07:00
Michael Nickerson
b08a962edb Fix compile error on OpenBSD 2022-08-04 08:13:19 +02:00
Johannes Altmanninger
095c093af6 Fix "commandline --paging-mode" false negative when there is no room for pager, attempt 2
The previous fix was reverted because it broke another scenario.  Add tests
for both scenarios.

The first test exposes another problem: autosuggestions are sometimes not
recomputed after selecting the first completion with Tab Tab. Fix that too.
2022-07-31 07:14:56 +02:00
Aaron Gyes
7b18a70724 Revert "Fix "commandline --paging-mode" false negative when there is no room for pager"
This reverts commit 1edcd8ab29.

The commit broke hitting <TAB> to show the pager, followed by
down-or-search.
2022-07-30 18:15:10 -07:00
Johannes Altmanninger
a447cc38a9 Hint at more matches at the bottom of the history pager 2022-07-30 23:27:24 +02:00
Johannes Altmanninger
1af9b8e430 Prefix history pager results with a fake prompt
This makes it easy to see where the individual commands start.  Perhaps we
can get rid of this once we have syntax highlighting for the commands in
the history pager, or if we add timestamps as descriptions.
2022-07-30 23:27:24 +02:00
Johannes Altmanninger
453aac14af Advance pager history search with Control-R/Control-S
Note that every change to the search field still starts a new search, from
the end of history. We could change this in future but it's unclear to me
what the expected behavior is. I don't find the traditional readline behavior
very intuitive.
2022-07-30 23:27:24 +02:00
Johannes Altmanninger
24e04daa22 Teach history search to move forward in time
Will use this for forward incremental search.

No functional change.
2022-07-30 23:27:24 +02:00
Johannes Altmanninger
dcff0a2f2b Add Control+R incremental history search in pager
This reimplements ridiculousfish/control_r which is a more future-proof
approach than .
Pressing Control+R shows history in our pager and allows to search filter
commands with the pager search field.

On the surface, this works just like in other shells; though there are
some differences.

- Our pager shows multiple results at a time.
- Other shells allow to use up arrow/down arrow to select adjacent entries
  in history. Shouldn't be hard to implement but the hidden state might
  confuse users and it doesn't play well with up-or-search, so this is
  left out.

Users might expect the history pager to use subsequence matching (fuzzy
matching) like the completion pager, however due to the history pager design it
uses substring matching.  We could change this in future, however that means
we would also want to change the ordering from "reverse-chronological" to
"longest common subsequence" (e.g. what fuzzy finders do), because otherwise
a query "fis" might give this ordering:

            fsck /dev/disk/by-partlabel/Linux\x20filesystem
            fish

which is probably not what the user wants.

The pager shows only a small number of history items at a time.  This is
because, as explained above, the history pager does not support subsequence
matching, so navigating it does not scale well.

Closes 
2022-07-30 23:27:24 +02:00
Johannes Altmanninger
b0233c9aa7 Revert "Refactor: inline clear_pager()"
The next patch wants to add state that should be reset when we clear the
pager, which will happen in this function.

This reverts commit b25b291d38.

No functional change.
2022-07-30 23:27:24 +02:00
Johannes Altmanninger
9a0d8e67df Extract function for smartcase history search
To be used in the commit after next.

No functional change.
2022-07-30 23:27:24 +02:00
Johannes Altmanninger
3954200555 Centralize how we invalidate pager rendering after completions change
The pager's rendering_needs_update() function detects some but not all
scenarios where a rendering is stale. In particular, it does not compare
the completion strings.

To make this work, we manually invalidate the pager rendering whenever we
update completion strings. The history pager needs the same functionality,
so let's move it into the pager.

No functional change.
2022-07-30 23:27:24 +02:00
Baspar
ec8fd628bd Generate job & process exit events for background jobs 2022-07-30 10:06:33 -07:00
Michael Forster
f09d2c4e6e Use env_dispatch to update cursor selection mode 2022-07-30 09:49:07 -07:00
Michael Forster
7d198fa404 Add an initial test for fish_cursor_selection_mode 2022-07-30 09:49:07 -07:00
Michael Forster
5cf67c2d61 Use dedicated variable to configure selection size
This addresses code review feedback to not couple the purely visual
concept of cursor style with the logical concept of the selection size.
Instead this now uses a dedicated variable
`$fish_select_char_after_cursor` to determine whether to extend the
selection beyond the cursor:

* fish_select_char_after_cursor = 1 or unset -> extend selection
* all other cases -> place the selection end that the cursor
2022-07-30 09:49:07 -07:00
Michael Forster
a7d943793e Consider cursor width when updating selection
This fixes the handling of the right end of the selection. Currently the
right end is considered to be at the cursor position + 1. When using a
`block` or `underline` cursor this is arguably correct, because the
cursor has a width of 1 and spans from the current position to the next:
```
    x x [x x x̲] x
```

This is incorrect though (or at least very unintuitive), when using a
`line` cursor:
```
    x x [x x|x] x
```

This commit changes the strategy for determining the end of the
selection in the following way:

* If the current cursor as determined by `$fish_cursor_<bind_mode>` is
  set to `line`, then a cursor width of `0` is assumed.
* In all other cases, including `block` and `underscore` as well as when
  no value is set we retain the previous behavior of assuming a cursor
  width of `1`.
```
    x x [x x x̲] x
    x x [x x|]x x
```

This change should not affect many users, because the selection is
probably used most by vi-mode users, who are also likely to use a
block cursor.
2022-07-30 09:49:07 -07:00