mirror of
https://github.com/neovim/neovim.git
synced 2024-12-19 18:55:14 -07:00
Merge pull request #14582 from bfredl/gender
docs: fix some remanining cases of gender pronoun for "the user"
This commit is contained in:
commit
d16e9d8ed4
@ -3181,8 +3181,8 @@ window, then the one window will be horizontally split (by default).
|
||||
If there's more than one window, the previous window will be re-used on
|
||||
the selected file/directory. If the previous window's associated buffer
|
||||
has been modified, and there's only one window with that buffer, then
|
||||
the user will be asked if s/he wishes to save the buffer first (yes,
|
||||
no, or cancel).
|
||||
the user will be asked if they wish to save the buffer first (yes, no, or
|
||||
cancel).
|
||||
|
||||
Related Actions |netrw-cr| |netrw-o| |netrw-t| |netrw-v|
|
||||
Associated setting variables:
|
||||
|
@ -1969,7 +1969,7 @@ LEX *lex.vim* *ft-lex-syntax*
|
||||
Lex uses brute-force synchronizing as the "^%%$" section delimiter
|
||||
gives no clue as to what section follows. Consequently, the value for >
|
||||
:syn sync minlines=300
|
||||
may be changed by the user if s/he is experiencing synchronization
|
||||
may be changed by the user if they are experiencing synchronization
|
||||
difficulties (such as may happen with large lex files).
|
||||
|
||||
|
||||
@ -3009,11 +3009,11 @@ variables in your vimrc:
|
||||
|
||||
< (dash users should use posix)
|
||||
|
||||
If there's no "#! ..." line, and the user hasn't availed himself/herself of a
|
||||
default sh.vim syntax setting as just shown, then syntax/sh.vim will assume
|
||||
the Bourne shell syntax. No need to quote RFCs or market penetration
|
||||
statistics in error reports, please -- just select the default version of the
|
||||
sh your system uses and install the associated "let..." in your <.vimrc>.
|
||||
If there's no "#! ..." line, and the user hasn't availed themself of a default
|
||||
sh.vim syntax setting as just shown, then syntax/sh.vim will assume the Bourne
|
||||
shell syntax. No need to quote RFCs or market penetration statistics in error
|
||||
reports, please -- just select the default version of the sh your system uses
|
||||
and install the associated "let..." in your <.vimrc>.
|
||||
|
||||
The syntax/sh.vim file provides several levels of syntax-based folding: >
|
||||
|
||||
|
@ -1875,7 +1875,7 @@ NOT LOADING
|
||||
|
||||
It's possible that a user doesn't always want to load this plugin. Or the
|
||||
system administrator has dropped it in the system-wide plugin directory, but a
|
||||
user has his own plugin he wants to use. Then the user must have a chance to
|
||||
user has their own plugin they want to use. Then the user must have a chance to
|
||||
disable loading this specific plugin. This will make it possible: >
|
||||
|
||||
6 if exists("g:loaded_typecorr")
|
||||
@ -1908,7 +1908,7 @@ item can be used: >
|
||||
|
||||
The "<Plug>TypecorrAdd;" thing will do the work, more about that further on.
|
||||
|
||||
The user can set the "mapleader" variable to the key sequence that he wants
|
||||
The user can set the "mapleader" variable to the key sequence that they want
|
||||
this mapping to start with. Thus if the user has done: >
|
||||
|
||||
let mapleader = "_"
|
||||
@ -1919,7 +1919,7 @@ will be used, which is a backslash. Then a map for "\a" will be defined.
|
||||
Note that <unique> is used, this will cause an error message if the mapping
|
||||
already happened to exist. |:map-<unique>|
|
||||
|
||||
But what if the user wants to define his own key sequence? We can allow that
|
||||
But what if the user wants to define their own key sequence? We can allow that
|
||||
with this mechanism: >
|
||||
|
||||
21 if !hasmapto('<Plug>TypecorrAdd;')
|
||||
@ -1928,7 +1928,7 @@ with this mechanism: >
|
||||
|
||||
This checks if a mapping to "<Plug>TypecorrAdd;" already exists, and only
|
||||
defines the mapping from "<Leader>a" if it doesn't. The user then has a
|
||||
chance of putting this in his vimrc file: >
|
||||
chance of putting this in their vimrc file: >
|
||||
|
||||
map ,c <Plug>TypecorrAdd;
|
||||
|
||||
@ -2033,7 +2033,7 @@ Now let's add a user command to add a correction: >
|
||||
The user command is defined only if no command with the same name already
|
||||
exists. Otherwise we would get an error here. Overriding the existing user
|
||||
command with ":command!" is not a good idea, this would probably make the user
|
||||
wonder why the command he defined himself doesn't work. |:command|
|
||||
wonder why the command they defined themself doesn't work. |:command|
|
||||
|
||||
|
||||
SCRIPT VARIABLES
|
||||
@ -2285,7 +2285,7 @@ An example of how to define functionality in a filetype plugin: >
|
||||
|hasmapto()| is used to check if the user has already defined a map to
|
||||
<Plug>JavaImport;. If not, then the filetype plugin defines the default
|
||||
mapping. This starts with |<LocalLeader>|, which allows the user to select
|
||||
the key(s) he wants filetype plugin mappings to start with. The default is a
|
||||
the key(s) they want filetype plugin mappings to start with. The default is a
|
||||
backslash.
|
||||
"<unique>" is used to give an error message if the mapping already exists or
|
||||
overlaps with an existing mapping.
|
||||
|
@ -209,8 +209,8 @@ argument: >
|
||||
:amenu <silent> Mine.Next\ File :call <SID>NextFile()<CR>
|
||||
|
||||
Don't use "<silent>" too often. It is not needed for short commands. If you
|
||||
make a menu for someone else, being able to see the executed command will give
|
||||
him a hint about what he could have typed, instead of using the mouse.
|
||||
make a menu for someone else, being able to see the executed command will
|
||||
give them a hint about what they could have typed, instead of using the mouse.
|
||||
|
||||
|
||||
LISTING MENUS
|
||||
|
@ -216,7 +216,7 @@ starting with "$".
|
||||
## INTERACTIVE ELEMENTS *interactive*
|
||||
|
||||
As visible in this very document, vim-tutor-mode includes some interactive
|
||||
elements to provide feedback to the user about his progress. If the text in
|
||||
elements to provide feedback to the user about their progress. If the text in
|
||||
these elements satisfies some set condition, a ✓ sign will appear in the gutter
|
||||
to the left. Otherwise, a ✗ sign is displayed.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user