pasting multiple lines after cutting

[465788227]

When pasting, we get as many lines as we have cut before by ctrl-x.
But how can i paste just one last line?

[ghost]

I think what you're describing is an issue that's been bothering me for the longest time as well, but I never opened an issue about it.

In the nano editor, which I remember micro was inspired by, the cut buffer is cleared when you move the cursor and cut again, so if you cut 5 lines in a row and then paste them, you get all 5, but if you cut 1 line, move, cut another, then paste, you only get the second one. This is the behavior I think both you and I want.

I looked briefly at the source code for this a little bit a long time ago. Apparently, micro has some more complex rules for deciding when to clear the cut buffer, that I still don't completely understand.

[Gavin-Holt]

Hi

I think this is addressed in #3221

Experimenting CTRL+X overwrites the clipboard.
But CutLine appends the line to the clipboard.

If you want to replace the clipboard with the current line try binding CTRL+K like this:

    "Ctrlk": "SelectLine,Copy,Delete",

Kind Regards Gavin Holt
Please close if this fixes your problem

[dmaluka]

Came here from #3477.

I looked briefly at the source code for this a little bit a long time ago. Apparently, micro has some more complex rules for deciding when to clear the cut buffer, that I still don't completely understand.

Those rules are indeed tricky: the cut buffer is cleared if it has been already pasted at least once, or if the last cut was more than 10 seconds ago. (I also described it in the commit message in my 52ed431.) Actually the last part (about 10 seconds) never really worked, due to a bug in the code (so I threw it away in 68d6f43).

So the actual rules are simply: the cut buffer is cleared if it has been already pasted at least once.

Still, yeah, this behavior is not quite intuitive, and doesn't seem quite useful. I would be happy to throw it away, if I could be sure there are no users that actually prefer this behavior.

In the nano editor, which I remember micro was inspired by, the cut buffer is cleared when you move the cursor and cut again, so if you cut 5 lines in a row and then paste them, you get all 5, but if you cut 1 line, move, cut another, then paste, you only get the second one. This is the behavior I think both you and I want.

Yeah, this behavior sounds more useful than the current one.

Honestly, I wouldn't bother even with that, I'd prefer to replace the current behavior with the simplest and the most intuitive and predictable one: always cut single line only. I guess that is what a lot of users would prefer over any multiline cut functionality, see e.g. #3477 and #3221.

@JoeKar @Neko-Box-Coder @Andriamanitra so I'm thinking: what if we replace the current behavior with the simple single-line-cut only one (i.e. make CutLine equivalent to CopyLine,DeleteLine) and then see if we get any user complaints over a couple of months. WDYT?

(And then maybe in the future we add back multiline cut functionality as well, in one form or another, with a separate action e.g. CutMultiline, for those users who prefer it.)

[dmaluka]

Or perhaps removing multiline cut functionality altogether right away would be too drastic, so instead:

1. Make CutLine equivalent to CopyLine,DeleteLine (no multiline cut), but also add CutMultiline and change the default binding of Ctrl-k from CutLine to CutMultiline (but keep Ctrl-x bound to Cut|CutLine by default, not to Cut|CutMultiline, thus address the valid point raised in set to make ctrl+k remember last buffer not all #3221 (comment)).
2. Make CutMultiline behavior more sane than the current one, e.g. more nano-like.

BTW the current behavior has an "advantage" over nano: it allows cutting lines that are not necessarily consecutive. But I'm not sure if this "advantage" was implemented intentionally, not just thoughtlessly.

[Neko-Box-Coder]

@dmaluka

Yeah, I agree we should change ctrl-x default to match what people would expect, cutting a line.

BTW the current behavior has an "advantage" over nano: it allows cutting lines that are not necessarily consecutive. But I'm not sure if this "advantage" was implemented intentionally, not just thoughtlessly.

I think the current multiline cut implementation is quite cool (although I don't really use it) but if enough people expect it to behave exactly like nano (even though we never said it behaves like nano), then maybe should change it.

1. Make CutLine equivalent to CopyLine,DeleteLine (no multiline cut), but also add CutMultiline and change the default binding of Ctrl-k from CutLine to CutMultiline (but keep Ctrl-x bound to Cut|CutLine by default, not to Cut|CutMultiline, thus address the valid point raised in

Separating the multiline cut feature as CutMultiline seems reasonable to me.

[Andriamanitra]

what if we replace the current behavior with the simple single-line-cut only one (i.e. make CutLine equivalent to CopyLine,DeleteLine) and then see if we get any user complaints over a couple of months. WDYT?

I don't like messing with the defaults without a really good reason because it always surprises some users (even if they are not annoyed enough to raise an issue about it).

However I think most of the surprising behavior would be addressed by changing CutLine to only append the line to clipboard contents if the previous contents exactly match what they were after the last CutLine action. If the user does a Copy or Cut in between then CutLine would just replace the clipboard contents with the line that was cut. The cases where you'd want to append a line to clipboard contents are so niche that I find it highly unlikely that any real users are currently relying on that quirk.

The idea to add a separate CutMultiline action is also valid but I'm not entirely convinced that a separate action is warranted because the proposed new CutLine behavior can already be easily had with CopyLine,DeleteLine.