Add option to not have newlines selectable

[diktomat]

There already has been some discussion on newline characters being treated like any other in #585 and #2956. As this is a very frequent stumbling stone for me as well, I'd like to propose adding an option to treat newline characters special. With this new option set, Helix would:

• not allow the cursor be on a newline character
• not select it on x, unless it's in between multiple lines that are selected
• select it additionally on xd to delete the whole line

Reasoning:

• Beyond Kakoune, I don't know any editor behaving this way, so it would be more in line with what everyone else does, making it easier to switch.
• While being more consistent per se, the current behavior is less consistent with expectations and thus less intuitive.
• Some obviously seem to like the current behavior for being consistent, so make it optional.

[CptPotato]

I fear that this could make the behavior quite inconsistent and harder to follow if in some cases the newline was selected and in others not, causing weird side effects depending on what inputs the user performs.

Though I can't say for sure, maybe this could work pretty smoothly?

[archseer]

This gets even more inconsistent: if you place the cursor on an empty line, you're literally placing the cursor onto the EOL character. Disabling this would mean a bunch of workarounds for empty lines.

[diktomat]

If I understand #376 correctly, the cursor actually internally is between the \ns of the current and the line above, so this wouldn't be inconsistent at all?

[sudormrfbin]

#376 allows expressing ranges as positions between characters, but cursors in helix always have a width of 1. This is why pressing d with a normal cursor deletes the character under it -- it is simply deleting the single width selection under it.

[the-mikedavis]

The current behavior is quite elegant when it comes to selections: you can treat newline like any other character so you can do things like t<ret> to select up until a newline or sub-select newlines in a selection.

Normally I would agree that behavior should be customizable but in this case I think it's out of scope: as archseer says, in order to make this configurable, we'd need to add a bunch of workarounds which would be pretty hacky. Ultimately this is a smaller but comparable problem as having an evil mode (vim bindings). Maintaining competing paradigms is a pain so it's out of scope

[adsick]

When you say it like so for me it sounds like helix aims to be consistently bad, guys in #585 correctly point out that there is no point in looking at some thing called "kakoune", the point is to make a good editor and good editor should have a good design and intuitive UX.
When good decisions are "inconsistent" you are in fact doing the whole thing wrong.
@archseer

[archseer]

@adsick Thanks for the ping! You are being rude again, so I'm not going to respond. You are welcome to start a polite discussion next time.

[taupiqueur]

Kakoune used to treat the EOL specially, but changed this behavior during its development.

mawww/kakoune#530

[adsick]

@adsick Thanks for the ping! You are being rude again, so I'm not going to respond. You are welcome to start a polite discussion next time.

by my personal standards there is nothing rude in my speech, it simply is my response to your "consistent" status quo where things make no sense to outsiders (but are "consistent" for some small % of users). In fact I'm trying to help helix be more accessible to people who know nothing about "kakoune" whatever it is (most people out there).

If you care so much about correctness and politeness then I want to mention that your behavior in my regard is somewhat toxic too because it basically goes like so

adsick and normies: hey, it bothers me, let's change/improve it!
helix members: something about kakoune + "wontfix"

You of course can continue to do that and make your kakoune echo chamber prosper, but in reality it won't get much traction as others will simply switch to nvim/VScode where things just work well... normally

After in all it maybe just me not getting all of those extremely useful and "comprehensive" features you put in helix (and behaviours that arise from them). take multiple cursors wrapping around string boundaries.

I'm stubborn but say it once again "kakoune" doesn't necessarily means "good" (intuitive/productive/rich), people need something that is good, not something that is "kakoune"

[adsick]

It is kinda funny being accused of rudeness seeing you basically rejecting improvements using the same arguments everytime - "kakoune" and "inconsistent"

[the-mikedavis]

the point is to make a good editor and good editor should have a good design and intuitive UX

Actually, the point for us is to make an editor we enjoy using ourselves. In our opinions, helix is already a good editor and has good design and intuitive UX.

in reality it won't get much traction as others will simply switch to nvim/VScode

That's ok. Helix isn't trying to be everything for everyone. We're just working on editor we enjoy working on and designing it the way we like it.

Disagreeing with our design choices is fine but we've been explicit that we have no desire to change some core design principles like following the select-then-act paradigm or treating newlines like characters. If you continue to disagree, you can...

• Fork the project and change it how you like. If your changes are clearly better, your fork will naturally become more popular than this repo.
• Use a different editor. I don't mean this to be snarky: if you don't like Helix's paradigms and choices, a vim descendant may align better with your interpretation of a good editor.

But being "stubborn" and continuing to complain about our choices does nothing but antagonize us.

[adsick]

Okay, okay I get it, thanks for your time spent. Started thinking of fork myself, but not quite sure if my development skills are enough for that. Anyway good luck doing what you're up to.

[pickfire]

@adsick I noticed that some of the user experience stuff that you have pointed out I have looked into quite a few of them in the past but haven't make them into reality yet, like gld instead of vgld.

I am more than happy if you send some pull requests to improve the current state of art, just tag me and I will help to look at them. But I will also appreciate if you can reword the way you comment, if you want others to listen to your opinions.

The other way you could help if you are not experienced with development is to try out pull requests that involves keybindings and user experience changes, for example help me to review #2412, I always wanted some feedbacks.

If you standards of rudeness are low it's fine, but the other maintainers standard may likely be high. Pro tip, remove all the words "you"/"your" from your comments, that will hugely reduce the rudeness others perceived.