URL had properly named replacements for protocol(), set_protocol() and
create_with_file_protocol() already. This patch removes these function
and updates all call sites to use the functions named according to the
specification.
See https://url.spec.whatwg.org/#concept-url-scheme
This was present in Vector already. Clang-format fixed some const
positions automatically too.
Also removed a now-ambiguous and unnecessary constructor from Shell.
We previously had at least three different implementations for resolving
executables in the PATH, all of which had slightly different
characteristics.
Merge those into a single implementation to keep the behaviour
consistent, and maybe to make that implementation more configurable in
the future.
When |& is typed, stderr will be piped to stdout before the actual
piping happens. This behaves basically like a 2>&1 | (and the
underlying implementation transforms it to that anyway).
Replacement conditions for `requires_argument` have been chosen based
on what would be most convenient for implementing an eventual optional
argument mode.
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
StringView was used where possible. Some utilities still use libc
functions which expect null-terminated strings, so String objects were
used there instead.
The lazy resolution mechanism made it so that the variables were linked
together, causing unexpected behaviour:
true
x=$? # expected: x=0
false
echo $x # expected: 0, actual: 1
This moves all code comprehension-related code to a new library,
LibCodeComprehension.
This also moves some types related to code comprehension tasks (such as
autocomplete, find declaration) out of LibGUI and into
LibCodeComprehension.
31ca48e made this default to paths, but now that we have a few sensible
ways to complete things, let's make those work too.
For instance, prior to this `kill <tab>` would've suggested paths, but
now it will suggest processes.
Setting 'allow_commit_without_listing' to false will now make LibLine
show the suggestion before actually committing to it; this is useful for
completions that will replace all the user input, where mistakes can go
unnoticed without some visual cue.
Now that we can resolve these correctly and they're per-suggestion, we
can finally use them for their intended purpose of letting suggestions
overwrite stuff in the buffer.
The shell now expects a JSON object of the form {"kind":<kind>,...} per
line in the standard output of the completion process, where 'kind' is
one of:
- "plain": Just a plain suggestion.
- "program": Prompts the shell to complete a program name starting with
the given "name".
- "proxy": Prompts the shell to act as if a completion for "argv" was
requested.
- "path": Prompts the shell to complete a path given the "base" and
"part" (same as completing part in cwd=base).
We previously allowed globs as match pattern, but for more complex
matching needs, it's nice to have regular expressions.
And as the existing "name a part of the match" concept maps nicely to
named capture groups, we can simply reuse the same code and make groups
with names available in the match body.
For example, when typing `cd <tab>`, the shell will show a list of
files in the current directory. This behavior is similar to typing `cd
./<tab>`.
It makes it easier to `cd` into directories without having to list them
first.
This saves work in places that previously had to create a
`Vector<String>` anyway, or repeatedly cast the char* to a String.
Plus, Strings are nicer than char*. :^)
This feature needs a bit more work, so let's disable it by default.
Note that the shell will still use _complete_foo if it is defined
regardless of this setting.
This commit limits the autocomplete processes to effectively have
readonly access to the fs, and only enough pledges to get the dynamic
loader working.
A program can either respond to `--complete -- some args to complete`
directly, or add a `_complete_<program name>` invokable (i.e. shell
function, or just a plain binary in PATH) that completes the given
command and lists the completions on stdout.
Should such a completion fail or yield no results, we'll fall back to
the previous completion algorithm.
Shell can now use LibLine's `on_paste` hook to more intelligently escape
pasted data, with the following heuristics:
- If the current command is invalid, just pile the pasted string on top
- If the cursor is *after* a command node, escape the pasted data,
whichever way yields a smaller encoding
- If the cursor is at the start of or in the middle of a command name,
paste the data as-is, assuming that the user wants to paste code
- If the cursor is otherwise in some argument, escape the pasted data
according to which kind of string the cursor is in the middle of
(double-quoted, single-quoted or a simple bareword)
Previously would show the list of history items starting from
an index of 0.
This is a bit misleading though. Running `!0` would actually cause
the parser to error out and prevent you from running the command.
The "at most n bytes" behaviour of strncmp is required for this logic to
work, this was overlooked in 5b64abe when converting Strings to
StringViews, which lead to broken autocomplete.
