* typval_encode.c.h: avoid -Wnonnull-compare warning
closes#6847
The NULL check is needed because TYPVAL_ENCODE_CONV_EMPTY_DICT may be
invoked with literal `NULL`.
Warning occurs even for `Debug` build-type:
neovim/src/nvim/eval/typval.c: In function ‘_typval_encode_nothing_convert_one_value’:
neovim/src/nvim/eval/typval.c:1802:10: warning: nonnull argument ‘tv’ compared to NULL [-Wnonnull-compare]
if (tv != NULL) { \
^
../src/nvim/eval/typval_encode.c.h:398:9: note: in expansion of macro ‘TYPVAL_ENCODE_CONV_EMPTY_DICT’
TYPVAL_ENCODE_CONV_EMPTY_DICT(tv, tv->vval.v_dict);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc version:
gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
* fixup! typval_encode.c.h: avoid -Wnonnull-compare warning
With this implementation there is no "jank" during startup.
Using the main_loop in any fashion is janky. Using only the TUI loop
emits the termcodes too soon, or requires bad hacks like counting
tui_flush invocations (9 seems to work).
ref #7664
ref #7649
ref #7664
ref 27f9b1c7b0
vim-patch:8.0.0299 NA
vim-patch:8.0.0309 NA
vim-patch:8.0.0310 NA
vim-patch:8.0.0215 NA
Problem: When a Cscope line contains CTRL-L a NULL pointer may be used.
(Coverity)
Solution: Don't check for an emacs tag in a cscope line.
e362c3d2c3
vim-patch:8.0.0244 NA
Problem: When the user sets t_BE empty after startup to disable bracketed
paste, this has no direct effect.
Solution: When t_BE is made empty write t_BD. When t_BE is made non-empty
write the new value.
d9c60648e5
Some patches were not properly marked in the commit logs. So they are
marked here:
vim-patch:8.0.1230
vim-patch:8.0.1229
vim-patch:8.0.0618
vim-patch:8.0.0104
vim-patch:8.0.0405
vim-patch:8.0.0400
vim-patch:8.0.0302
vim-patch:8.0.0288
vim-patch:8.0.0285
vim-patch:8.0.0284
vim-patch:8.0.0281
vim-patch:8.0.0279
vim-patch:8.0.0278
vim-patch:8.0.0277
vim-patch:8.0.0276
vim-patch:8.0.0273
vim-patch:8.0.0272
vim-patch:8.0.0271
vim-patch:8.0.0270
vim-patch:8.0.0269
vim-patch:8.0.0268
vim-patch:8.0.0267
vim-patch:8.0.0260
vim-patch:8.0.0257
vim-patch:8.0.0249
vim-patch:8.0.0248
vim-patch:8.0.0246
vim-patch:8.0.0244
vim-patch:8.0.0241
vim-patch:8.0.0240
vim-patch:8.0.0239
vim-patch:8.0.0232
vim-patch:8.0.0221
vim-patch:8.0.0217
vim-patch:8.0.0215
vim-patch:8.0.0213
vim-patch:8.0.0211
vim-patch:8.0.0203
vim-patch:8.0.0199
vim-patch:8.0.0193
vim-patch:8.0.0192
vim-patch:8.0.0191
vim-patch:8.0.0187
vim-patch:8.0.0183
vim-patch:8.0.0180
vim-patch:8.0.0173
vim-patch:8.0.0171
vim-patch:8.0.0170
vim-patch:8.0.0169
vim-patch:8.0.0166
vim-patch:8.0.0163
vim-patch:8.0.0162
vim-patch:8.0.0161
vim-patch:8.0.0152
vim-patch:8.0.0145
vim-patch:8.0.0144
vim-patch:8.0.0141
vim-patch:8.0.0139
vim-patch:8.0.0138
vim-patch:8.0.0130
vim-patch:8.0.0129
vim-patch:8.0.0123
vim-patch:8.0.0122
vim-patch:8.0.0120
vim-patch:8.0.0117
vim-patch:8.0.0115
vim-patch:8.0.0114
vim-patch:8.0.0113
vim-patch:8.0.0109
vim-patch:8.0.0108
vim-patch:8.0.0107
vim-patch:8.0.0105
vim-patch:8.0.0103
vim-patch:8.0.0098
vim-patch:8.0.0097
vim-patch:8.0.0095
vim-patch:8.0.0094
vim-patch:8.0.0093
vim-patch:8.0.0089
vim-patch:8.0.0087
vim-patch:8.0.0082
vim-patch:8.0.0080
vim-patch:8.0.0077
vim-patch:8.0.0076
vim-patch:8.0.0072
vim-patch:8.0.0071
vim-patch:8.0.0070
vim-patch:8.0.0067
vim-patch:8.0.0065
vim-patch:8.0.0063
vim-patch:8.0.0061
vim-patch:8.0.0059
vim-patch:8.0.0055
vim-patch:8.0.0054
vim-patch:8.0.0051
vim-patch:8.0.0050
vim-patch:8.0.0048
vim-patch:8.0.0045
vim-patch:8.0.0039
vim-patch:8.0.0036
vim-patch:8.0.0030
vim-patch:8.0.0029
vim-patch:8.0.0028
vim-patch:8.0.0027
vim-patch:8.0.0024
vim-patch:8.0.0022
vim-patch:8.0.0021
vim-patch:8.0.0018
vim-patch:8.0.0016
vim-patch:8.0.0015
vim-patch:8.0.0014
vim-patch:8.0.0013
vim-patch:8.0.0011
vim-patch:8.0.0010
vim-patch:8.0.0009
vim-patch:8.0.0007
vim-patch:8.0.0005
Use `@cond <something>` to obscure a section from doxygen.
doxygen thinks kvec_withinit_t() is a function. That adds noise to the
generated API documentation, and also prevents the following function
from being noticed.
closes#7429
Problem: after a help window was closed, a window was selected and its
autocommands triggered. After that, restore_snapshot was called and the
focused window changed, confusing the user.
Solution: Add function get_snapshot_focus() that returns the window that
holds the cursor in a snapshot. Use this function in win_close to make
sure the right window is selected before any autocommand is triggered.
Unix's typical locale-related environment variables aren't always set
appropriately on a Mac. Instead of relying on them, query the locale
information using Mac specific APIs and then set $LANG appropriately for
the rest of nvim.
Closes#5873
The previous commit ensures that we can never flush the buffer in a
state where toggling cursor visibility can corrupt other escape codes.
Thus, we can remove the workaround added as part of e838452, simplyfing
the code and hiding the cursor on more occasions.
e83845285 fixed an issue where long (true color) escape sequences got
interrupted by the cursor visibility toggling caused by buffer flushes.
cdfaecb25 introduces a new issue which causes similar problems: While
the old buffer flushing code appended the cursor visibility escapes to
the buffer before/after flushing, the new code effectively prepends the
sequences.
Assume the following sequence of events occurs:
- A long escape code is issued using unibi_out when the buffer is
almost full
- out() gets called for a prefix of that escape code, causing the
buffer to fill up
- flush_buf(ui, false) is called and (correctly) does not insert any
cursor toggling escapes
- The rest of the escape code is written into the now empty buffer
- At some later point, some other part of nvim calls flush_buf(ui,
true), which then toggles the cursor, corrupting the escape code
This could possibly also be fixed by tracking the state of the buffer
(i.e. does it contain a partially output escape code?), but this seems
fragile in the same way e83845285 turned out to be.
The root cause for all these problems is the mismatch between nvim's
(implicit) assumption that the buffer is flushable at any point in time
and the non-atomicity of unibilium's character based callback interface.
The proper fix (without modifying unibilium) is to ensure nvim's
assumption about the buffer state holds at all times.
To that end, add a "cork" flag which ensures one unibi_out-call never
splits its output across a buffer flush; if an escape code does not fit
into the current buffer, flush it without any part of the escape code in
it and insert the whole escape code in the emptied buffer. This is a
little more complex because it modifies the buffer in place rather than
printing into another buffer, checking the remaining space in the
terminal buffer and then memcpy'ing it.
