Working with items marked for deletion/move

[dumblob]

Currently it seems impossible to work with items marked for deletion/move. I was thinking about unification of yanking and marking-for-deletion/move into one operation. If it won't happen in the default configuration, I would like to have this opportunity in my configuration. In case they won't get unified, two things for a user configuration seem to be missing:

1. possibility to programatically read the marked-for-deletion/move items
2. possibility to set the color of the mark of the marked-for-deletion/move items

I wonder what was the motivation to separate yanking and marking-for-deletion/move? Could someone please enlighten me? The marking-for-deletion/move seems completely redundant to me currently :(

[occivink]

unification of yanking and marking-for-deletion/move into one operation

Seconding this. In my config I unmapped the mark-for-deletion/move and mapped new commands to delete/move all marked files.

[gokcehan]

@dumblob I'm a little confused by the terms used here so I may not have understood this correctly. If we unify yank and delete commands then how do we distinguish about copying the file or moving it?

For your first item, you can currently read deleted item with load remote command. There is an example for this in the documentation. For your second item, I didn't understand what you need. Semantically what do expect to have when colors are changed? Can you give use cases as examples?

@occivink The idea is, if you have two clients operating on different directories and you want to copy files between these two directories, you can simply mark items you want and yank them in the first client, and then paste them in the second client. If you don't use lf with multiple clients, then I guess your approach might save a few steps.

[occivink]

distinguish about copying the file or moving it

I guess you could have one key to "move all marked files here" and another to "copy all marked files here". That's the kind of paradigm that I'm personally using.

Also you're right that I'm usually not using the client-server feature, but I imagine that you could share the "unified" marks so that you could copy/move between two clients.

[dumblob]

@gokcehan the point is, that both copy and move operations are taking a list of items as their first argument and the destination as their second argument. From the UX point of view, the user usually thinks in steps and thus the user wants in the first step say "I will work with these items" and first in the second step decide what she actually wants to do (either copy or move). In practise it looks exactly like @occivink outlined.

With regards to more clients I would very much like to share the selection across clients - exactly as @occivink wrote.

[gokcehan]

Ok I think it's clear to me now. I should first point out that the current way is how all file managers that I know of works including ranger (and also maybe vim). Your alternative suggestion gets rid of one of the steps for file copy/cut/paste. Since we should keep multiple client use as it is, our only possible option is to share marks among clients. Two things come to my mind. First, is there a use for having separate marks in each client, if so we would be breaking that use. Second, we need to sync marks in all clients and redraw ui at each toggle event. Is the performance overhead relevant here? I'm worried that this could be especially noticeable for crowded selection.

On the other hand, maybe it is best to make this optional. It is already possible to do this for single client use as @occivink mentions. If there is an easy way to make this possible for multiple clients use we can work on that without changing the current implementation.

[dumblob]

First, is there a use for having separate marks in each client, if so we would be breaking that use.

Can't speak for others, but I personally do not need different marks in each client. I somehow tend to use marks for the shortest time possible - either just for one operation (which is the major case) or for a set of operations (but in this case I try to not interrupt the workflow as otherwise I'm getting lost in the whole context).

Second, we need to sync marks in all clients and redraw ui at each toggle event. Is the performance overhead relevant here? I'm worried that this could be especially noticeable for crowded selection.

I wouldn't be worried about performance as the changes are both not frequent and not periodic.

[dumblob]

If there is an easy way to make this possible for multiple clients use we can work on that without changing the current implementation.

Any idea how to achieve the synchronization? I'd very much like to have it synchronized.