When the contents of a quickfix buffer are replaced, there is a chance
that deletion of the previous lines fails. This ensures that we don't
get stuck in an infinite loop of retrying.
Fix#25402
long is 32 bits on windows, while it is 64 bits on other architectures.
This makes the type suboptimal for a codebase meant to be
cross-platform. Replace it with more appropriate integer types.
Problem: cannot use buffer-number for errorformat
Solution: add support for parsing a buffer number using '%b' in
'errorformat'
closes: vim/vim#13419b731800522
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
long is 32 bits on windows, while it is 64 bits on other architectures.
This makes the type suboptimal for a codebase meant to be
cross-platform. Replace it with more appropriate integer types.
- Move vimoption_T to option.h
- option_defs.h is for option-related types
- option_vars.h corresponds to Vim's option.h
- option_defs.h and option_vars.h don't include each other
Most of the messy things when changing a non-current buffer is
not about the buffer, it is about windows. In particular, it is about
`curwin`.
When editing a non-current buffer which is displayed in some other
window in the current tabpage, one such window will be "borrowed" as the
curwin. But this means if two or more non-current windows displayed the buffers,
one of them will be treated differenty. this is not desirable.
In particular, with nvim_buf_set_text, cursor _column_ position was only
corrected for one single window. Two new tests are added: the test
with just one non-current window passes, but the one with two didn't.
Two corresponding such tests were also added for nvim_buf_set_lines.
This already worked correctly on master, but make sure this is
well-tested for future refactors.
Also, nvim_create_buf no longer invokes autocmds just because you happened
to use `scratch=true`. No option value was changed, therefore OptionSet
must not be fired.
ml_get_buf() takes a third parameters to indicate whether the
caller wants to mutate the memline data in place. However
the vast majority of the call sites is using this function
just to specify a buffer but without any mutation. This makes
it harder to grep for the places which actually perform mutation.
Solution: Remove the bool param from ml_get_buf(). it now works
like ml_get() except for a non-current buffer. Add a new
ml_get_buf_mut() function for the mutating use-case, which can
be grepped along with the other ml_replace() etc functions which
can modify the memline.
Problem: Quickfix text field is truncated.
Solution: Fix output of text field after pattern field in quickfix buffer.
(Shane Harper, closesvim/vim#12498)
5bf042810b
Co-authored-by: Shane Harper <shane@shaneharper.net>
Removes the `getoption_T` struct and also introduces the `OptVal` struct
to unify the methods of getting/setting different option value types.
This is the first of many PRs to reduce code duplication in the Vim
option code as well as to make options easier to maintain. It also
increases the flexibility and extensibility of options. Which opens the
door for things like Array and Dictionary options.
Problem: Using uninitialized memory with fuzzy matching.
Solution: Initialize the arrays used to store match positions.
caf642c25d
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Handling new value of an option has a long "else if" chain.
Solution: Use a function pointer. (Yegappan Lakshmanan, closesvim/vim#12015)
af93691b53
Problem: Vim9: no line break allowed in a for loop.
Solution: Skip line breaks in for command.
b7a78f7a67
Omit *_break_count and skip_for_lines(): Vim9 script only.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: leaking memory when using continuation line.
Solution: Keep a pointer to the continuation line in evalarg_T. Centralize
checking for a next command.
b171fb1790
Omit eval_next_line(): Vim9 script only.
vim-patch:8.2.1050: missing change in struct
Problem: Missing change in struct.
Solution: Add missing change.
65a8ed37f7
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: script cannot use line continuation like in a :def function.
Solution: Pass the getline function pointer to the eval() functions. Use it
for addition and multiplication operators.
5409f5d8c9
Omit source_nextline() and eval_next_non_blank(): Vim9 script only.
N/A patches for version.c:
vim-patch:8.2.1048: build failure without the eval feature
Problem: Build failure without the eval feature.
Solution: Add dummy typedef.
9d40c63c7d
vim-patch:8.2.1052: build failure with older compilers
Problem: Build failure with older compilers.
Solution: Move declaration to start of block.
7acde51832
Co-authored-by: Bram Moolenaar <Bram@vim.org>
vim-patch:8.2.0695: Vim9: cannot define a function inside a function
Problem: Vim9: cannot define a function inside a function.
Solution: Initial support for :def inside :def.
04b1269783
vim-patch:8.2.0725: Vim9: cannot call a function declared later in Vim9 script
Problem: Vim9: cannot call a function declared later in Vim9 script.
Solution: Make two passes through the script file.
09689a0284
vim-patch:8.2.0734: Vim9: leaking memory when using :finish
Problem: Vim9: leaking memory when using :finish.
Solution: Do not check for next line in third pass.
04816717df
vim-patch:8.2.0753: Vim9: expressions are evaluated in the discovery phase
Problem: Vim9: expressions are evaluated in the discovery phase.
Solution: Bail out if an expression is not a constant. Require a type for
declared constants.
32e351179e
vim-patch:8.2.0818: Vim9: using a discovery phase doesn't work well
Problem: Vim9: using a discovery phase doesn't work well.
Solution: Remove the discovery phase, instead compile a function only when
it is used. Add :defcompile to compile def functions earlier.
822ba24743
vim-patch:8.2.0819: compiler warning for unused variable
Problem: Compiler warning for unused variable.
Solution: Remove the variable.
f40e51a880
vim-patch:8.2.0822: Vim9: code left over from discovery phase
Problem: Vim9: code left over from discovery phase.
Solution: Remove the dead code.
2eec37926d
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Get E967 when using text property in quickfix window. (Sergey
Vlasov)
Solution: Do not add an extra NUL and compute the text length correctly.
(closesvim/vim#11513)
2f7bfe66a1
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Alloc/free of buffer for each quickfix entry is inefficient.
Solution: Use a shared grow array. (Yegappan Lakshmanan, closesvim/vim#11365)
975a665d48
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Quickfix listing does not handle very long messages.
Solution: Use a growarray instead of a fixed size buffer. (Yegappan
Lakshmanan, closesvim/vim#11357)
f8412c9d7c
Override Test_very_long_error_line() with a rewrite that doesn't use
deferred delete and string interpolation.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem:
The "force" flag of win_close() complicates the code and adds edge cases
where it is not clear what the correct behavior should be.
The "free_buf" flag of win_close() is passed on to float windows when
closing the last window of a tabpage, which doesn't make much sense.
Solution:
Remove the "force" flag and always close float windows as if :close! is
used when closing the last window of a tabpage, and set the "free_buf"
flag for a float window based on whether its buffer can be freed.
As 'hidden' is on by default, this change shouldn't affect many people.
Problem: Code is indented more than necessary.
Solution: Use an early return where it makes sense. (Yegappan Lakshmanan,
closesvim/vim#11833)
f97a295cca
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Crash when no errors and 'quickfixtextfunc' is set.
Solution: Do not handle errors if there aren't any.
4f1b083be4
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Filetype autocmd may cause freed memory access.
Solution: Set the quickfix-busy flag while filling the buffer.
d0fab10ed2
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Using one window for executing autocommands is insufficient.
Solution: Use up to five windows for executing autocommands.
e76062c078
N/A patches for version.c:
vim-patch:9.0.0966: some compilers don't allow a declaration after a label
Problem: Some compilers don't allow a declaration after a label.
Solution: Move the declaration to the start of the block. (John Marriott)
f86490ed4f
Co-authored-by: Bram Moolenaar <Bram@vim.org>