Problem: Cursor position wrong when splitting window in insert mode.
Solution: Pass the actual mode to win_fix_cursor(). (Luuk van Baal,
closesvim/vim#11999,
bc3dc298b3
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Problem: Scrolling two lines with even line count and 'scrolloff' set.
Solution: Adjust how the topline is computed. (closesvim/vim#10545)
1d6539cf36
Cherry-pick test_scroll_opt.vim changes from patch 8.2.1432.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
ci: add GCC release testing
We currently have no release testing, so it's good to check for any
unwanted behavior on release builds as well. Prefer GCC over clang, as
GCC release builds seem to create more warnings on release compared to
debug.
According to [AppStream spec](https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-id-generic),
the <id> element should contain a reverse-DNS scheme:
{tld}.{vendor}.{product}
Since the flathub requires that, the flatpak build replaces `<id>nvim</id>` with
`<id>io.neovim.nvim</id>`. That results in ID mismatch between flatpak version
and version from distribution's repositories. Because of that, software stores
are displaying two different neovims, instead of one neovim with options to
download it either from flatpak or from distribution's repos. We can use the
`<provides><id>nvim</id></provides>`, for everyone who was expecting the id to
be `nvim`.
Problem: After TUI refactor commit, code for setting Windows taskbar
icon wasn't being executed because of a backdated conditional.
Solution: Update the conditional to take TUI refactor into account.
Ref: https://github.com/neovim/neovim/pull/20634#discussion_r1088993820
This variable was only meant for easy testing during the development
cycle for treesitter highlighting while Lua was the only parser useable
for daily driving. Now that we have a good vimdoc parser, this approach
simply doesn't scale and should be removed sooner rather than later.
Instead of setting this variable, people for now should add the autocommand
directly to their config:
```lua
vim.api.nvim_create_autocmd('FileType', {
pattern = 'lua', -- or { 'lua', 'help' }
callback = function() vim.treesitter.start() end,
})
```
(or put `vim.treesitter.start()` in an `ftplugin`).
This fixes two clang warnings.
Using an unintialized "cursorline_fi" without assigning to it is not
something that should normally happen, and in case it happens it will
likely cause another redraw, but still don't use unintialized memory.
Problem:
The sleep before collecting the initial screen state is confusing and
may lead to unexpected success if it comes after a blocking RPC call.
Solution:
Remove that sleep and add an "intermediate" argument.
Problem:
Validation messages are not consistently formatted.
- Parameter names sometimes are NOT quoted.
- Descriptive names (non-parameters) sometimes ARE quoted.
Solution:
Always quote the `name` value passed to a VALIDATE macro _unless_ the
value has whitespace.
Problem: uv_tty_set_mode on stdout in Windows exits with error.
Cause: Windows cannot set the properties of the output of a tty.
Solution: Remove call to uv_tty_set_mode.
Ref: #21445
Ref: 88634c1405 (r100598822)
In Windows, library DLL's are copied in the building process, and a message for each copy is printed. This is useful to have in the log of CI, but annoying to see when you're building and rebuilding nvim constantly. Work around this issue by only enabling the messages on CI.
Problem:
- API validation involves too much boilerplate.
- API validation errors are not consistently worded.
Solution:
Introduce some macros. Currently these are clumsy, but they at least
help with consistency and avoid some nesting.
Problem: The cursorline highlight logic checks for `w_cursor.lnum`
which may be different from the line number passed to
`win_line()` even when the cursor is actually on that line.
Solution: Update cursor line highlight logic to check for the line
number of the start of a closed fold if necessary.
If nothing matched in match_from_hashbang, also check the file extension table.
For a hashbang like '#!/bin/env foo', this will set the filetype to 'fooscript'
assuming the filetype for the 'foo' extension is 'fooscript' in the extension
table.
We need higher level and more meaningful cmake options. Having a cmake
option for only controlling compiler flags is probably not worth it as
the same can be achieved with:
cmake -B build -D CMAKE_C_FLAGS=<compiler option>
Detect if on CI by checking that the CI environment variable is set to "true".
This is a common pattern among CI providers, including github actions and
cirrus.
Problem:
When not inside an Ex command, screen_resize() calls update_screen(),
which calls screenclear() and set the screen as valid. However, when
inside an Ex command, redrawing is postponed so update_screen() screen
doesn't do anything, and the screen is still invalid after the resize,
causing ui_comp_raw_line() to be no-op until update_screen() is called
on the main loop.
Solution:
Restore the call to screenclear() inside screen_resize() so that the
screen is invalid after screen_resize(). Since screenclear() changes
redraw type from UPD_CLEAR to UPD_NOT_VALID, it is called at most once
for each resize, so this shouldn't change how much code is run in the
common (not inside an Ex command) case.
Having CI scripts that is separate from the build system causes
tremendous amounts of problems, headaches and bugs. Testing the validity
of the scripts locally become near impossible as time goes on as they're
only vetted if it works on whatever CI provider we happened to have at
the time, with their own quirks and behavior.
The extra indirection between "cmake <-> general CI scripts <-> GHA" is
also a frequent source of problems, as the orchestration needs to be
done with environment variables, cmake flags and github actions matrix
strategy. This combination has turned out to be exceptionally fragile.
Examples:
15394b685513aa23b62ahttps://github.com/neovim/neovim/pull/22072#discussion_r1094390713
A lot of the code was inlined to .github/workflows/ci.yml without
further modifications. While this in itself doesn't integrate with our
build system any more than the current situation, it does
1. remove a level of indirection, and more importantly
2. allow us to slowly start integrating the CI into our build system now
that all the relevant code is in one place.
* ci: show all logs at the end of a run
The current CI won't show the logs on error due to early exit. This will
at least show the logs, although for all tests at once.