-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove yank behavior of c
and d
#3001
Comments
This is currently implemented in the # ~/.config/helix/config.toml
[keys.normal]
A-d = "delete_selection"
d = "delete_selection_noyank"
A-c = "change_selection"
c = "change_selection_noyank" I'm not sure it makes sense for this to be the default keymap though - On the other hand I agree with your reasoning:
|
@the-mikedavis To the point about As for keystroke count: |
I for one would actually be in favor of this change. One thing I think helix does well is being discoverable and obvious, and the more I think on things the more I realize that key bindings that do conditional logic or do more than one thing make things a little less obvious and discoverable. |
I couldn't agree more. I think the challenge with modal editing has always been a UX challenge. The primary UX mis-step has not been communicating the mode to the user. The mode that you're in should be obvious and not require any user memory (I shouldn't need to remember that I entered insert mode before leaving my desk to go to the restroom, for example). Furthermore, learning curve should compound over-time. If I learn that |
It works for me. If they don't work for you (via the the keybindings or the command palette) please open a bug. I'd consider them functional to continue the discussion forward. Why not swapping A-c and A-d with c and d respectively? So users can still have a command that yanks and can use it when they need it. Also it makes sense to have the keybind with less keystrokes to do the most simple action. |
It seems like that's a macos specific problem you could fix in terminal emulator: #2280 Swapping A-c and A-d could work but then it's the same number of key-presses as yc and yd, so we might as well just remove the current c and d mappings. I'd like to try this out in my config for a bit but it seems like a reasonable change to me in theory |
I'm using Kitty (terminal app) and it doesn't register the Option key as Alt I set EDIT: Never mind, it seems to have worked. |
Except that now there is a delay for simple yank ( |
There would be no delay for yank, it would simply be sequential. |
There would be a small timer after |
It wouldn't need to care what comes next, any which way it yanks, what comes after is entirely separate. |
No the yank and delete/change would be separate commands executed independently but in sequence - there wouldn't be any need to have a delay. So if you would want to delete/change without yank, you would form a selection and then hit |
c
and d
As someone trying to get into an editor like vim or helix, the fact that deleting a section overwrites my buffer was one of the worst design design decisions about vim to me. I am happy that there is an explicit command for not copying in helix and that I can simply swap the keybindings. I fully agree that this should be the default behavior. Another approach could be to keep the copying behavior of c and d, but to yank into some designated register which isn't the default one? |
Why not implement a Basic idea
Benefits
Editing PerformanceFor the sake of discussion, let
I'm not sure what the best keybinding for the cycling command would be. Perhaps LearnabilityThe concept is not trivial, but completely clear once you understood it. So:
Implementation complexityAfter pasting, helix has to remember the selection and the position in the stack as part of the „cycling state”. This has to be cleaned up after „leaving“ that mode, i.e. doing something other than pasting. Anecdotal testimonyAs someone having used emacs for quite a few years – first vanilla, then with vim keybindings – and various IDEs with vim keybindings, this is the one big feature which for me was painfully missing in vim. Rectifying this in helix could be a great opportunity. |
@lukasjuhrich That might work okay for smaller chunks of code, but if I just cut out a single line of code and afterwards cleaned up (=deleted) a bunch of bigger blocks of code (think 20-100+ lines), I will now have to insert/cycle through these big chunks of code (that I don't actually care about anymore) just to get to the yanked content I actually wanted in the first place. I think that's going to feel very confusing and disorienting to be honest. |
I'm 100% for removing yank from A very common pattern for me is the following:
In my personal experience pure deletions (= no yank) happen way more frequently as an action than cuts. A lot of the time I'll delete just a few characters here and there. I really don't need to be able to paste that whitespace, or the character That's why just deleting should be the quickest keypress |
Fwiw I took the (on July 7 2022) suggested keybindings and stuck it in my config. Re-found it today (after a year and something) and thought I'd chip in to say that it just feels less surprising. I have one machine that I rarely ssh into where I forgot to add it, and every time I get hit by suddenly having junk in my register. And every time I have a moment of confusion. I'm a big fan of this editor and I hardly change any default settings. But this change is staying in my config if this change request doesn't make it. |
Tldr: 100% in favour. Well, I just discovered that behaviour even exist, which is fuelled by my recent coding spree. I find yank before change/delete more natural since their function is in their names. Also, as mentioned above, the contents of registers are volatile, making them even more so by yank during change/delete is not user friendly per se. Alt-d is a very obscure thing, I've probably only ever used it handful of times (or at all) throughout 2023. |
There's an issue #6900 for emacs kill-ring proposed in #3001 (comment) I think it would definitely make yanking I don't have a strong opinion here since I'm still getting used to modal editing, but one thing I miss from VS Code is how easy it is to move lines up and down #2245. Currently |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
I think Vim made a mistake by letting
c
andd
pollute the default register by "yanking" the contents of the change or deletion. I'll make a short case as to why I think Helix should make a bold decision to not do this like vim (and maybe even kak).Why not?
The reason why
d
andc
should not also yank is simple, because you can yank befored
andc
easily withy
. You cannot as easily "prevent yank" without knowing about registers and particularly the black-hole register"_
; so you're left with"_d
or"_c
which is too often a use-case to make it not the default behavior. The times when you want to yank before a modification is easily opt-in withyd
andyc
. Simply put, the answer why the default behavior should be inverted: it's the correct UX.Note, in View mode,
y
does not remove the selection like it does in vim. This positions Helix to be able to even consider the correct behavior.With the correct default behavior in place, users can edit happily knowing that when they copy something to their default register many modifications back in their history, they will not accidentally overwrite the default register with
d
andc
. The foot-gun has been holstered.How do we migrate?
Some users (vim and kak alike) will not expect this change and will perhaps not like to modify their habit. However, this could easily be mitigated with a config to change the default behavior back (which is what user's do already). If a user doesn't like the position Helix makes, they can modify the behavior or change their habits.
Please.
The text was updated successfully, but these errors were encountered: