[Feature Request]: Support for whichwrap

[hholst80]

What feature would you like to see?

I would like vis to implement the Vim 'whichwrap' setting.

The expected behavior between different users depends on their experience and previous editors. Instead of debating which is better, Vis can support both!

[mcepl]

1. If you want us to provide with some new feature, please, sit down and specify it as precisely as you are able to. If you say, “do it like them”, it means your time is too precious to sit down and do the specification, and we should do it instead of you. We would have to sit down, install some editor we don’t care about, study it and then divine what you meant by saying “do it like them”. That is not like the FLOSS world works. You should be paying others for doing work for you by doing as much as you can.
2. Issue tracker is for issues, with specified problem, and suggested solution, not for a free flow discussion. Please, send an email message to the email list https://lists.sr.ht/~martanne/devel, where we can discuss what is exactly what you wish for.

Thank you.

[hholst80]

Don't be an ass, I ask politely.

I thought that anyone working on vis would be familiar with vim standard configuration terms like whichwrap. I am sorry if I misjudged the situation.

Let me rectify it by pasting the man page for the setting?

Feature Request: whichwrap Behavior in a Vi-like Editor

Summary:
Introduce a whichwrap-like option in the editor, allowing users to configure the behavior of cursor movement at line boundaries. This feature provides fine-grained control over whether certain cursor motions (left, right, end, home, delete, backspace) should wrap to the next/previous line when at the beginning or end of the current line.

Key Features:

Configurable Wrapping: Users can define which motions (h, l, ←, →, BS, Space, ~) should allow line wrapping.

Customization Flexibility: Each type of motion can be individually enabled or disabled for wrapping, giving users full control over how the cursor behaves at line boundaries.

Improved Navigation: Enhances user experience by allowing intuitive wrapping behavior based on personal preferences or workflow needs.

This option would make line-based navigation more customizable, fitting various user preferences.

Reference
https://vimhelp.org/options.txt.html#%27whichwrap%27

[mcepl]

On Fri Oct 25, 2024 at 1:59 AM CEST, Henrik Holst wrote: I thought that anyone working on vis would be familiar with vim standard configuration terms like whichwrap. I am sorry if I misjudged the situation.

I have not used in anger vim (or in my case neovim) for more than year (I use it now only for two functions I miss in vis: nvim -d aka #1043 and support of orgmode TODO lists; Lua plugins for both are welcome!). I have truly forgotten meaning of all those hundreds options (certainly including this one).

Let me rectify it by pasting the man page for the setting?

Better than nothing … OK, so I opened neovim and looked it up. Yes, not only I have forgotten a lot, but I have never touched this option. Yes, it is different in vis, which was unpleasant in the beginning, but now I have completely forgotten about it.

[machinedgod]

@mcepl Offtopic, but there's a pretty nifty table plugin for vis (its on plugins page)
already

[hholst80]

Related issue in VSCOde. The author of the issue there had the inverse expectations to mine. LOL the tabs-vs-spaces of cursor movement.

VSCodeVim/Vim#1211

[rnpnr]

You still haven't told us what whichwrap is. Its not our responsibility to know every single feature of vim and it is stated in multiple locations that vis is not a vim clone.

Linking an issue for a vscode plugin, which as its name implies, is meant to be a clone of vim built on top of vscode is not helpful.

[hholst80]

You still haven't told us what whichwrap is. Its not our responsibility to know every single feature of vim and it is stated in multiple locations that vis is not a vim clone.

Linking an issue for a vscode plugin, which as its name implies, is meant to be a clone of vim built on top of vscode is not helpful.

#1203 (comment)

1. Nobody here implied vis is a vim clone. It is however vi-like. Being vi-like it would be a nice-to-have feature to be able to customize to the users wishes how the cursor behaves at line boundaries.

2. The issue talks about the feature. The technology where it is implemented is not important the feature is.

Please don't waste my time, and I promise to return the favor.

[rnpnr]

You still haven't told us what whichwrap is. Its not our responsibility to know every single feature of vim and it is stated in multiple locations that vis is not a vim clone.
Linking an issue for a vscode plugin, which as its name implies, is meant to be a clone of vim built on top of vscode is not helpful.

#1203 (comment)

Yes that's my bad, I was responding to what I saw via email, I didn't scroll back through the entire thread to see that you edited an entire post. Please take the time to type what you want to type instead of sending a half complete message (which you did again with this one).

1. Nobody here implied vis is a vim clone. It is however vi-like.

Last I checked vi has no such feature. This is a feature introduced by vim, not vi.

2. The issue talks about the feature. The technology where it is implemented is not important the feature is.

Then you should really do us the courtesy of telling us what it is to begin with instead of in this roundabout way that requires to read the same thing over and over again.

[hholst80]

I thought of that after the fact, that you you might have an email view of what was being said. I am sorry for the bad response from my side. I think this thread for no good reason got some bad vibes and I just thought you were out to attack me rather than to discuss the feature. My fault completely.

On the feature and its relationship to vi and or vim or even neovim I don't think that ultimately is of importance. I suspect that Vis does not have a design goal of being bug for bug compatible with Vi and obviously it has features far beyond what Vi in its original form had or has. Whatever that even means today, since nobody uses that but some derivative work.

Customizing the behavior around how cursor moves over line boundaries can be achieved in many ways. It does not even have to be an implementation of 'whichwrap' as its designed in Vim. I would just like, as an example, the cursor to NOT move to the above line if I press 'h' in normal mode and I am standing on the 'L' in the second line like here:

Same thing, if I stand on '1' and press 'l' I expect the cursor to stand still and NOT move to the 'L' on the second line.

There are other use cases related to this, which is captured by 'whichwrap'. Like the behavior of 'CTRL-W' in insert mode. It will delete all whitespace up to the first non-whitespace symbol on the line above. That is never what I intended to happen.

If Vis had this basic functionality to adapt to line movements (and edits) I would not see a reason to not to use Vis for all my programming tasks. Contrary to most Vim fanbois out there, I do not think regexps is a good user experience compared to multiple cursors, functionally equivalent or not.