It seems that the behaviour of the start parameter being missing is
server (or perhaps a specific client) dependent. The specification
clearely says that it should be inserted at the column of the original
request, but the servers clearly expect either for that column to be the
beginning of an identifier or for the client to ignore the spec and
request from that position anyway.
Reading the VSCode code, we see that the 'word' before the cursor is
guessed, and if only if BOTH 'start' AND 'length' are supplied, then
they are used to determine where insertion starts, otherwise the current
'word' is used. Unclear what 'word' means in the specific contexts, but
we're relying on iskeyword.
Too many plugins use the default priority of 10 so they race/chase.
Allow uses to configure the priorities and make sure that the defaults
are documented.
Initially I considered using #i, #s, etc. to coerce to specific types,
but then it wasn't clear of the semantics (particularly for bool, where
JSON bool true/false, Python bool True/False).
But it turns out that we can just coerce any key from a JSON string.
Users can _probably_ type JSON strings for most things, or use variables
to run scripts to generate them, this allows essentially complete
flexibility to define the data types needed to populate the launch spec.
The purpose of this is to allow some level of automated setup by
requesting data from the user and then (subsequently) saving the
flattneed config to the vimspector config file.
Debate rages about whether JSON should have comments. The specification
says it shouldn't but the author of JSON suggested that if you want to
use JSON for configuration, then pipe it through jsmin before parsing.
So that's what we do, using a tiny JSON minifier from
https://github.com/getify/JSON.minify/tree/pythonCloses#135
There are 2 things we ask for input for:
- input variables
- exception breakpoints
It's irritating to have to repeat yourself when going through the
edit/debug loop.
Howver, cacheing has some quirks and disadvantages - they key one being
when to clear the cache. To resolve this we take two slightly different
approaches:
1. For input variables, we remember the choice of the user, but present
that only as the default, so they can just hit enter to accept it. We
already rememeber the choices for the length of the debug session (i.e.
across 'restart' calls).
2. For exception breakpoints, we remember the choices for as long as the
current session is running.
This allows users to hit the 'restart' button without being prompted at
all.
Meanwhile, we also remove the (broken) support for exception breakpoint
matchers and state the server default for exception breakpoint filters.
