vim-patch:8.0.0469: compiler warnings on MS-Windows
Problem: Compiler warnings on MS-Windows.
Solution: Add type casts. (Christian Brabandt)
0c0d4eca4d
vim-patch:8.0.0581: moving folded text is sometimes not correct
Problem: Moving folded text is sometimes not correct.
Solution: Bail out when "move_end" is zero. (Matthew Malcomson)
94be619e30
vim-patch:8.0.0583: fold test hangs on MS-Windows
Problem: Fold test hangs on MS-Windows.
Solution: Avoid overflow in compare.
b11c826ddc
Problem: ml_get errors in silent Ex mode. (Dominique Pelle)
Solution: Clear valid flags when setting the cursor. Set the topline when
not in full screen mode.
d5d37537d1
Closes#6540
In #6221 there was a mistake in calculating which folds need to be
re-ordered. When there are no folds after those that have been adjusted,
then `move_end` remains 0. This results in reverse_fold_order()
swapping folds that have been adjusted with uninitialised folds in the
remainder of the grow array.
Add a check in foldMoveRange() to account for this case.
When foldUpdateIEMSRecurse() re-uses an existing fold, it misses the
case where the existing fold spans from before startlnum to after
firstlnum, the new fold does not span this range, and there is no
"forced start" of a fold. We add a case for this in.
Ensure that if there was no forced break in folds, we merge folds that
now touch each other.
Include testing for a tricky foldmethod=expr case that has never been a
bug. This case works at the moment because of some effects that are not
obvious when reading the code.
A test for this could be useful to ensure a regression doesn't happen.
vim-patch:8.0.0408
In order to re-order marks according to the :move command, do_move()
uses mark_adjust() in a non-standard manner. The non-standard action is
that it moves some marks *past* other marks. This doesn't matter for
marks, but mark_adjust() calls foldMarkAdjust() which simply changes
fold starts and lengths and doesn't have enough information to know that
other folds have to be checked and reordered.
The array of folds for each window are assumed to be in order of
increasing line number, and if this gets broken some folds can get
"lost".
There has been a previous patch to avoid this problem by deleting and
recalculating all folds in the window, but this comes at the cost of
closing all folds when executing :move, and doesn't cover the case of
manual folds.
This patch adds a new function foldMoveRange() specifically for the
:move command that handles reordering folds as well as simply moving
them. Additionally, we allow calling mark_adjust_nofold() that does the
same as mark_adjust() but doesn't affect any fold array.
Calling mark_adjust_nofold() should be done in the same manner as
calling mark_adjust(), but according changes to the fold arrays must be
done seperately by the calling function.
vim-patch:8.0.0457
vim-patch:8.0.0459
vim-patch:8.0.0461
vim-patch:8.0.0465
Fix a problem when filtering manually folded lines
When foldMarkAdjustRecurse() is called to adjust folds that start inside
the range of lines that are being moved and end outside that range, it
calculates `amount_after` for its recursive call incorrectly.
The calculation assumes that folds inside the changed range are being
deleted, but this is not always the case.
This means nested folds that start after the changed range of lines are
shifted an incorrect amount.
We fix this by calculating the `amount_after` differently if the folds
inside the changed range are not being deleted.
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>
move `call_shell` to misc1.c
Move some fns to state.c
Move some fns to option.c
Move some fns to memline.c
Move `vim_chdir*` fns to file_search.c
Move some fns to new module, bytes.c
Move some fns to fileio.c
Problem: More problems reported by coverity.
Solution: Avoid the warnings. (Christian Brabandt)
cde8854730
Applied manually. Files that do not exst anymore: gui.c gui_w16.c gui_w32.c
if_xcmdsrv.c os_unix.c
Problem: Fold can't be opened after ":move". (Ein Brown)
Solution: Delete the folding information and update it afterwards.
(Christian Brabandt)
d5f6933d5c
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.
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.
This commit integrates libvterm with Neovim and implements a terminal emulator
with nvim buffers as the display mechanism. Terminal buffers can be created
using any of the following methods:
- Opening a file with name following the "term://[${cwd}//[${pid}:]]${cmd}"
URI pattern where:
- cwd is the working directory of the process
- pid is the process id. This is just for use in session files where a pid
would have been assigned to the saved buffer title.
- cmd is the command to run
- Invoking the `:terminal` ex command
- Invoking the `termopen` function which returns a job id for automating the
terminal window.
Some extra changes were also implemented to adapt with terminal buffers. Here's
an overview:
- The `main` function now sets a BufReadCmd autocmd to intercept the term:// URI
and spawn the terminal buffer instead of reading the file.
- terminal buffers behave as if the following local buffer options were set:
- `nomodifiable`
- `swapfile`
- `undolevels=-1`
- `bufhidden=hide`
- All commands that delete buffers(`:bun`, `:bd` and `:bw`) behave the same for
terminal buffers, but only work when bang is passed(eg: `:bwipeout!`)
- A new "terminal" mode was added. A consequence is that a new set of mapping
commands were implemented with the "t" prefix(tmap, tunmap, tnoremap...)
- The `edit` function(which enters insert mode) will actually enter terminal
mode if the current buffer is a terminal
- The `put` operator was adapted to send data to the terminal instead of
modifying the buffer directly.
- A window being resized will also trigger a terminal resize if the window
displays the terminal.
Problem : Dereference of null pointer @ 1701.
Diagnostic : False positive.
Rationale : Comparison `last_wp != wp` just after initializing
`last_wp` to NULL makes the compiler think `wp` can be
null. Error appears then on codepath assuming comparison is
false (i.e. `wp` is null).
Resolution : Change order of OR clauses.
That seems not to give motives for the analyzer to check
the `wp` null path and removes the warning.
But potential null dereference is still there, so we add
the nonnull annotation to `wp` parameter.
