For historical reasons (namely the webconfig origin), our theme
names contain spaces and uppercase letters which can be inconvenient
when using the "fish_config theme choose" shell command. Use more
conventional file names.
Web config still uses the pretty names, using the ubiquitous "# name:"
property.
Commit 0893134543 (Added .editorconfig file (#3332) (#3313),
2016-08-25) trimmed trailing whitespace for Markdown file (which do
have significant trailing whitespace) but ReStructuredText does not,
and none of our Markdown files cares about this, so let's clean up
whitespace always.
No need to define "cmd-foo" anchors; use :doc:`foo <cmds/foo>`
instead. If we want "cmd-foo" but it should be tested.
See also 38b24c2325 (docs: Use :doc: role when linking to commands,
2022-09-23).
functions/help and completions/help duplicate a lot of information
from doc_src. Get this information from Sphinx.
Drop short section titles such as "help globbing" in favor of the
full HTML anchor:
help language#wildcards-globbing
I think the verbosity is no big deal because we have tab completion,
we're trading in conciseness for consistency and better searchability.
In future, we can add back shorter invocations like "help globbing"
(especially given that completion descriptions often already repeated
the anchor path), but it should be checked by CI.
Also
- Remove some unused Sphinx anchors
- Remove an obsoleted script.
- Test that completions are in sync with Sphinx sources.
(note that an alternative would be to check
in the generated help_sections.rs file, see
https://internals.rust-lang.org/t/how-fail-on-cargo-warning-warnings-from-build-rs/23590/5)
Here's a list of deleted msgids. Some of them were unused, for others
there was a better message (+ translation).
$variable $variable 变量
(command) command substitution (命令) 命令替换
< and > redirections < 和 > 重定向
Autoloading functions 自动加载函数
Background jobs 后台作业
Builtin commands 内建命令
Combining different expansions 合并不同的展开
Command substitution (SUBCOMMAND) 命令替换 (子命令)
Defining aliases 定义别名
Escaping characters 转义字符
Help on how to reuse previously entered commands 关于如何重复使用先前输入的命令的帮助
How lists combine 列表如何组合
Job control 作业控制
Local, global and universal scope 局域、全局和通用作用域
Other features 其他功能
Programmable prompt 可编程提示符
Shell variable and function names Shell 变量和函数名
Some common words 一些常用词
The status variable 状况变量
Variable scope for functions 函数的变量作用域
Vi mode commands Vi 模式命令
What set -x does `set -x` 做什么
Writing your own completions 自己写补全
ifs and elses if 和 else
var[x..y] slices var[x..y] 切片
{a,b} brace expansion {a,b} 大括号展开
~ expansion ~ 展开
Closes#11796
This seems a bit better because it's what bind uses. To makes sure that
something like :kbd:`ctrl-x` looks good in HTML, remove the border from the
kbd style. Else both "ctrl" and "x" get small boxes which looks weird.
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.
If a code block includes a line starting with ">", we assume it shows
an interactive session, all lines starting with ">" are commands and
the rest is output.
Unfortunately, in something like:
```
> for val in $PATh
echo "entry: $val"
end
entry: /usr/bin
```
this won't highlight the dangling lines. We could also prefix them
with `>`, but that require us to parse them in blocks or the `end`
would be an error.
So, for now, simply don't give these as a prompt but as a script with
cheesy comments describing the output.
The file is called "config.fish", not "init.fish". We'll call it
"configuration" now.
"Initialization" might be slightly more precise, but in an irritating
way.
Also some wording improvements to the section. In particular we now
mention config.fish *early*, before the whole shebang.
Unlike links, these are checked by sphinx and it complains if they
don't match.
Also they have a better chance of doing something useful in outputs
other than html.
We should typically avoid scrolling even at max-width.
An exception here is the output of `functions` - this prints one very
long line, but it's really not important what's in there specifically,
it's just to illustrate the kind of output you'd get.
This came up online - here we exclaim that fish has no aliases (which
is true), but then in the main docs we explain that you can use
`alias` to make something (which is also true).
Add a foot note explaining the apparent contradiction.
For the few weird code blocks where default highlighting does not work,
we must add the 'highlight' class manually to get matching backgrounds.
This reuses the background color defined in pygments.css.
There are a few code blocks where the default highlighting does not
work and the documentation looks bad as a result. Usually this happens
when we are demonstrating an important interactive feature, such as
autosuggestions, syntax highlighting, or tab completion.
The pygments highlighter was not designed for code samples like these.
But it is important to show the behavior clearly in the docs. I am
attempting to make these weird examples look as much like the "normal"
code blocks as possible.
https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
- add missing links for some commands (control flow section)
- fix broken links that use the old syntax (#tut_ links)
- miscellaneous fixing of backticks/emphasis
