[QUESTION] Cursor up/down navigation in soft-wrapped text (gj/gk in Vim)

[VKondakoff]

Question

Hi!

This issue is quite old. Here are some previous discussions: #3649 , #2851, https://discuss.kakoune.com/t/navigating-line-wrapped-text/700/7 .

Unfortunately, none of the workarounds discussed in these threads are working in the latest Kakoune. Any chance to see some new ideas?

Thank you!

[nonumeros]

When you say the cursor in navigation for vim gj and gk you mean the motion as if gj and gk were default in vim. They are not. Some folks even remap to j and k and vice versa.

So I can't wrap my head (no pun intended) around it. Even vim has a gq to format the lines to whatever standard width one deems necessary . I don't think tw is default either.

After reading some of the referenced issues you posted (thank you for that) it resembles what a vim plugin such as pencil would do by Wrapping the line around as you type. It's innovative no doubt

But I like long lines a la ed editor. The original. The only one. Anything that comes after is just a remake.

If one has a

hook global WinSetOption filetype=*. %{
set window autowrap_column 32 
autowrap_enable
} 

it may not have the same effect as a the pencil plugin with vim does, but it's fairly acceptable I think

[VKondakoff]

Thanks for looking into this!

When you say the cursor in navigation for vim gj and gk you mean the motion as if gj and gk were default in vim. They are not. Some folks even remap to j and k and vice versa.

Sorry, English is not my native language, so I'm no 100% sure I understand you correctly, but the gj/gk motions are available in Vim by default, and no plugin is needed to use them: https://neovim.io/doc/user/motion.html#gk .

IMHO: as Kakoune gives us an option to soft-wrap lines, there should be a way to go up/down the display (virtual soft-wrapped) lines instead of physical lines. The lack of this motion makes user constantly toggle the soft-wrap on/off, because navigating in heavily soft-wrapped text currently is a nightmare.

[nonumeros]

Thanks for looking into this!

When you say the cursor in navigation for vim gj and gk you mean the motion as if gj and gk were default in vim. They are not. Some folks even remap to j and k and vice versa.

Sorry, English is not my native language, so I'm no 100% sure I understand you correctly, but the gj/gk motions are available in Vim by default, and no plugin is needed to use them: https://neovim.io/doc/user/motion.html#gk .

IMHO: as Kakoune gives us an option to soft-wrap lines, there should be a way to go up/down the display (virtual soft-wrapped) lines instead of physical lines. The lack of this motion makes user constantly toggle the soft-wrap on/off, because navigating in heavily soft-wrapped text currently is a nightmare.

You're correct. It is as default in say neovim, or whatever, say vim , as much as a plugin would be therein. The motion k and/or j is all that is needed on vi. The motions gk and gj were just add-ons to vi and thus, later becoming what are now known as vim and neovim becoming say, for, what it's worth, mainstream editors. . That's what I meant by default. Technically and for convention, you're correct, but is just a misleading concept that there exists and everyone goes on and repeats it. But it is just an add-on. Vi treats real lines as displayed lines basically because these are the real lines

but I agree with you in that kak ought to implement it

[dojoteef]

@VKondakoff As you said, this is an old issue with many duplicates at this point. I would close this out and discuss any solutions in one of the existing issues, like #1425.

@nonumeros gj/gk have been in vim since version 4 (check out src/normal.c), which was released in 1996, nearly three decades ago. I think it's safe to assume users of vim have become accustomed to its existence by this point.

[nonumeros]

@VKondakoff As you said, this is an old issue with many duplicates at this point. I would close this out and discuss any solutions in one of the existing issues, like #1425.

@nonumeros gj/gk have been in vim since version 4 (check out src/normal.c), which was released in 1996, nearly three decades ago. I think it's safe to assume users of vim have become accustomed to its existence by this point.

So what? It's not less an add-on than before. And it'd be pretty safe to assume most vim users are not vi users. And of course, I would agree with you in that it's been there forever but then again that alone doesn't mean shit. Pardon my french.

Quoting mawww here

I dont think j/kshould take display into account, the current direction we have taken with Kakoune is to remove dependency on display

#1425 (comment)

and

to add some other keys that are specifically 'move vertically according to the view'. Not sure which bindings to use (maybe as a goto binding), but you'll be able to remap these to j/k

I personally would have thought his first statement was the opposite of the behavior but I don't know. That's all.

[dojoteef]

Pardon my french.

@nonumeros I think civility is important in conversations. Please don't appeal to ridicule. Let's just leave the history of gj/gk aside for now and merely note that it is an issue that's been reported at least since 2017, with multiple separate issues being opened about it. I think we can both agree to those facts.

Quoting mawww here

I dont think j/kshould take display into account, the current direction we have taken with Kakoune is to remove dependency on display

#1425 (comment)

and

to add some other keys that are specifically 'move vertically according to the view'. Not sure which bindings to use (maybe as a goto binding), but you'll be able to remap these to j/k

I personally would have thought his first statement was the opposite of the behavior but I don't know. That's all.

The person who opened #1435 wanted j/k remapped to be based on display line. @mawww states j/k should not be changed, but rather that an alternative is a new set of bindings in the goto menu that go up/down a display line. This is essentially saying, that gj/gk is the key combo that likely makes most sense (which mirrors what vim does). Both in vim and in the hypothetical case that kakoune supports gj/gk users are free to remap j => gj and k => gk, which some people already do for vim. So what he said is fully consistent and is in line with how vim works.

From my reading of the issues, the reason this hasn't been implemented is that there are tricky edge cases. There aren't easy ways to perform the necessary calculations for selections that are off-screen, which is likely to occur with multiple selections. Additionally, there are different types soft wrapping, including at word boundaries, taking into account previous line indents, etc.

[nonumeros]

I probably agree more with you than with mawww in this one. As much as I can support and love mawww for his relentless pursuit for the editor doesn't translate onto bending backwards for the vision and certain aspects of whatever comes into play

Some of that conversation goes on and on with even coordinates by other users. For crying out loud I reckon those are indeed the calculations you must have been referring to. But these supposedly calculations are nothing more than a sure way to flunk it off altogether. it's like cheating ahead of the exam and then calling it off flawed.

If keybinding mappings are considered by mawww and these in turn would not interfere later on with something else, so be it.

But if, to give you an example, you notice and were to invoke kak -n and were to use up the least amount of real estate on your terminal and were to compare it later on, side by side, with say, vi, then the resemblance is more accurate than before.

And if later on you go right ahead (recall that kak -n) and get the wrap going, aha!!! that's when everything gets thrown off. And I'm pretty sure you know this by now.

But yes. The least amount of real estate terminal with kak -n and then buffer wrap becomes crystal clear that the problem is there . Anyway. Some folks may use the terminologies soft-wrap and hard-wrap but I don't care really. The only reason I mention is is precisely because at this point everything goes bananas :) to display lines accordingly

[losnappas]

Afaict still not possible. I don't think a %sh block can tell if e.g. add-highlighter -override global/wrap wrap -indent -word is active or not, makes things kinda impossible. Maybe nuking all highlighters b4 executing a careful {count}l could work but probably not.