bf21df1c7b
Problem: close_buffer() callers incorrectly handle b_nwindows,
especially after nasty autocmds, allowing it to go
out-of-sync. May lead to buffers that can't be unloaded, or
buffers that are prematurely freed whilst displayed.
Solution: Modify close_buffer() and review its callers; let them
decrement b_nwindows if it didn't unload the buffer. Remove
some now unneeded workarounds like 8.2.2354, 9.1.0143,
9.1.0764, which didn't always work (Sean Dewar)
close_buffer() now doesn't decrement b_nwindows when not unloading buf, or when
buf isn't w_buffer after autocmds (they would've already decremented it).
Callers are now expected to decrement b_nwindows if w_buffer is not NULL after
close_buffer(), and when still intending to switch buffers or close win, for two
reasons:
- close_buffer() autocmds may have switched buffers. The new w_buffer's
b_nwindows would also need decrementing.
- After close_buffer(), callers may opt to not switch w_buffer or close win.
b_nwindows would need to be incremented again. (unless w_buffer is NULL from
being unloaded; callers are already forced to find a new buffer then)
These were the main causes of b_nwindows bugs, as these cases could not be
reliably detected, and went largely unhandled.
NOTE: if close_buffer() autocmds switch buffers, close_buffer() is not called
for that new buffer before decrementing b_nwindows. This may skip side-effects
like from 'bufhidden', but I think it's mostly harmless, and was already
happening in other places.
Let's see how this goes... Other details: (I have lots to say!)
It's OK to pass a win to close_buffer() that isn't showing buf (used by
set_curbuf()). In that case, we skip some side-effects and don't decrement
b_nwindows, but may still unload buf if hidden.
buf_freeall() now returns whether it freed anything. Removes some repeated
checks in close_buffer().
Preserve close_buffer()'s behaviour when called by win_free_popup() after its
popup was already removed from the window list. This made win_valid_any_tab()
return FALSE, so we skip things that originally checked it in that case.
Add "set_context" to close_buffer() to preserve do_ecmd()'s behaviour of only
setting b_last_cursor and/or calling buflist_setfpos() when not splitting
(see 7.2.041: https://groups.google.com/g/vim_dev/c/ZGgNvaylNzI/m/WHxjhnuxqB0J)
Without this, Test_marks_cmd() fails from its ' mark differing. Don't use
oldwin though; it's not always the window with the closed buf, especially
after BufLeave autocmds in do_ecmd(). Also, only set context if win is really
displaying buf.
Don't bail in do_ecmd() if buf was deleted but curwin->w_buffer is NULL; that
leaves curwin open to a NULL buffer! Use lastbuf instead, like set_curbuf().
I don't think it's possible for buf to be deleted by close_buffer() anyway, as
b_locked was set (which I can't see a way to bypass, unlike b_locked_split).
Maybe such checks can be removed, but I'd rather not risk that here.
Don't set curwin to previouswin in set_curbuf(); shouldn't be needed, otherwise
may lead to curbuf != curwin->w_buffer if autocmds switch to a window showing
buf, as that skips enter_buffer()? Was introduced back in 7.3.557 to avoid
cases where autocmds switch windows, possibly leaving previouswin with a NULL
buffer. Since 7.4.2312 and 7.4.2328, close_buffer() and buf_freeall() already
handles this. I've added an assert() as a sanity check anyway.
In free_all_mem(), set b_nwindows to 0 before close_buffer() so buffers can be
wiped if still in a window before win_free_all(). Needed as close_buffer() now
skips unloading buffers that aren't hidden if win is NULL. If it's possible for
free_all_mem()'s :tabonly! and :only! to not close all windows before freeing,
then this issue was also previously possible if b_nwindows > 1.
related: #19728
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Vim source code
Here are a few hints for finding your way around the source code. This doesn't make it less complex than it is, but it gets you started.
You might also want to read
:help development.
Jumping around
First of all, use :make tags to generate a tags file, so that you can jump
around in the source code.
To jump to a function or variable definition, move the cursor on the name and
use the CTRL-] command. Use CTRL-T or CTRL-O to jump back.
To jump to a file, move the cursor on its name and use the gf command.
Most code can be found in a file with an obvious name (incomplete list):
| File name | Description |
|---|---|
| alloc.c | memory management |
| arglist.c | handling argument list |
| autocmd.c | autocommands |
| blob.c | blob data type |
| buffer.c | manipulating buffers (loaded files) |
| bufwrite.c | writing a buffer to file |
| change.c | handling changes to text |
| cindent.c | C and Lisp indentation |
| clientserver.c | client server functionality |
| clipboard.c | handling the clipboard |
| cmdexpand.c | command-line completion |
| cmdhist.c | command-line history |
| debugger.c | Vim script debugger |
| diff.c | diff mode (vimdiff) |
| drawline.c | drawing a window line |
| drawscreen.c | drawing the windows |
| eval.c | expression evaluation |
| evalbuffer.c | buffer related built-in functions |
| evalfunc.c | built-in functions |
| evalvars.c | vim variables |
| evalwindow.c | window related built-in functions |
| fileio.c | reading and writing files |
| filepath.c | dealing with file names and paths |
| findfile.c | search for files in 'path' |
| fold.c | folding |
| fuzzy.c | fuzzy matching |
| getchar.c | getting characters and key mapping |
| gc.c | garbage collection |
| help.c | vim help related functions |
| highlight.c | syntax highlighting |
| indent.c | text indentation |
| insexpand.c | Insert mode completion |
| locale.c | locale/language handling |
| map.c | mapping and abbreviations |
| mark.c | marks |
| match.c | highlight matching |
| float.c | floating point functions |
| mbyte.c | multi-byte character handling |
| memfile.c | storing lines for buffers in a swapfile |
| memline.c | storing lines for buffers in memory |
| menu.c | menus |
| message.c | (error) messages |
| mouse.c | handling the mouse |
| ops.c | handling operators ("d", "y", "p") |
| option.c | options |
| optionstr.c | handling string options |
| popupmenu.c | popup menu |
| popupwin.c | popup window |
| profiler.c | Vim script profiler |
| quickfix.c | quickfix commands (":make", ":cn") |
| regexp.c | pattern matching |
| register.c | handling registers |
| scriptfile.c | runtime directory handling and sourcing scripts |
| screen.c | lower level screen functions |
| search.c | pattern searching |
| session.c | sessions and views |
| sign.c | signs |
| spell.c | spell checking core |
| spellfile.c | spell file handling |
| spellsuggest.c | spell correction suggestions |
| strings.c | string manipulation functions |
| syntax.c | syntax and other highlighting |
| tag.c | tags |
| term.c | terminal handling, termcap codes |
| testing.c | testing: assert and test functions |
| textformat.c | text formatting |
| textobject.c | text objects |
| textprop.c | text properties |
| time.c | time and timer functions |
| typval.c | Vim script type/value functions |
| undo.c | undo and redo |
| usercmd.c | user defined commands |
| userfunc.c | user defined functions |
| viminfo.c | viminfo handling |
| window.c | handling split windows |
Debugging
If you have a reasonable recent version of gdb, you can use the :Termdebug
command to debug Vim. See :help :Termdebug.
When something is time critical or stepping through code is a hassle, use the channel logging to create a time-stamped log file. Add lines to the code like this:
ch_log(NULL, "Value is now %02x", value);
After compiling and starting Vim, do:
:call ch_logfile('debuglog', 'w')
And edit debuglog to see what happens. The channel functions already have
ch_log() calls, thus you always see that in the log.
Important Variables
The current mode is stored in State. The values it can have are NORMAL,
INSERT, CMDLINE, and a few others.
The current window is curwin. The current buffer is curbuf. These point
to structures with the cursor position in the window, option values, the file
name, etc. These are defined in
structs.h.
All the global variables are declared in
globals.h.
The main loop
This is conveniently called main_loop(). It updates a few things and then
calls normal_cmd() to process a command. This returns when the command is
finished.
The basic idea is that Vim waits for the user to type a character and
processes it until another character is needed. Thus there are several places
where Vim waits for a character to be typed. The vgetc() function is used
for this. It also handles mapping.
Updating the screen is mostly postponed until a command or a sequence of
commands has finished. The work is done by update_screen(), which calls
win_update() for every window, which calls win_line() for every line.
See the start of
screen.c
for more explanations.
Command-line mode
When typing a :, normal_cmd() will call getcmdline() to obtain a line
with an Ex command. getcmdline() contains a loop that will handle each typed
character. It returns when hitting CR or Esc or some other character that
ends the command line mode.
Ex commands
Ex commands are handled by the function do_cmdline(). It does the generic
parsing of the : command line and calls do_one_cmd() for each separate
command. It also takes care of while loops.
do_one_cmd() parses the range and generic arguments and puts them in the
exarg_t and passes it to the function that handles the command.
The : commands are listed in ex_cmds.h. The third entry of each item is
the name of the function that handles the command. The last entry are the
flags that are used for the command.
Normal mode commands
The Normal mode commands are handled by the normal_cmd() function. It also
handles the optional count and an extra character for some commands. These
are passed in a cmdarg_t to the function that handles the command.
There is a table nv_cmds in
normal.c
which lists the first character of every command. The second entry of each
item is the name of the function that handles the command.
Insert mode commands
When doing an i or a command, normal_cmd() will call the edit()
function. It contains a loop that waits for the next character and handles it.
It returns when leaving Insert mode.
Options
There is a list with all option names in
option.c,
called options[].
The GUI
Most of the GUI code is implemented like it was a clever terminal. Typing a
character, moving a scrollbar, clicking the mouse, etc. are all translated
into events which are written in the input buffer. These are read by the
main code, just like reading from a terminal. The code for this is scattered
through gui.c.
For example, gui_send_mouse_event() for a mouse click and gui_menu_cb() for
a menu action. Key hits are handled by the system-specific GUI code, which
calls add_to_input_buf() to send the key code.
Updating the GUI window is done by writing codes in the output buffer, just
like writing to a terminal. When the buffer gets full or is flushed,
gui_write() will parse the codes and draw the appropriate items. Finally the
system-specific GUI code will be called to do the work.
Debugging the GUI
Remember to prevent that gvim forks and the debugger thinks Vim has exited,
add the -f argument. In gdb: run -f -g.
When stepping through display updating code, the focus event is triggered
when going from the debugger to Vim and back. To avoid this, recompile with
some code in gui_focus_change() disabled.
Contributing
If you would like to help making Vim better, see the
CONTRIBUTING.md
file.
This is README.md for version 9.2 of the Vim source code.