Should paste also clear by default?

[devnull09]

One of the things that annoyed me about lf was that selected files stayed marked.
I solved this by mapping the paste key to clear as well
map p : paste; clear

I tried using the default for a while to see if there is a good reason for this behavior but I cant really thing of a good reason why things like the copy/move buffer should survive reboots.
Logging in and finding marked files from copy operations a few days in the past has no use I can think of.

So should the default be changed?
I think that the buffer should at least be cleared at reboot (or rather when the lf server process is stopped).

Does anyone know good reasons to keep the buffer permanently?

[gokcehan]

@devnull09 This was implemented in #745 to be able to paste the same selection multiple times to different directories. At the time I didn't mind since it was possible to get the previous behavior with your example (e.g. map p :paste; clear). I also did not mind making it the default since technically this is the same behavior you get in regular gui file managers. However, after using it for a while I agree this may not be the best default for lf.

@laktak What do you think? Shall we change the default back to the previous one? It would still be possible to get the current behavior (e.g. map p paste).

[gokcehan]

@laktak A counter-argument would be that keeping the selection is more like an extra feature that you can start looking for once you need it which is otherwise still usable without it, but if you don't expect this behavior it can somehow shoot you in the foot. If this was not configurable and there was only a single choice, personally I would prefer the previous behavior because it is often the common use case that you only paste the files once. Wasn't this kind of similar to why you introduced dir selection in #849 later on that you can forget you were working on a different directory?

[laktak]

Not sure if we are all talking about the same thing.

lf has three types of selections (and IMO the display could be improved #754):

• selecting (for an operation)
• copy
• move

This issue is about clearing the copy selections after the paste. I don't see how you can shoot yourself in the foot with that? When I did #745 I thought this was a bug.

If you want to copy something else you would have to copy/yank the files first. That operation takes the marked files and sets them to copy (discarding the previous copy selection).

The PR in #849 is for taking the selection only from the current directory.

[gokcehan]

@laktak For example, you can accidentally copy the files to the same directory twice. This can happen when the copying takes some time since the files do not show up immediately in the directory.

The current behavior is also not consistent with cut files where you could also come up with some use cases for keeping the cut files either as selected or cut files in their new place after the paste.

Since this is already configurable and we are only discussing the defaults here, I think it boils down to you considering the previous behavior as a bug. Why do you think it was a bug? How often do you really copy the same files to multiple locations?

[laktak]

Why do you think it was a bug?

Because, as you said, this is the default in most other filemanagers. I've used this on a number of occasions - I wouldn't have noticed otherwise.

But as you also said, this is a default. As long as I can configure lf to do it my way I'm OK with it. You asked for my opinion and I still think the common case is as it is now ;)

[devnull09]

Im still uncertain which is the better default behavior, especially since as @laktak correctly mentioned, its the default behavior for most file managers.
The one thing that is different in lf is that copy and move operations visibly mark files and keep this marking until it is manually cleared which makes it annoying.

Keeping files marked during the lifetime of the lf process is one option that comes to mind.
Alternatively, saving the marked file list in a tmpfs path like /tmp or /run would reset the marking at reboot.

Personally I would reset the marked file list when the lf client is closed but Im not sure what would be a sane default for everyone.
All I know is that I keep running into marked files in some less visited directories and wonder how many days ago I marked it and for what reason. Its not helpful to keep it persistent for days.

[devnull09]

If there is a use case to keep the selection for multiple paste actions, could we at least have the marked file list cleared when lf (server) is stopped? Assuming there is a clean and easy way to implement this at least.

[laktak]

That's not a good idea. The server stops when the last lf instance exits. If I only use one lf instance the files would be gone the next time I start lf.

[devnull09]

Maybe the server process is not a good trigger then, but I think it would make sense to clear the selection at reboot.

Logging in to find the file selections from the last day is not really useful and it happens a lot to me.
Personally I went and made a script that just deletes ~/.local/share/lf/files at logout to solve this, but it should really be handle by lf instead of annoying the user.