fix(jump): do not force charwise Operator-pending jump

[abeldekat]

Details:

• Always highlight matches even when the Operator-pending jump did not succeed. This can happen if the jump is not possible, but there are matches in the other direction.

• The internal undo workaround is not needed anymore.

• This change is breaking for users that test MiniJump.state.mode to be equal to 'nov'. In that situation, the mode is now 'no'.

Resolve #2323

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

[echasnovski]

Thanks for the PR!

As this stands, I don't think it is a feat(jump)!, but a regular fix(jump):

• Resolves some edge cases that were there due to :undo (like in a new test for empty line).
• The no mode is a more correct mode anyway, since nov is a forced charwise mode (which should be the case for something like dv-f) which was a byproduct of me not finding another way to implement the intended jumping behavior (since it requires forced charwise movement to match the found patterns).
• It doesn't seem to break any explicitly documented behavior.

Also:

• I did notice that [mini.jump] Improve highlighting after jumping in Operator-pending mode #2323 does not fully describe the behavior: there are problems if mark is the first line, but everything seems to work as expected (and as after this PR's change) if: the first line is empty, mark is on the second with cursor on its a.
• The "highlight all matches after Operator-pending mode jump" is not something that can be considered a feature. Ideally it would be highlighting only the matches that can be used to dot-repeat. Adding this functionality would be a feat(), but I don't think it can be done concisely. Highlighting all matches doesn't have much utility since it is not possible to change direction or till "on the fly" for dot-repeat.

So describing this as a fix(jump): do not force charwise Operator-pending jump is closer to what this achieves.

---

I noticed one problem with this change: highlighting disappears only after second unrelated cursor move if Operator-pending jump did not actually jump. I.e. with mark as a line and cursor on a: dfm - wait for highlight - l and it still highlights - land it stops highlighting.

This might be not a problem if there is no highlighting after an Operator-pending jump, but currently there is. I am still on the fence about whether removing all highlighting is a good thing or a technical necessity.

[abeldekat]

I noticed one problem with this change: highlighting disappears only after second unrelated cursor move if Operator-pending jump did not actually jump. I.e. with mark as a line and cursor on a: dfm - wait for highlight - l and it still highlights - land it stops highlighting.

Indeed, that's a side effect of removing the 'undo'. On the first 'l', H.cache.n_cursor_moved is still 0....

I would like to fix that, not sure how at the moment.

[abeldekat]

I would like to fix that, not sure how at the moment.

Would the code below be acceptable?

  -- If target not found in Operator-pending expression mapping, charwise-visual
  -- is reverted, preventing a character from being consumed.
  -- Do it here to also act on dot-repeat.
  if is_expr and not has_jumped then
    H.on_cursormoved()
    vim.cmd('normal! v')
  end

[echasnovski]

Would the code below be acceptable?

Judging simply by the code - not quite. It basically reads as "If inside expression jump and not jumped act as on cursor moved".

[abeldekat]

noticed one problem with this change: highlighting disappears only after second unrelated cursor move if Operator-pending jump did not actually jump. I.e. with mark as a line and cursor on a: dfm - wait for highlight - l and it still highlights - l and it stops highlighting.

In normal mode, a similar scenario also happens on latest main: With mark as a line and cursor on a: fm - wait for highlight - l and it still highlights - l and it stops highlighting.

Same cause: State is in jumping mode, but there was no jump, and thus no CursorMoved

I have an idea to fix this in the same manner for all modes. It's probably best to create a new PR after this one is merged.

[abeldekat]

I changed the text of corresponding issue #2323 to be less verbose. Please let me know if anything else needs to be done before merging.

[echasnovski]

This now should be part of the latest main.

The code looked good, I only tweaked a new "cursor on empty line" testing.