Open 465788227 opened 1 year ago
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.
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
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.)
Or perhaps removing multiline cut functionality altogether right away would be too drastic, so instead:
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).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.
@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.
- Make
CutLine
equivalent toCopyLine,DeleteLine
(no multiline cut), but also addCutMultiline
and change the default binding ofCtrl-k
fromCutLine
toCutMultiline
(but keepCtrl-x
bound toCut|CutLine
by default, not toCut|CutMultiline
, thus address the valid point raised in
Separating the multiline cut feature as CutMultiline
seems reasonable to me.
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
.
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 newCutLine
behavior can already be easily had withCopyLine,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 sameDeleteLine
: deletes the line and doesn't touch the clipboard; multiple times the sameCutLine
: 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 againA 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
.
When pasting, we get as many lines as we have cut before by ctrl-x. But how can i paste just one last line?