Cut Line does not work correctly

[Giessen]

Description of the problem or steps to reproduce

Given two lines of texts:
text1
text2

Do following:

1. Cut Line text1 （using command Cut）
2. Cut Line text2
3. Do paste, we get
   "text1
   text2"
   rather than "text2".

Related config

bindings.json:
"Ctrl-k": "Cut",
"Ctrl-u": "Paste",

Specifications

Commit hash: Commit hash: 7d37e72
OS: WSL2/ubuntu 20.04
Terminal: Windows Terminal

[dmaluka]

This is "intended behavior".

If you pull the newest master, you'll find that this behavior is now documented in help keybindings: bf65847

Don't tell me this behavior is confusing and non-intuitive. I know it is.

This behavior, as we recently discovered, was there since a very long time (since #64 + #70). See also our recent discussion here: 52ed431.

It's quite possible that the number of users that find this "feature" useful is exactly zero (I'm not among them, and none of the people I know are among them), so we can safely remove this feature and replace it with the usual intuitive behavior and no one will complain. But I don't know how to verify this hypothesis.

[dmaluka]

Searching through the issues (https://github.com/zyedidia/micro/issues?q=multiple+line+cut) shows that there were multiple users annoyed by this behavior: #2653 #3221 (and no evidence so far that anyone enjoyed this behavior).

[Andriamanitra]

For what it's worth the current behavior matches nano, although nano only combines the cuts if you don't have a selection when cutting (which is IMO more sensible than what micro does). I suspect there are indeed users who use this behavior to move multiple lines. I'm not one of them but the feature does make sense in my opinion.

[Giessen]

Thank you very much for the info. I suggest there be an option to toggle on/off this behaviour. Or it's better to have different commands for intuitive/combining-cuts behaviours.

[MarkZaytsev]

I've prepared a pull request in attempt to fix the issue. Not sure about changing shortcuts thought.