A place to have peaceful discussions over user disagreements & suggestions on key bindings

[txtyash]

Some users might dislike some of the built-in keybindings and might have ideas for better built-in keybindings that might be more intuitive and easier to type.

This could improve the default bindings and reduce common key remapping in user configs. Also, makes it easier for many users to quickly adapt to other users' configs.

Where should such users discuss keybinding ideas so that they're also considered by the developers?

[archseer]

Why not just use the existing issues/discussions pages to do this?

[archseer]

Discussions can be tagged with a separate category and searched for separately.

[txtyash]

Have to be "searched for".

I still think:

Having a single place where users can put their suggestions would be nice and also redirecting them to a page which shows the ideas that developers have "considered" from that discussion.

[archseer]

How is having a discussion category any different than having a separate repository that the users have to be aware of? I'd rather keep discussions under the official repository rather than splitting them around different places.

[archseer]

go unnoticed

If a suggestion is reasonable enough then someone will put in the work to open an issue or PR and get the change merged. I typically work on whatever I personally need in helix.

[archseer]

Let me repeat my question: how is using a separate repository's issues any different than making a discussion category for keybinds (see for example https://github.com/helix-editor/helix/discussions/categories/polls). It's more easily discoverable, has better threading and individual answers can be voted on.

[txtyash]

Here's a practical example.... I keep notes of problems I'm facing and they're related to multiple things...
A very small part of which is:

- EOL:
  - `space p` pastes on the next line
  - `xms"` goes onto the next line
  - `a` at the end of the line inserts on the next line
  - vim's `cc` or `C`: `x_c`
- Keybindings:
  - terrible default bindings: `alt-tilde`, `tilde`, `alt+shif+c`,
  - purpose: `alt-u`, `alt-U`?
  - `<count>x`: +1
  - `C-x`, `C-a`, `md[` issue

I'll start explaining:

EOL:

1. When I paste with space p at the very end of the line, it gets pasted onto the next line unless the line I'm pasting has a newline character at the end of it. No one would want that behavior. If I really want to paste before the start of the next line then I'd go to the start of that line and do space P instead.
2. If I'm in the middle of a line and wish to surround the entire line with quotes then it must be as easy as xms" right? Nope, it adds one of the quotes on the next line. So, now I have to do ght<ret>ms". Beautiful, consistent behavior of the selection action model you might say but unnecessarily using extra keystrokes would be anti productive in layman terms.
3. pressing a at the end of the line would take me to the start of the next line. Here it would be less annoying to restrict that behavior since the user intends to go to the next line and press I if they really want to insert anything at the start of the next line. Ik I can use i here but still having the a fixed here would be an attention to detail
4. hitting xc on a line entirely removes the line. I suggest it should do what x_c does. I can map it IK. It's an issue I'm having with the built-in behavior which I think is bad. If I really want to remove the entire line then I'd do xd instead. Usually in such cases if user wants to change the content of the entire line. If they really want to remove the line then they'd xd it.

Keybindings:

1. Some bindings are mostly hard to press. I probably won't ever open an issue for such because I use a custom keymap and usually remap anything that's difficult to press, to what's easier to press on my keyboard. But I do believe that the current bindings can be simplified with what's available. Also, helix uses up the alt key to... So, users don't have another mod left if they wanted to use a terminal multiplexer or tiling window manager. Helix, has left out some keys to use with alt for other purposes which is nice.
   One example of this is not being able to use what is at hand. When I suggested that we could put ~, backtick, alt-backtick, .. under match mode then that wasn't well received by the community. Yeah, it was rude of me to open up a PR for it without actually discussing but still it was an effort to simplify the bindings. I don't expect you to forcefully put them under match mode but you could at least think over it and be like "yea, let's talk over how we could simplify it" or "We're sorry although mu, ml, etc. are easier to press, we can't have them under match mode. Can you suggest to put them elsewhere?". Or you guys could've at least told me what you're planning to do with theses many spare keys under match mode.

2. ignore the second one. I'm still learning...

3. As @n0s4 suggested in the keymap issue that X is better for extending upwards. I have x & X to entire lines downwards and upwards respectively. This is what I primarily use to select multiple entire lines. It's easier than using v<count>jX. But there's an inconsistency with <count>x(It's not helix's fault). If I have to select 3lines downwards then I have to do 4x. I wish I could use 3x. I have to +1 it everytime in my mind. Nabd tho.. Just nitpicking.

4. I'm sorry I got furious about this one but @the-mikedavis said that the jumping behavior of C-x, C-a is going to be reverted. Also, jumps for md[ are considered a bad idea. Why? That's just going to make users need more keystrokes for snappy edits. This would be a long discussion.

Mostly, my complain is that I feel there's less regard to reducing keystrokes on the developer/maintainer side. This should be considered to. Since, a lot of potential with modal editing lies in there.

I don't mean to keep complaining unnecessarily. I really love this project. You guys are doing absolutely great work. But I hope you guys can understand that users tend to have a "user experience" and could bring in huge improvements with ideas and suggestions. Ig expressing more clearly what you guys are thinking/planning vs what user think would benefit them could blend in nicely if there's more engagement. This could mean slower development but probably better outcomes. I'm aware that you people also need to value your own personal time. So, some interaction could keep users aware of your state and time. If it could help easing workloads on you people.

Again, nice work but please let users with less programming experience have some priority for crunching ideas.

[txtyash]

Almost forgot, my point with the above long message was that it's a long list. A lot of minor stuff. I don't think most of these things deserve an issue. So, it's basically a massive clutter. They fit good in one place because hopefully other users will have some points to make about any of those minor problems.

[txtyash]

@archseer I hope you considered my points regarding EOL. Do you agree with them? Because that does seem like a problem.

A situation where I was trying to paste a link in markdown and surrounding it with chevrons:

• Pasting at the EOL with <space>p pastes on the next line. I believe this isn't how one intends to paste.
• If pasting at EOL with <space> shift+p, T (till previous <space>), and surrounding with ms> puts > on the next line.

[the-mikedavis]

This is starting to stray from the discussion. But specifically to these points:

• <space>P: you most likely want to use P (or <space>P). p pastes after the cursor's head. P pastes before
• T<space>: this is expected if your cursor is on the newline. You are surrounding the selection from the previous space to the end-of-line character with </>. The > gets put after the EOL so it ends up on the next line. You can use _ to trim whitespace from the selection.

[txtyash]

@the-mikedavis Why have that problem in the first place? Why does the user need to deal with the EOL character?

Also, If visualizing repeat is the problem then I did suggest mr & mR. The idea seems nice. I wonder if you don't face those problems.

[the-mikedavis]

I don't consider it to be a problem; I think the EOL being a regular character is elegant in many cases like being able to use t<ret> to select up to the EOL character.

[txtyash]

I don't consider it to be a problem; I think the EOL being a regular character is elegant in many cases like being able to use t<ret> to select up to the EOL character.

Is it impossible to make t<ret> work without that character?

[txtyash]

That could also make selections more consistent. Instead of having vgl and t<ret>, something better could be made.