Commit Graph

529 Commits

Author SHA1 Message Date
59e1d7f353 patch 9.1.1625: Autocompletion slow with include- and tag-completion
Problem:  Autocompletion slow with include- and tag-completion
Solution: Refactor ins_compl_interrupted() to also check for timeout,
          further refactor code to skip outputting message when
          performing autocompletion (Girish Palya).

Running `vim *` in `vim/src` was slower than expected when
'autocomplete' was enabled. Include-file and tag-file completion
sources were not subject to the timeout check, causing unnecessary
delays.

So apply the timeout check to these sources as well, improving
autocompletion responsiveness, refactor find_pattern_in_path() to take
an additional "silent" argument, to suppress any messages.

closes: #17966

Signed-off-by: Girish Palya <girishji@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-08-12 21:38:56 +02:00
cb27992cda patch 9.1.1464: gv does not work in operator-pending mode
Problem:  gv does not work in operator-pending mode
          (liushapku)
Solution: remove the check for checkclearop in nv_gv_cmd()
          (phanium)

fixes: #3666
closes: #17551

Signed-off-by: phanium <91544758+phanen@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-06-16 20:19:15 +02:00
e89aef3f65 patch 9.1.1390: style: more wrong indentation
Problem:  style: more wrong indentation
Solution: reformat a few more places
          (Yegappan Lakshmanan)

closes: #17309

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-05-14 20:31:55 +02:00
6af20a9be3 patch 9.1.1357: Vim incorrectly escapes tags with "[" in a help buffer
Problem:  Vim incorrectly escapes tags containing "[" in a help buffer
Solution: check if the buffer has the "help" filetype set, instead of
          already being a help buffer (Phạm Bình An)

fixes: #17224
closes: #17232

Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Phạm Bình An <phambinhanctb2004@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-05-01 17:30:58 +02:00
98800979dc patch 9.1.1319: Various typos in the code, issue with test_inst_complete.vim
Problem:  Various typos in the code, redundant and strange use of
          :execute in test_ins_complete.vim (after 9.1.1315).
Solution: Fix typos in the code and in the documentation, use the
          executed command directly (zeertzjq).

closes: #17143

Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-04-18 10:57:33 +02:00
bc27b6e34f patch 9.1.1294: gui tabline menu does not use confirm when closing tabs
Problem:  gui tabline menu does not use confirm when closing tabs
Solution: use ":confirm tabclose" explicitly (JMcKiern)

closes: #17093

Signed-off-by: JMcKiern <jmckiern@tcd.ie>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-04-12 11:51:00 +02:00
c8cce711dd patch 9.1.1175: inconsistent behaviour with exclusive selection and motion commands
Problem:  inconsistent behaviour with exclusive selection and motion
          commands (aidancz)
Solution: adjust cursor position when selection is exclusive
          (Jim Zhou)

fixes: #16278
closes: #16784

Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Jim Zhou <jimzhouzzy@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-03-05 20:47:29 +01:00
2c47ab8fcd patch 9.1.1108: 'smoothscroll' gets stuck with 'listchars' "eol"
Problem:  'smoothscroll' gets stuck with 'listchars' "eol".
Solution: Count size of 'listchars' "eol" in line size when scrolling.
          (zeertzjq)

related: neovim/neovim#32405
closes: #16627

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2025-02-13 20:34:34 +01:00
bb95589473 patch 9.1.0938: exclusive selection not respected when re-selecting block mode
Problem:  exclusive selection not respected when re-selecting block mode
          (Matt Ellis)
Solution: advance selection by another character when using
          selection=exclusive and visual block mode

fixes: #16202
closes: #16219

Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-12-16 22:49:15 +01:00
9848face74 patch 9.1.0869: Problem: curswant not set on gm in folded line
Problem:  curswant not set on gm in folded line
          (citizenmatt)
Solution: in a folded line, call update_curswant_force()

fixes: #11596
closes: #11994
closes: #15398

Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-11-17 16:18:00 +01:00
a1b654ff36 patch 9.1.0856: mouseshape might be wrong on r and gr
Problem:  mouseshape might be wrong on r and gr
Solution: call update_mousesape(-1) immediately
          (Yee Cheng Chin)

Currently, when entering the "pretend" or single character replace modes
using `r` or `gr`, the mouse cursor doesn't immediately update until you
have re-focused the window or moved the mouse. This is because it's not
calling `update_mouseshape(-1)` immediately, so the cursor will only be
updated when it's called by other functions like `gui_mouse_focus`.

