Problem: The style guide states that all switch statements that are not conditional on an enum must have a `default` case, but does not give any explicit guideline for switch statements that are conditional on enums. As a result, a `default` case is added in many enum switch statements, even when the switch statement is exhaustive. This is not ideal because it removes the ability to have compiler errors to easily detect unchanged switch statements when a new possible value for an enum is added.
Solution: Add explicit guidelines for switch statements that are conditional on an enum, clarifying that a `default` case is not necessary if the switch statement is exhaustive. Also refactor pre-existing code with unnecessary `default` cases.
Problem: Macros for MS-Windows are inconsistent, using "32", "3264 and
others.
Solution: Use MSWIN for all MS-Windows builds. Use FEAT_GUI_MSWIN for the
GUI build. (Hirohito Higashi, closesvim/vim#3932)
4f97475d32
* fix(PVS/V547): remove ifs that are always true or false
* fix(PVS/V560): remove partial conditions that are always true
* fix(PVS/V1044): suppress warning about loop break conditions
* fix(PVS/V1063): suppress "modulo by 1 operation is meaningless"
* fix(PVS/V568): suppress "operator evaluates the size of a pointer"
Also mark vim-patch:8.2.4958 as ported.
This includes a partial port of Vim patch 8.2.2569 and some changes to
nvim_eval_statusline() to allow a multibyte fillchar. Literally every
line of C code touched by that patch has been refactored in Nvim, and
that patch contains some irrelevant foldcolumn tests I'm not sure how to
port (as Nvim's foldcolumn behavior has diverged from Vim's).
* refactor: format all C files under nvim
* refactor: disable formatting for Vim-owned files:
* src/nvim/indent_c.c
* src/nvim/regexp.c
* src/nvim/regexp_nfa.c
* src/nvim/testdir/samples/memfile_test.c
The warning is triggered by the second division when arr is a char array
since sizeof(char) is 1. A modulo by 1 may normally indicate a logic
error, but in this case it's intended.
Problem: Cannot get the search statistics.
Solution: Add the searchcount() function. (Fujiwara Takuya, closesvim/vim#4446)
e8f5ec0d30
Additional changes:
- Tests weren't passing because the test ran assuming the cursor was at
start of buffer but append() left the cursor at end of buffer .
So cursor is moved to start of buffer after append.
- searchcount() added to list of builtin functions.
Per GCC's documentation:
> The __has_include operator by itself, without any operand or parentheses, acts as a predefined macro so that support for it can be tested in portable code. Thus, the recommended use of the operator is as follows:
>
> #if defined __has_include
> # if __has_include (<stdatomic.h>)
> # include <stdatomic.h>
> # endif
> #endif
>
> The first ‘#if’ test succeeds only when the operator is supported by the version of GCC (or another compiler) being used. Only when that test succeeds is it valid to use __has_include as a preprocessor operator.
Problem: Cannot get the script line number when executing a function.
Solution: Store the line number besides the script ID. (Ozaki Kiichi,
closesvim/vim#3362) Also display the line number with ":verbose set".
f29c1c6aa3
Problem: Mac features are confusing.
Solution: Make feature names more consistent, add "osxdarwin". Rename
feature flags, cleanup Mac code. (Kazunobu Kuriyama, closesvim/vim#2178)
d057301b1f
Problem: Too many curly braces.
Solution: Remove curly braces where they are not needed. (Hirohito Higashi,
closesvim/vim#3982)
abab0b0fdd
Neovim code style requires the opposite.
Add curly braces to minimize lint errors when applying Vim patches.
Problems so far:
- Marks in the current instance are not adjusted.
- Duplicates are not removed (not that it works in Vim either now, not at
8.0.134 at least).
We were initially checking whether to apply 'langmap' translation based
on typebuf.tb_maplen.
This gets set to 0 on the last byte of a map when the del_typebuf()
function is called, which means that the option was not working for the
last character of a mapping.
For this reason, we switched to using KeyTyped to decide whether to
apply the transformation or not in commit 53da57d27.
Substituting one for the other isn't enough, because KeyTyped isn't set
until vgetorpeek() is returning.
This means 'langmap' translations are not applied when searching for
characters to map in the vgetorpeek() function if the *previous* key was
not typed.
We can't assert that both hold, as we would then *not* apply the
transformation when looking for a map starting with the first typed key
after a previously expanded map (as KeyTyped would be `false` from the
previously expanded map, and not yet reset).
Hence we assert that if we are looking for the mapping while in
vgetorpeek(), the map length should be zero, otherwise, KeyTyped must be
`true`.
This is implemented by checking for the variable `vgetc_busy`.
