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 https://github.com/zyedidia/micro/issues/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 https://github.com/zyedidia/micro/pull/3335/commits/52ed4315ff521f27b9042f8dfa292cb618370f51.) Actually the last part (about 10 seconds) never really worked, due to a bug in the code (so I threw it away in https://github.com/zyedidia/micro/pull/3335/commits/68d6f43c638673960057117efeb24b945afabf5a).

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 https://github.com/zyedidia/micro/issues/3221#issue-2210520636).
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.

[JoeKar]

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?

After this topic caused a further issue my mind directly agreed.

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).

Highlighting this is fully legit too. But we've already other things which are questionable (especially due to the already grown plugin interface) but more or less untouchable due to the same fact...we would need to brake with some expectation/scenarios/defaults.

I think having this "feature" is indisputable and seems to have users/friends too. So we've to keep it by any means.

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.

But does this really feel consistent? Yes it does the trick, but sounds more like a workarond for not having a direct counterpart action of CopyLine.

BTW: Ctrl-x: Cut|CopyLine,DeleteLine is possible and fulfills the workaround, but displays "Deleted line" as tooltip. :wink:

Maybe we think the other way around. We currently have...

• CopyLine: copies the line and overwrites the clipboard; multiple times the same
• DeleteLine: deletes the line and doesn't touch the clipboard; multiple times the same
• CutLine: cuts the line and adds it to the clipboard; performed multiple times appends the current line when there is no Copy, CopyLine or Cut invoked in between otherwise adds it to a fresh clipboard and starts over again

A CopyLine with "cuts the line and overwrites the clipboard; multiple times the same" feels more intuitive in that row...at least for me.

Furthermore, the following key bindings...

• Ctrl-x: Cut|Cutline
• Ctrl-k: Cutline

...without a selection both do the same.

Would it make a difference, when we change the default binding and add a new action? At least not for the daily end-user, but for plugin developers it might be when they use the CutLine action in plugins and expect it to append the lines.

At this point it seems to be hard to make everyone happy.

[...] my mind directly agreed.

And still does. Keeping the misleading tooltip in mind, the description consistency and the non existing difference (in case of no selection) between Ctrl-x and Ctrl-k.