To fix this, just make sure we call this `update_mouseshape(-1)`. It's
what we do when entering Insert or Replace modes for example.

I noticed this when trying to figure out why MacVim CI is failing in
`Test_mouse_shape_after_cancelling_gr` (introduced in #12110), but I
think that test is only passing in Vim GTK CI by accident, since this
issue happens there too. I think the window captured focus after the
mouse `gr` call which triggers a mouse shape change but it probably
would have failed under other circumstances.

fixes: #14660
closes: #12157

Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-11-11 21:57:27 +01:00
f8702aeb8f patch 9.1.0699: "dvgo" is not always an inclusive motion
Problem:  "dvgo" is not always an inclusive motion
          (Iain King-Speir)
Solution: initialize the inclusive flag to false

fixes: #15580
closes: #15582

Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-08-28 20:39:24 +02:00
22105fd1fe patch 9.1.0589: vi: d{motion} and cw work differently than expected
Problem:  vi: d{motion} and cw command work differently than expected
Solution: add new cpo-z flag to make the behaviour configurable

There are two special vi compatible behaviours (or should I say bugs?):

1): cw behaves differently than dw. That is, because cw is special cased
    by Vim and is effectively aliased to ce.
    POSIX behaviour is documented here:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152_13_81

2): d{motion} may make the whole delete operation linewise, if the start
    and end of the motion are on different lines and there are only
    blanks before the start and after the end of the motion.
    Did not find a related POSIX link that requires this behaviour.

Both behaviours can be considered inconsistent, but we cannot easily
change it, because it would be a backward incompatible change and also
incompatible to how classic vi behaved.

So let's add the new cpo flag "z", which when not included fixes both
behaviours and make them more consistent to what users would expect.

This has been requested several times:
https://groups.google.com/d/msg/vim_use/aaBqT6ECkA4/ALf4odKzEDgJ
https://groups.google.com/d/msg/vim_dev/Dpn3xtUF16I/T6JcOPKN6usJ
http://www.reddit.com/r/vim/comments/26nut8/why_does_cw_work_like_ce/
https://groups.google.com/d/msg/vim_use/vunNWLFWfQg/MmJh_ZGaAgAJ
https://github.com/vim/vim/issues/4390

So in summary, if you want to have the w motion work more consistent,
remove the 'z' from the cpo settings.

related: #4390
closes: #15263

Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-07-15 20:51:11 +02:00
d9be94cf03 patch 9.1.0581: Various lines are indented inconsistently
Problem:  style: Various lines are indented inconsistently
Solution: Retab these lines and correct some comments.
          (zeertzjq)

closes: #15259

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-07-14 10:20:20 +02:00
701ad50a9e patch 9.1.0433: Wrong yanking with exclusive selection and ve=all
Problem:  Wrong yanking with exclusive selection and virtualedit=all,
          and integer overflow when using getregion() on it.
Solution: Set coladd when decreasing column and 'virtualedit' is active.
          Add more tests for getregion() with 'virtualedit' (zeertzjq).

closes: #14830

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-05-23 07:47:55 +02:00
8c85a2a49a patch 9.1.0426: too many strlen() calls in search.c
Problem:  too many strlen() calls in search.c
Solution: refactor code and remove more strlen() calls,
          use explicit variable to remember strlen
          (John Marriott)

closes: #14796

Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-05-20 19:18:26 +02:00
8e4c4c7d87 patch 9.1.0418: Cannot move to previous/next rare word
Problem:  Cannot move to previous/next rare word
          (Colin Kennedy)
