Uncrustify and clang-format are already both excellent at ordering
includes; this isn't something we need to check for ourselves. Also
remove the section on include order in the dev-style documentation.
This warning is essentially only triggered for ported vim functions.
It's unlikely that we'll refactor vim functions solely based on their
size since it'd mean we'd greatly deviate from vim, which is a high cost
when it comes to importing the vim patches. Thus, this warning only
serves as an annoyance and should be removed.
Do not copy a lot of lua strings (dict keys) to just strequal() them
Just compare them directly to a dedicated hash function.
feat(generators): HASHY McHASHFACE
Fixes handing of "-" on Python 3:
Traceback (most recent call last):
File "…/Vcs/neovim/src/clint.py", line 3625, in <module>
main()
File "…/Vcs/neovim/src/clint.py", line 3618, in main
ProcessFile(filename, _cpplint_state.verbose_level)
File "…/Vcs/neovim/src/clint.py", line 3464, in ProcessFile
'replace').read().split('\n')
File "/usr/lib/python3.7/codecs.py", line 701, in read
return self.reader.read(size)
File "/usr/lib/python3.7/codecs.py", line 500, in read
data = self.bytebuffer + newdata
TypeError: can't concat str to bytes
With the old behavior, if a GUI makes a blocking request that requires user
interaction (like nvim_input()), it would not get any screen updates.
The client, not nvim, should decide how to handle notifications during a
pending request. If an rplugin wants to avoid async calls while a sync call is
busy, it likely wants to avoid processing async calls while another async call
also is handled as well.
This may break the expectation of some existing rplugins. For compatibility,
remote/define.vim reimplements the old behavior. Clients can opt-out by
specifying `sync=urgent`.
- Legacy hosts should be updated to use `sync=urgent`. They could add a flag
indicating which async methods are always safe to call and which must wait
until the main loop returns.
- New hosts can expose the full asyncness, they don't need to offer both
behaviors.
ref #6532
ref #1398d83868fe90
memcpy is not equivalent to memmove (which is used by vim_strcat), this
could cause subtle bugs if xstrlcat is used as a replacement for
vim_strcat. But vim_strcat is inconsistent: in the `else` branch it uses
strcpy, which doesn't allow overlap.
Helped-by: oni-link <knil.ino@gmail.com>
Helped-by: James McCoy <jamessan@jamessan.com>
Helped-by: Nikolai Aleksandrovich Pavlov <kp-pav@yandex.ru>
Closes#731
References #851
Note: This does not remove some intentional legacy usages of strncpy.
- memcpy isn't equivalent because it doesn't check the string
length of `src`, and doesn't zero-out the remainder of `dst`.
- xstrlcpy isn't equivalent because it doesn't zero-out the
remainder of `dst`. Some Vim logic depends on that (e.g.
ex_append which calls vim_strnsave).
Helped-by: Douglas Schneider <ds3@ualberta.ca>
Helped-by: oni-link <knil.ino@gmail.com>
Helped-by: James McCoy <jamessan@jamessan.com>
Except when they are system just in case. There should be no .c.h system files
though, but if there will be it is unlikely that they inherit the same
convention.
