It's fine if it doesn't show up in the synopsis above, but putting it
under "Notes" is just too awkward.
It's a short option that exists, and so it should be documented.
I tried to make the synopsis a little less theoretical with
the placeholders and instead introduced the actual scope
options, long and short once, then refer to them as -Uflg from
then on.
I mentioned that list indicies are accepted / work to erase stuff.
In the list of options, we pretend like --unexport is long-only.
Especially with --unpath and --path, and what would go wrong
if one confused it with --univeral, and how rarely it's used,
I think it's better this way. I mention it as a synonym later
in the document so that it's not literally undocumented.
Changed phrasing such as:
"Causes the specified shell variable to be given a global scope"
Which can be read as we are taking a shell variable that exists
and giving it global scope, upgrading it to global (retaining
the value).
Redid the example section using the > syntax for things entered
into a prompt, with shell output following. The explanatory
Added in missing newlines at the ends of sentences.
I'm not sure if line continuations are covered anywhere else in the docs, but I
think the escapes section of the language page is a good place to mention them.
Makes it possible to retrieve the currently executing command line as
opposed to the currently executing command (`status current-command`).
Closes#8905.
- Clean up the wording a little.
- Highlight the limitations of the "debugger" more clearly and don't mislead
people into thinking it's possible to really interactively set/remove
breakpoints except in select circumstances.
Sidenote: I can't believe we're using a markup language that doesn't support
nested inline markup. What a crying shame, rST!
Up to now, in normal locales \x was essentially the same as \X, except
that it errored if given a value > 0x7f.
That's kind of annoying and useless.
A subtle change is that `\xHH` now represents the character (if any)
encoded by the byte value "HH", so even for values <= 0x7f if that's
not the same as the ASCII value we would diverge.
I do not believe anyone has ever run fish on a system where that
distinction matters. It isn't a thing for UTF-8, it isn't a thing for
ASCII, it isn't a thing for UTF-16, it isn't a thing for any extended
ASCII scheme - ISO8859-X, it isn't a thing for SHIFT-JIS.
I am reasonably certain we are making that same assumption in other
places.
Fixes#1352
There are many applications with "primitive" argument parsing capabalities that
cannot handle munging two short options together (`-xf` for `-x -f`) or a short
option and its required value (`-dall` for `-d all`). To prevent fish from
suggesting munged arguments/payloads, the options (both long and short, not just
long!) can be specified as `-o` or `--old-option` but none of this is
documented.
Hyphenation in our documentation is aggressive, even to the point of caus-
ing options themselves to be broken across lines. This makes the document-
ation hard to read, especially when you have an option like `string colle-
ct` which gets a weird hyphen.
Remove the hyphenation from the CSS.
This makes it so we link to the very top of the document instead of a
special anchor we manually include.
So clicking e.g. :doc:`string <cmds/string>` will link you to
cmds/string.html instead of cmds/string.html#cmd-string.
I would love to have a way to say "this document from the root of the
document path", but that doesn't appear to work, I tried
`/cmds/string`.
So we'll just have to use cmds/string in normal documents and plain
`string` from other commands.