Solution: Add the ]r and [r motions (Christ van Willegen)

fixes: #14773
closes: #14780

Signed-off-by: Christ van Willegen - van Noort <github.com@vanwillegen-vannoort.nl>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-05-17 18:52:45 +02:00
acdfb8a979 patch 9.1.0343: 'showcmd' wrong for partial mapping with multibyte
Problem:  'showcmd' is wrong for partial mapping with multibyte char,
          and isn't very readable with modifyOtherKeys.
Solution: Decode multibyte char and merge modifiers into the char.
          (zeertzjq)

This improves the following situations:
- Multibyte chars whose individual bytes are considered unprintable are
  now shown properly in 'showcmd' area.
- Ctrl-W with modifyOtherKeys now shows ^W in 'showcmd' area.

The following situation may still need improvement:
- If the char is a special key or has modifiers that cannot be merged
  into it, internal keycodes are shown in 'showcmd' area like before.
  This applies to keys typed in Normal mode commands as well, and it's
  hard to decide how to make it more readable due to the limited space
  taken by 'showcmd', so I'll leave it for later.

closes: #14572

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-17 21:28:54 +02:00
9148ba8a46 patch 9.1.0280: several issues with 'smoothscroll' support
Problem:  Logic to make sure cursor is in visible part of the screen after
          scrolling the text with 'smoothscroll' is scattered, asymmetric
          and contains bugs.
Solution: Adjust and create helper function for 'smoothscroll' cursor logic.
          (Luuk van Baal)

closes: #14410

Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-08 22:27:41 +02:00
cb204e688e patch 9.1.0258: half-page scrolling broke backward compatibility
Problem:  Support for 'smoothscroll' in (half-)page scrolling
          broke backward compatibility and can be made to work better.
          (after v9.1.215)
Solution: Restore the previous cursor and end-of-buffer behavior for
          half-page scrolling and improve 'smoothscroll' support.
          (Luuk van Baal)

fixes: #14338
closes: #14377

Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-02 20:49:45 +02:00
5a2e3ec9ac patch 9.1.0215: Half-page scrolling does not support smooth-scrolling
Problem:  Page-wise scrolling with Ctrl-D/Ctrl-U implements
          it's own logic to change the topline and cursor.
          More logic than necessary for scrolling with Ctrl-F/Ctrl-B
          was removed in patch 9.1.0211.
Solution: Re-use the logic from Ctrl-E/Ctrl-Y/Ctrl-F/Ctrl-B while
          staying backward compatible as much as possible.
          Restore some of the logic that determined how many lines will
          be scrolled (Luuk van Baal)

closes: #14316

Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-03-28 10:10:40 +01:00
366c81a200 patch 9.1.0201: gM not working correctly with virt text
Problem:  `gM` would include outer virtual text and its padding when
          getting the line length used to calculate the middle of the
          line, putting the cursor much closer to virtual text lines.
Solution: Exclude outer virtual text in getting the line length for
          `gM`, so that virtual text doesn't influence where the cursor
          is moved to (Dylan Thacker-Smith).

closes: #14262

Signed-off-by: Dylan Thacker-Smith <dylan.ah.smith@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-03-24 09:46:56 +01:00
b2d124c625 patch 9.1.0200: gj/gk not skipping over outer virtual text lines
Problem:  `gj`/`gk` was updating the desired cursor virtual column to
          the outer virtual text, even though the actual cursor position
          was moved to not be on the virtual text, leading the need to
          do an extra `gj`/`gk` to move past each virtual text line.
          (rickhowe)
Solution: Exclude the outer virtual text when getting the line length
          for moving the cursor with `gj`/`gk`, so that no extra
          movement is needed to skip over virtual text lines.
          (Dylan Thacker-Smith)

fixes: #12028
related: #14262

Signed-off-by: Dylan Thacker-Smith <dylan.ah.smith@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-03-24 09:43:25 +01:00
2157035637 patch 9.1.0147: Cannot keep a buffer focused in a window
Problem:  Cannot keep a buffer focused in a window
          (Amit Levy)
Solution: Add the 'winfixbuf' window-local option
          (Colin Kennedy)

fixes:  #6445
closes: #13903

Signed-off-by: Colin Kennedy <colinvfx@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-03-03 16:16:47 +01:00
4e141c66b9 patch 9.1.0141: Put in Visual mode wrong if it replaces fold marker
Problem:  Put in Visual mode wrong if it replaces fold marker.
Solution: Temporarily disable folding during put in Visual mode.
          (zeertzjq)

fixes: #14097
closes: #14100

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-02-28 21:49:51 +01:00
02d7a6c6cf patch 9.1.0138: too many STRLEN calls when getting a memline
Problem:  too many STRLEN calls when getting a memline
Solution: Optimize calls to STRLEN(), add a few functions in memline.c
          that return the byte length instead of relying on STRLEN()
          (John Marriott)

closes: #14052

Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-02-26 21:25:03 +01:00
bf321806bf patch 9.1.0060: Recorded register cannot be translated using keytrans()
Problem:  Recorded register cannot be translated using keytrans() when
          it involves character search (iddqd505)
Solution: Record a K_IGNORE instead of a K_NOP (zeertzjq)

related: #13916
closes: #13925

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-28 19:03:00 +01:00
184f71cc68 patch 9.1.0006: is*() and to*() function may be unsafe
Problem:  is*() and to*() function may be unsafe
Solution: Add SAFE_* macros and start using those instead
          (Keith Thompson)

Use SAFE_() macros for is*() and to*() functions

The standard is*() and to*() functions declared in <ctype.h> have
undefined behavior for negative arguments other than EOF.  If plain char
is signed, passing an unchecked value from argv for from user input
to one of these functions has undefined behavior.

Solution: Add SAFE_*() macros that cast the argument to unsigned char.

Most implementations behave sanely for negative arguments, and most
character values in practice are non-negative, but it's still best
to avoid undefined behavior.

The change from #13347 has been omitted, as this has already been
separately fixed in commit ac709e2fc0
(v9.0.2054)

fixes: #13332
closes: #13347

Signed-off-by: Keith Thompson <Keith.S.Thompson@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-04 21:19:04 +01:00
22cbc8a4e1 patch 9.0.2114: overflow detection not accurate when adding digits
Problem:  overflow detection not accurate when adding digits
Solution: Use a helper function

Use a helper function to better detect overflows before adding integer
digits to a long or an integer variable respectively. Signal the
overflow to the caller function.

closes: #13539

Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Michael Henry <vim@drmikehenry.com>
Signed-off-by: Ernie Rael <errael@raelity.com>
2023-11-19 10:47:21 +01:00
58f9befca1 patch 9.0.2109: [security]: overflow in nv_z_get_count
Problem:  [security]: overflow in nv_z_get_count
Solution: break out, if count is too large

When getting the count for a normal z command, it may overflow for large
counts given. So verify, that we can safely store the result in a long.

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-11-16 22:04:37 +01:00
4bca4897a1 patch 9.0.2075: TextChangedI may not always trigger
Problem:  TextChangedI may not always trigger
Solution: trigger it in more cases: for insert/
          append/change operations, and when
          opening a new line,

fixes: #13367
closes: #13375

Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
2023-10-27 19:26:49 +02:00
476733f3d0 patch 9.0.1915: r_CTRL-C works differently in visual mode
Problem:  r_CTRL-C works differently in visual mode
Solution: Make r_CTRL-C behave consistent in visual mode
          in terminal and Windows GUI

in visual mode, r CTRL-C behaves strange in Unix like environments. It
seems to end visual mode, but still is waiting for few more chars,
however it never seems to replace it by any characters and eventually
just returns back into normal mode.

In contrast in Windows GUI mode, r_CTRL-C replaces in the selected area
all characters by a literal CTRL-C.

Not sure why it behaves like this. It seems in the Windows GUI, got_int
is not set and therefore behaves as if any other normal character has
been pressed.

So remove the special casing of what happens when got_int is set and
make it always behave like in Windows GUI mode. Add a test to verify it
always behaves like replacing in the selected area each selected
character by a literal CTRL-C.

closes: #13091
closes: #13112

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-09-19 20:45:07 +02:00
dccc29c228 patch 9.0.1866: undo is synced after character find
Problem:  Undo is synced after character find.
Solution: Set no_u_sync when calling gotchars_nop().

closes: #13022
closes: #13024

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2023-09-04 22:25:07 +02:00
d809c0a903 patch 9.0.1792: problem with gj/gk/gM and virtual text
Problem:  Normal mode "gM", "gj", "gk" commands behave incorrectly with
          virtual text.
Solution: Use linetabsize() instead of linetabsize_str().

closes: #12909

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2023-08-27 11:17:39 +02:00
654bdbbd32 patch 9.0.1761: g<kEnd> behaves different from g<end>
Problem:  g<kEnd> behaves different from g<end>
Solution: Make g<kEnd> behave like g<End>

closes: #12861

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2023-08-20 18:24:20 +02:00
b5f6fe9ca2 patch 9.0.1753: can't move to last non-blank char
Problem: can't move to last non-blank char
Solution: Make g<end> behave like that

Make it possible to move to last non-blank char on a line

We can distinguish between g0 and g^ to move to the very first character
and the first non-blank char.

And while we can move to the last screen char, we cannot go to the last
non-blank screen char.

Since I think g$ is the more widely used and known movement command (and
g<end> is synonymous to it) change the behaviour of g<end> to move to
last non-screen char instead and don't have this be the same command as
the g$ command anymore.

If you want to keep the old behaviour, you can use:

```
nnoremap g<end> g$
```

Add a test to verify the behaviour.

closes: #12593

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-08-19 15:55:35 +02:00
bacc83009b patch 9.0.1694: wrong mapping applied when replaying a char search
Problem: wrong mapping applied when replaying a char search
Solution: Store a NOP after the ESC

closes: #12708
closes: #6350

Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2023-08-12 00:09:31 +02:00
2d63e4b3cc patch 9.0.1693: Ctrl-Q not handled like Ctrl-V in replace mode
Problem: Ctrl-Q not handled like Ctrl-V in replace mode
Solution: Handle Ctrl-Q like Ctrl-V

closes: #12686
closes: #12684

Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-08-12 00:03:57 +02:00
a109f39ef5 patch 9.0.1599: Cursor not adjusted when 'splitkeep' is not "cursor"
Problem:    Cursor not adjusted when near top or bottom of window and
            'splitkeep' is not "cursor".
Solution:   Move boundary checks to outer cursor move functions, inner
            functions should only return valid cursor positions. (Luuk van
            Baal, closes #12480)
2023-06-02 14:16:35 +01:00
8667a5678f patch 9.0.1545: text not scrolled when cursor moved with "g0" and "h"
Problem:    Text not scrolled when cursor moved with "g0" and "h".
Solution:   Adjust w_skipcol when needed. (Luuk van Baal, closes #12387)
2023-05-12 15:47:25 +01:00
73916bac5a patch 9.0.1490: the ModeChanged event may be triggered too often
Problem:    The ModeChanged event may be triggered too often.
Solution:   Only trigger ModeChanged when no operator is pending.
            (closes #12298)
2023-04-26 16:50:19 +01:00
aa7f25ebf1 patch 9.0.1451: unnecessary redrawing when 'showcmdloc' is not "last"
Problem:    Unnecessary redrawing when 'showcmdloc' is not "last".
Solution:   Redraw later when "showcmd_is_clear" is set. (Luuk van Baal,
            closes #12260)
2023-04-13 21:47:38 +01:00
f86dea8119 patch 9.0.1385: g'Esc is considered an error
Problem:    g'Esc is considered an error.
Solution:   Make g'Esc silently abandon the command. (closes #12110)
2023-03-05 21:15:06 +00:00
4f026ea9f1 patch 9.0.1356: cannot cancel "gr" with Esc
Problem:    Cannot cancel "gr" with Esc.
Solution:   Make "gr<Esc>" do nothing. (closes #12064)
2023-02-26 14:47:24 +00:00
d6a4ea3aa0 patch 9.0.1354: "gr CTRL-G" stays in virtual replace mode
Problem:    "gr CTRL-G" stays in virtual replace mode. (Pierre Ganty)
Solution:   Prepend CTRL-V before control characters. (closes #12045)
2023-02-25 14:24:44 +00:00
a23a11b5bf patch 9.0.1336: functions without arguments are not always declared properly
Problem:    Functions without arguments are not always declared properly.
Solution:   Use "(void)" instead of "()". (Yegappan Lakshmanan, closes #12031)
2023-02-21 14:27:41 +00:00
441a7a9448 patch 9.0.1324: "gj" and "gk" do not move correctly over a closed fold
Problem:    "gj" and "gk" do not move correctly over a closed fold.
Solution:   Use the same code as used for "j"/"k" to go to the next/previous
            line. (Luuk van Baal, closes #12007)
2023-02-18 20:15:44 +00:00
1d6539cf36 patch 9.0.1309: scrolling two lines with even line count and 'scrolloff' set
Problem:    Scrolling two lines with even line count and 'scrolloff' set.
Solution:   Adjust how the topline is computed. (closes #10545)
2023-02-14 17:41:20 +00:00
8f531662e2 patch 9.0.1273: "1v" may select block with wrong size
Problem:    "1v" may select block with wrong size. (Evgeni Chasnovski)
Solution:   Compute "curswant" in the right line. (closes #11925)
2023-02-01 17:33:18 +00:00
a41e221935 patch 9.0.1208: code is indented more than necessary
Problem:    Code is indented more than necessary.
Solution:   Use an early return where it makes sense. (Yegappan Lakshmanan,
            closes #11819)
2023-01-16 18:19:05 +00:00