Prior to this, we did not care if there was any whitespace after the
last token in the prompt, and this caused a regression:
```
> lsp <tab>
> lsp ci
```
To achieve this, the API was tweaked a bit to allow for easier tracking
of completions.
This API change is non-disruptive to any application that does not use
anchored styles.
LibLine should ultimately not care about what a "token" means in the
context of its user, so force the user to split the buffer itself.
This also allows the users to pick up contextual clues as well, since
they have to lex the line themselves.
This commit pacthes Shell and the JS repl to better handle completions,
so certain wrong behaviours are now corrected as well:
- JS repl can now complete "Object . getOw<tab>"
- Shell can now complete "echo | ca<tab>" and paths inside strings
In the case of a syntax error the shell parser prints an error message
to stderr and returns an empty Vector<Command> - in that case we
shouldn't try to determine whether or not we can continue parsing but
abort immediately - is_complete() expects that *something* was parsed
successfully.
Fixes#2251.
This fixes the little issue with Shell not allowing cancellation of
commands once they were in continuation mode
```
$ ls '
$ # No matter what we do here, we cannot escape 'ls'
```
This patchset adds some metadata to Parser::parse() which allows the
Shell to ask for the rest of a command, if it is not complete.
A command is considered complete if it has no trailing pipe, or
unterminated string.
This patchset fixes incorrect handling of escaped tokens (`a\ b`) in
Shell autocompletion and LibLine.
The users of LibLine can now choose between two token splitting modes,
either taking into account escapes, or ignoring them.
It was impractical to return a RefPtr<File> since that left us no way
to extract the error string. This is usually needed for the UI, so the
old static open() got basically no use.
These strings would be applied when inserted into the buffer, but are
not shown as part of the suggestion.
This commit also patches up Userland/js and Shell to use this
functionality
Now expanding a tilde isn't hardcoded to just work for `cd`. It is instead
expanded while processing shell arguments. Autocompletion still doesn't
work, but this is definitely an improvement over the last iteration.
`cdh` with no arguments dumps the last 8 cd calls in history, and
`cdh [index]` can be used to cd to re-run a specific index from that
history. `cdh` itself it a thin wrapper of the `cd` builtin.
There's definitely some improvements that can be made for this command,
but this seems like a good starting point for getting a feel for it and
ideas for changing it in the future.
It's not entirely clear whether we should be storing the resolved path -
or simply just the last argument passed to cd. For now we just use the
last path passed into cd as this seemed like the better option for now.
This means:
* invalid paths will still be stored in history (potentially useful)
* cdh's can be repeated for duplicate directory names
* the history looks a little nicer on the eyes
It might make sense to use resolved paths.
Closes#397
