Problem: When there is any error Vim will use a non-zero exit code.
Solution: When using ":silent!" do not set the exit code. (Yasuhiro
Matsumoto)
8b778d5599
Regarding the individual items in the header:
`Vim - Vi improved by Bram Moolenar`
Bram Moolenar is already mentioned throughout the documentation, as
well as the intro screen.
`:help uganda`
It's already shown to all users who don't use `shortmess+=I` upon
starting nvim, and is already placed prominently in help.txt, i.e.,
`:help` run with no arguments.
`:help credits`
Already mentioned near the top of help.txt.
`README.md`
Already mentioned in develop.txt.
Making an environment variable empty can be a way of unsetting it for
platforms that don't support unsetenv(). In most cases, we treat empty
variables as having been unset. For all others, use os_env_exists().
We already use wrappers for allocation, the new `xfree` function is the
equivalent for deallocation and provides a way to fully replace the malloc
implementation used by Neovim.
Switching cursor off is only necessary in two occasions:
- When redrawing to avoid terminal flickering
- When the editor is busy
The first can now be handled by the TUI, so most calls to ui_cursor_off can be
removed from the core.
So, before this commit it was only necessary to switch the cursor off to notify
the user that nvim was running some long operation. Now the cursor_{on,off}
functions have been replaced by busy_{stop,start} which can be handled in a
UI-specific way(turning the cursor off or showing a busy indicator, for
example).
To make things even more simpler, nvim is always busy except when waiting for
user input or other asynchronous events: It automatically switches to a non-busy
state when the event loop is about to be entered for more than 100 milliseconds.
`ui_busy_start` can be called when its not desired to change the busy state in
the event loop (As its now done by functions that perform blocking shell
invocations).
Problem : Branch condition evaluates to a garbage value @ 2868.
Diagnostic : False positive.
Rationale : Array has_hotkey, declared at 2812, is initialized by
console_dialog_alloc (only the needed number of elements).
That same number of elements is used by
copy_hotkeys_and_msg.
Suggested path error is impossible, because it involves a
different number of elements in those functions.
Resolution : Above condition is cumbersome to prove through assertions.
Thus, we prefer to just initialize the array to all-false
at declaration point before calling console_dialog_alloc.
- Removed term.c, term.h and term_defs.h
- Tests for T_* values were removed. screen.c was simplified as a
consequence(the best strategy for drawing is implemented in the UI layer)
- Redraw functions now call ui.c functions directly. Updates are flushed with
`ui_flush()`
- Removed all termcap options(they now return empty strings for compatibility)
- &term/&ttybuiltin options return a constant value(nvim)
- &t_Co is still available, but it mirrors t_colors directly
- Remove cursor tracking from screen.c and the `screen_start` function. Now the
UI is expected to maintain cursor state across any call, and reset it when
resized.
- Remove unused code
Problem : Out-of-bounds access @ 3730.
Diagnostic : Real issue.
Rationale : str is constructed step by step, str_l growing each time.
str_m is the maximum length of str. So, at every step,
avail is computed to see if the piece to be added fits in.
If not, piece is truncated to a max of `avail`, so that str
stays in bounds. Such blocks where pieces are added are of
the form `if (str_l < str_m)`. It then follows that once
one of those pieces exhausts available space on str, no
other such block should be entered. Formally:
str_l < strl_m && avail = str_m - str_l && x >= avail
-->
str_l + x >= str_m
Now, suggested error path successively enters blocks where
str is exhausted. We're not sure if coverity just fails to
follow above implications, or, on the contrary, it's aware
of them, but it's signaling the more complex possibility of
implications not being fulfilled because of possible
arithmetic overflows. We opt then to assume this last case,
as the possibility is in fact there.
Resolution : Refactor code so that tracked condition doesn't depend on
arithmetic implications. Check for overflow.
- Remove abstract_ui global, now it is always active
- Remove some terminal handling code
- Remove unused functions
- Remove HAVE_TGETENT/TERMINFO/TERMIOS/IOCTL #ifdefs
- Remove tgetent/terminfo from version.c
- Remove curses/terminfo dependencies
- Only start/stop termcap when starting/exiting the program
- msg_use_printf will return true if there are no attached UIs(
messages will be written to stdout)
- Remove `ex_winpos`(implement `:winpos` with `ex_ni`)
These were found with -Wunused-macros. There are many more macros which
triggered that warning, but they were primarily part of larger sets of
macros so leave them alone.
Problem : Dereference of null pointer @ 179.
Diagnostic : False positive.
Rationale : Error occurs if `s` paramater is null, which should not
happen.
Resolution : Declare parameter as non null.
Also:
- Remove NO_CONSOLE_INPUT/NO_CONSULE preprocessor conditionals
- Remove ctrl_c_interrupts variable, check for mapped_ctrl_c directly in
process_interrupts()
- Move ui_inchar profiling to input_poll which is where Nvim blocks for input.
Two new functions, `event_enable_deferred()`/`event_disable_deferred()` have to
be called by code that is capable of handling asynchronicity. User-dialog states
like "press ENTER to continue" or the swap file confirmation no longer will
generate K_EVENT.
Problem : Dead assignment @ 3323.
Dead assignment @ 3587.
Diagnostic : Harmless issues.
Rationale : - 3323: Assignment is in fact dead. But, in addition to
that, `length_modifier` is assigned default value `\0`
when declared and is untouched in path leading to
signaled point. So, maintaining assignment adds nothing
to code.
- 3587: Assignment is in fact dead. It could be thought
that `precision_specified` has to be 1 in order to flag
`precision` as having a valid value. But that doesn't
seem to be the case, as there are places in the code
where `precision` gets assigned a default value, even if
`precision_specified` is 0. So, maintaining assignment
adds nothing to code.
Resolution : Remove dead assignments.
Problem : Dereference of null pointer @ 693.
Diagnostic : False positive.
Rationale : Error condition occurs if `delete_first_msg` is entered two
consecutive times, the firt of which sets leaves history
empty. But, in that case, second entrance should leave at
the `return FAIL`, and thus cannot reach the pointer
dereference.
Resolution : Assert history will be empty after first entrance.
- Remove all *_set_defer methods and the 'defer' flag from rstream/jobs
- Added {signal,rstream,job}_event_source functions. Each return a pointer that
represent the event source for the object in question(For signals, a static
pointer is returned)
- Added a 'source' field to the Event struct, which is set to the appropriate
value by the code that created the event.
- Added a 'sources' parameter to `event_poll`. It should point to a
NULL-terminated array of event sources that will be used to decide which
events should be processed immediately
- Added a 'source_override' parameter to `rstream_new`. This was required to use
jobs as event sources of RStream instances(When "focusing" on a job, for
example).
- Extracted `process_from` static function from `event_process`.
- Remove 'defer' parameter from `event_process`, which now operates only on
deferred events.
- Refactor `channel_send_call` to use the new lock mechanism
What changed in a single sentence: Code that calls `event_poll` have to specify
which event sources should NOT be deferred. This change was necessary for a
number of reasons:
- To fix a bug where due to race conditions, a client request
could end in the deferred queue in the middle of a `channel_send_call`
invocation, resulting in a deadlock since the client process would never
receive a response, and channel_send_call would never return because
the client would still be waiting for the response.
- To handle "event locking" correctly in recursive `channel_send_call`
invocations when the frames are waiting for responses from different
clients. Not much of an issue now since there's only a python client, but
could break things later.
- To simplify the process of implementing synchronous functions that depend on
asynchronous events.
