| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: buffer text with composing chars are converted from UTF-8
to an array of up to seven UTF-32 values and then converted back
to UTF-8 strings.
Solution: Convert buffer text directly to UTF-8 based schar_T values.
The limit of the text size is now in schar_T bytes, which is currently
31+1 but easily could be raised as it no longer multiplies the size
of the entire screen grid when not used, the full size is only required
for temporary scratch buffers.
Also does some general cleanup to win_line text handling, which was
unnecessarily complicated due to multibyte rendering being an "opt-in"
feature long ago. Nowadays, a char is just a char, regardless if it consists
of one ASCII byte or multiple bytes.
|
| |
|
|
|
|
|
|
|
| |
Problem: Cannot accurately get mouse clicking position when clicking on
a TAB or with virtual text.
Solution: Add a "coladd" field to getmousepos() result.
closes: vim/vim#13335
https://github.com/vim/vim/commit/f5a94d5165bb9e390797da50a1fa7a87df3fbee4
|
| |
|
|
|
|
|
| |
Problem: Peeking and flushing output slows down execution.
Solution: Do not update the mode message when global_busy is set. Do not
flush when only peeking for a character. (Ken Takata)
https://github.com/vim/vim/commit/cb574f415486adff645ce384979bfecf27f5be8c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'arabicshape' feature of vim is a transformation of unicode text to
make arabic and some related scripts look better at display time. In
particular the content of a cell will be adjusted depending on the
(original) content of the cells just before and after it.
This is implemented by the arabic_shape() function in nvim. Before this
commit, shaping was invoked in four different contexts:
- when rendering buffer text in win_line()
- in line_putchar() for rendering virtual text
- as part of grid_line_puts, used by messages and statuslines and
similar
- as part of draw_cmdline() for drawing the cmdline
This replaces all these with a post-processing step in grid_put_linebuf(),
which has become the entry point for all text rendering after recent
refactors.
An aim of this is to make the handling of multibyte text yet simpler.
One of the main reasons multibyte chars needs to be "parsed" into
codepoint arrays of composing chars is so that these could be inspected
for the purpose of shaping. This can likely be vastly simplified in many
contexts where only the total length (in bytes) and width of composed
char is needed.
|
| | |
|
| |
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
| | |
|
| | |
|
| |
|
| |
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Also combine high-priority CursorLine with Folded.
|
| |
|
| |
Note: CursorLine highlight is now combined with Folded.
|
| |
|
|
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: famiu <famiuhaque@protonmail.com>
|
| |
|
|
|
| |
- Close and open a new window each time so that window options have
their default values in each test.
- Change feed_command() to command() as the latter is faster.
|
| | |
|
| |
|
|
|
|
|
|
| |
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: 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: When a folded line has virtual lines attached, the following
problems occur:
- The virtual lines are drawn empty.
- The 'foldtext' line is drawn empty.
- The cursor is drawn incorrectly.
Solution: Check whether virtual lines belong to a folded line.
Fix #17027
Fix #19557
Fix #21837
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem: Not enough folding code is tested.
Solution: Add more test cases. (Yegappan Lakshmanan, closes vim/vim#8046)
https://github.com/vim/vim/commit/5c504f680e63120fea36becfabb8d939d4449e34
Reorder test_fold.vim to match upstream.
Cherry-pick Test_fold_expr_error() from patch 8.2.0633.
Cherry-pick syntax feature check from patch 8.2.1432.
Cherry-pick a delete() call from patch 8.2.2112.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Avoids using `gui=reverse` on `VertSplit` and makes window separators
look much nicer by default.
|
| |
|
|
| |
Co-authored-by: Jordan Haine <jhaine@securitycompass.com>
|
| | |
|
| |
|
|
|
|
| |
Problem: CursorLine highlight used while 'cursorline' is off.
Solution: Check 'cursorline' is set. (cloes vim/vim#5017)
https://github.com/vim/vim/commit/49474ca12236776bb56aeb9d39bd6592e28157c7
|
| | |
|
| |
|
|
|
|
|
| |
* Fix click on foldcolumn if it has tabline
* Fixes to correctly determine if tablie was clicked when multigrid is enabled
* Separate foldcolumn checks into functions
* Add test case for click on foldcolumn with split window
* Fix foldcolumn click used nvim_input() on multigrid enabled
|
| |
|
|
|
|
| |
"set foldcolumn=auto" is documented but not supported.
Support it by making it behave as "auto:1", similar to "signcolumn".
Close https://github.com/neovim/neovim/pull/13561
|
| |
|
|
| |
the highlight was not used with spell enabled on folded lines.
Thanks to lervag for the nice report.
|
| |
|
|
|
| |
Partially addresses https://github.com/neovim/neovim/issues/12982. It's
more a quickfix while reworking folds.
|
| | |
|
| |
|
|
| |
fixes #12988.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
as well as copy_text_attr, text_to_screenline.
Display of folded line is now done via win_line, which reduces code
deduplication.
As fold_line was a trimmed down version of win_line, this change brings
new features such CursorLineNr highighting even on folded line, as well
as CursorLine highlighting.
|
| |
|
|
|
|
|
|
| |
Similar to signcolumn, allow foldcolumn to adapt itself to the number of
folds.
Regression:
vim supports a maximum fdc of 12, this limits it to 9.
|
| |
|
|
|
| |
would previously only work with ascii fillchars.
Added a test.
|
| |
|
|
|
| |
You can try it with
set fillchars+=foldopen:▾,foldsep:│,foldclose:▸
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It is perfectly fine and expected to detach from the screen just by
the UI disconnecting from nvim or exiting nvim. Just keep detach() in
screen_basic_spec, to get some coverage of the detach method itself.
This avoids hang on failure in many situations (though one could argue
that detach() should be "fast", or at least "as fast as resize",
which works in press-return already).
Never use detach() just to change the size of the screen, try_resize()
method exists for that specifically.
|
| |
|
|
|
|
|
|
| |
* screen: Fix to draw signs with combining characters.
The buffer size for signs can be too small, because the upper length
limit of a sign can be 56 bytes. If combining characters are only two
bytes in size, this reduces to 32 bytes.
* screen: Adjust buffer size to maximal sign column count
|
| |
|
|
|
|
|
|
|
|
|
|
| |
confusing (#9816)
Problem: Extending sign and foldcolumn below the text is confusing.
Solution: Let the sign and foldcolumn stop at the last text line, just like
the line number column. Also stop the command line window leader.
(Christian Brabandt)
https://github.com/vim/vim/commit/8ee4c01b8c79a29065c1af05e5d9c0721069765f
Closes https://github.com/neovim/neovim/issues/9613
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: When 'rnu' is set folded lines are not displayed correctly.
(Vitaly Yashin)
Solution: When only redrawing line numbers do draw folded lines.
(closes vim/vim#3484)
https://github.com/vim/vim/commit/7701f308565fdc7b5096a6597d9c3b63de0bbcec
---
Explanation:
Before this patch, relative line numbers would update on a cursor
movement and overwrite fold highlighting in the line number columns.
Other operations can cause the fold highlighting to overwrite the line
number styles. Together, this causes the highlighting in the line number
columns to flicker back and forth while editing.
Test case: create `t.vim` with these contents:
set fdm=marker rnu foldcolumn=2
call setline(1, ["{{{1", "nline 1", "{{{1", "line 2"])
and then call `nvim -u NORC -S t.vim` and press `j`; observe that the fold
highlighting disappears.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid clearing the screen in most situations. NOT_VALID should be
equivalent to CLEAR unless some external force messed up the terminal,
for these situations <c-l> and :mode will still clear the screen.
Also eliminate some obsolete code in screen.c, that dealt with that in
vim drawing window 1 can mess up window 2, but this never happens in
nvim.
But what about slow terminals? There is two common meanings in which
a terminal is said to be "slow":
Most commonly (and in the sense of vim:s nottyfast) it means low
bandwidth for sending bytes from nvim to the terminal. If the screen is
very similar before and after the update_screen(CLEAR) this change
should reduce bandwidth. If the screen is quite different, but there is
no new regions of contiguous whitespace, clearing doesn't reduce
bandwidth significantly. If the new screen contains a lot of whitespace,
it will depend of if vsplits are used or not: as long as there is no
vsplits, ce is used to cheaply clear the rest of the line, so
full-screen clear is not needed to reduce bandwith. However a left
vsplit currently needs to be padded with whitespace all the way to the
separator. It is possible ec (clear N chars) can be used to reduce
bandwidth here if this is a problem. (All of this assumes that one
doesn't set Normal guibg=... on a non-BCE terminal, if you do you are
doomed regardless of this change).
Slow can also mean that drawing pixels on the screen is slow. E-ink
screens is a recent example. Avoiding clearing and redrawing the
unchanged part of the screen will always improve performance in these
cases.
|
| | |
|
