[RFC] Switch to move/copy concept instead of yank/cut/paste

[Brixy]

Is your feature request related to a problem? Please describe

Hi guys!

This may be a far-reaching idea. If it does not fit, please just close this issue ;-)

Currently you can yank or yank --cut single files or a selection of files. In the target directory you paste the files. This is probably how most TUI file managers work.

Will you be willing to contribute this feature?

Sorry – I am not a Rust expert.

Describe the solution you'd like

nnn uses a different concept: You just select one or more file, and in the target directory you either move (v) or copy (p) these files.

This seems more efficient, and I could think of these advantages:

• You need to decide only in the target directory what to do with selected files.
• It is arguably easier to copy or move selected files from multiple directories into a single target folder because there is no need to differentiate between yanking and cutting in advance.
• You just need to color code selected files because there is no need to differentiate between selected, yanked, and cut files.
• It’s actually easier to understand. Currently, if you select and then yank two files, then “re-select” one of those files, there is no visible indication. If you then hit d for example, it’s a bit hard to predict what yazi — and other file managers — will do. The proposed concept just knows two states: selected or unselected. Moving, deleting, and copying only refers to selected files.
• It would be sufficient to just support counting selected files. Again no need to support counting selected, cut, and yanked files, and no need to think about e.g. cutting and then re-selecting files.
• You can simply unselect files and move or copy the rest of the selection.
• No need to support “un-yanking” (see #313) or „un-cutting“ files.
• The current concept for deleting multiple files (first select, then delete) can be transferred to moving and copying.

Possible disadvantages:

• People are used to the current vim-like concept coming from other TUI file managers.
• The proposed concept would not support moving and copying files with one single paste command (which is currently not possible in yazi).

Currently if you want to cut and paste a single file you just need to press x and p.With the proposed concept it would be <Space> and p. There wouldn’t be much difference.

Describe alternatives you've considered

No response

Additional context

No response

[15cm]

Disclaimer: I didn't try nnn.

In the proposal, how do you tell whether your selection is finalized or not, under these scenarios:

• Yank multiple batches of files in the same directory with multiple select operations and then paste then to another directory with one hit.
• Yank multiple batches of files in the different directories with multiple select operations and then paste then to another directory with one hit.

[dan-da]

@15cm what does it mean for selection(s) to be finalized?

It seems to me that selections would always be "finalized" in the sense that at any moment the user could press a key to initiate move or copy of all selected files. After the key is pressed, the selections(s) would disappear along with the original file(s) for a move operation. For a copy operation, the selection(s) could remain, in case another operation is desired.

[15cm]

I didn't realize that multiple selections are supported. I thought I have to select a region, yank, and then select another region. My question got resolved and I'd vote for the proposal as well.

Some thoughts about the yank concept. In the GUI file managers we need ctrl-c or cmd-c to copy because the selection does not persists when you change the directory. However, the selection in Yazi persists until unselect and can serve as the clipboard by itself. I don't see the necessity of the yank clipboard either. The proposal is more like the DnD behavior in GUI FMs, where drop means copy and shift+drop means move.

[Brixy]

It seems to me that selections would always be "finalized" in the sense that at any moment the user could press a key to initiate move or copy of all selected files.

Yes, that’s it. You select as many files (and folders) across folders as you like, and when you are done you just perform a move or copy action in the destination folder. If, yet, the selected files should stay in place, you would just unselect everything using <Esc>.

Currently yanking/coping from multiple source folders is not supported, and it might be confusing.

This proposal would ‘just’ need to support cross folder selection.

[dan-da]

It seems to me that there could also be a symlink action, to keep original files in place, and link to them. Or really I suppose it should be softlink and hardlink, for the two possible types.

[sxyazi]

Sounds quite appealing, I'm still considering its potential pros and cons.

Since this is a proposal that could change user behavior, I'll be adding an RFC tag to see the community's opinion.

[Gajus84]

I like the idea. Maybe along with that a window that allows to quickly see the selected files in a list would then also come in handy.

[magnetophon]

People are used to the current vim-like concept coming from other TUI file managers.

This is a big one for me. For years I have been using almost exclusively programs with vim bindings and it's a pleasure to rely on the same muscle memory throughout my desktop.

[patka-123]

I like this proposal a lot. Pasting the files in the location folder is much more intuitive. It doesn't deviate much from vim if you can just use p to put the file in the destination folder, right?

Or maybe it can be put behind a config value, so both options are possible? I'm not sure what the maintenance burden will be since I'm only a Yazi user that doens't know the code.

[LeXofLeviafan]

Sounds similar to how MC (Midnight Commander) does copying/moving. Though, its default mode is twin-panels…

[sxyazi]

Do we need support for cross-directory operations? If so, I'd like to know more about its details - how does it work?

Consider: I have selected /a/b/c, /a/b, /a. Now, if I cut them to /, what will the directory structure of / look like? Will it be just /a/b/c, or /a, /b, /c, or some other situation?

[Brixy]

Consider: I have selected /a/b/c, /a/b, /a. Now, if I cut them to /, what will the directory structure of / look like? Will it be just /a/b/c, or /a, /b, /c, or some other situation?

That's a good question.

nnn/cp for example will prompt

cp: will not create hard link './b/c' to directory './c' cp: will not create hard link './a/b' to directory './b'

'Enter' to continue

and copy the directories to /a, /b and /c.

If you mark /a and /b/a nnn will just copy a single /a directory.

I hope I got your questions right.

[LeXofLeviafan]

Well, in the abstract sense, it'd make sense to simply copy/move all selected files/folders to the chosen destination (which would result in multiple copies of the same subtree when selected along with its parent for copying, and in the subtree being simply removed from the parent dir when selected for moving). Detecting subtree nesting would be a plus I suppose, though not exactly trivial considering possible existence of symlinks, hard links & bind-mounts.

The case of name collisions is more complicated, but it could be handled similarly to collisions with already existing files during regular copying/moving operations; i.e. when copying/moving a directory on top of existing one, they get merged (with optional confirmation), and in other cases the result would be either replacing the existing file altogether, skipping, or aborting the operation. The only important difference is that when the user tries to move multiple identically-named files, the replacing approach would result in losing all but one of them (…which is technically still viable, but the confirmation request would need to be IN ALL CAPS in this case).

…One way or another, it's probably a good idea to explicitly show the list which files/folders are going to be copied/moved to the user (possibly shortening long lists from the same source, e.g "…and 127 more from the same folder"), and/or all of the source folders (to avoid accidentally copying/moving unintended selection).

[magnetophon]

One way or another, it's probably a good idea to explicitly show the list which files/folders are going to be copied/moved to the user (possibly shortening long lists from the same source, e.g "…and 127 more from the same folder"), and/or all of the source folders (to avoid accidentally copying/moving unintended selection).

Fully agreed. This would also be handy when deleting files, as requested in https://github.com/sxyazi/yazi/issues/285

[sxyazi]

@LeXofLeviafan Ah yeah, this reminds me that we also need to consider the repetition of /a/a/a when selecting /a, /a/a, /a/a/a, as well as how to merge if there's a b under /a and also under /a/a.

To handle these, we'll need to establish a basis in synchronous operations. However, Yazi's copy, cut, and delete are concurrent (which means that if we merge them, b could potentially come from /a/b or /a/a/b, and we can't determine the order of concurrency), and loading the directory tree happens simultaneously with these operations. Both sides are asynchronous, so it's not possible to foresee the complete list of files that might cause conflicts beforehand.

Maybe we can avoid users selecting potentially conflicting files in some way? For instance, displaying an error when /a is selected and /a/b is chosen, or delaying this notification until the user actually pastes. Alternatively, automatically de-selecting /a when /a/b / /a/b/c/d is selected, or /a/b / /a/b/c/d when /a is selected.

...There might be other better ways to handle this. I'm not sure what would be more intuitive; I haven't even used cross-directory file selection before :)

[LeXofLeviafan]

…Can't the operations be enqueued to run sequentially for each selection (potentially grouped by folder)? I.e. when paths A, B and C are selected, and a ‘copy’ to D is requested, there will be 3 operations added to a queue (‘A -> D’, ‘B -> D’, ‘C -> D’), and invoked in that order, polling the queue after completion of each operation. This might complicate the implementation a bit, but it would also make the outcome predictable (the app just needs to confirm how to handle collisions in the first place – which is needed for single path operations as well).

[sxyazi]

This requires introducing a queuing mechanism for the task system and allowing partial tasks to pause and wait for one or more tasks it depends on to complete before resuming.

If we prioritize based on the outermost directory, and execute a copy operation:

• /a/b/file depends on and needs to wait for /a/file;
• /a/b/c/file depends on and needs to wait for /a/b/file, /a/file;
• ...

And when any task on which a task depends fails, it won't be executed and should also be presented as a failure - this is somewhat counterintuitive; we might need to group interdependent tasks in a specific way, which can be very complex.

[Tweoss]

It seems to me that if copying or moving /a and /a/b, it would be okay to move just /a. I think this because /a/b is still copied or moved to roughly the right location (with an offset that user probably understands, given that they selected /a/b). Additionally, this approach likely would not require pausing / waiting (if I understand correctly), as we could merge the paths into their parents prior to executing any actual commands.

For example,/a/b/c + /a + /1/2/3 + /1/2/4 + /1/2 would be pre-processed into /a + /1/2.

I tried this out in Mac's Finder, where I had

- a
  - b
    - c
    - d

then selected /a/b and /a/b/d, and moved them to /. This just moved all of /a/b to /b.

While it does make more sense in a visual file manager like Finder (where you can expand folders without entering them), I think the result was still fairly intuitive.

[og900aero]

I've used several file managers: vifm, ranger, lf, joshuto, and I think the correct operation would be to copy and move only the given directory or/and file itself, not the entire complete path. So, if I select the following files and directories:

/a/b/file.txt /c/file.log /d/one_directory /f/g/a/two_directory

then I want to copy these to the /home/user/Data directory, then the result should look like this:

home/user/Data/file.txt home/user/Data/file.log home/user/Data/one_directory home/user/Data/two_directory

[sxyazi]

@Tweoss Basically agree. I'm just wondering if in this scenario there should be a way to indicate to the user that the outermost directory will be treated as the target.

Maybe when the user selects both /a and /a/b, we could use different colored blocks on the left side: /a in green 🟩 and /a/b in red 🟥.

Does this seem reasonable, or are there any other suggestions?

---

@og900aero If I select /a/file.txt and /b/file.txt, and do a paste them to /, what will happen?

---

Just reminded by @asim215 on Discord, I thought of a tricky question we've never considered - how to handle multi-tabs?

Currently, yank allows users to copy and paste between multiple tabs. With the new mode, does it mean that when a tab has files selected, other tabs will no longer be able to select files? Or does it mean that we will lose the feature of cross-tab file operations?

[Tweoss]

I think the colors make great sense!

In the comparison to Mac's Finder, though, Finder only has a single blue selection color. This does lower the mental work to understand selections. I think, perhaps, one reason to have a single selection state is for operations that don't conflict like copying and moving do. Bulk renaming would be one such operation.

Having colors, then, just distinguishes behavior for moving and copying. Other operations still use that selection.

I did some more experimenting and "New Folder with Selection" first moves selected child folders out to the same level as the selected parent folders, then creates the new folder with the selection. This could be another possible solution (move or copy inner items to topmost level, then proceed with updated selection; equivalently, apply move/copy operations to inner items before outer items).

Funnily enough, Finder produced a malformed archive when asked to archive a child folder / text file and its parent. I guess this shows how this is indeed a difficult problem we're trying to solve.

---

I'm wondering if we could think of tabs as registers. I think that it would be most natural to have each tab with their independent selections; otherwise, we might have a "spooky action at a distance" situation where some selections in different tabs are red or green for non-obvious reasons.

Additionally, pasting into, for example, tab 2 from selections in tab 1, 3, and 4 with a non-trivial merging heuristic would probably be very confusing.

For those reasons, perhaps we could treat each tab as a register, and enable pasting from different tabs with some bindable command. By default, p in a tab would paste from that tab's own selection. I'm not sure how we would have keybinds to paste from different tabs, as the numbers are already used to switch tabs. Ideally, 1p would paste from the first tab, but that is a conflict.

I can see how this register approach could add complexity to the mental model, so perhaps it is not the ideal approach.

[og900aero]

@Tweoss Basically agree. I'm just wondering if in this scenario there should be a way to indicate to the user that the outermost directory will be treated as the target.

Maybe when the user selects both /a and /a/b, we could use different colored blocks on the left side: /a in green 🟩 and /a/b in red 🟥.

Does this seem reasonable, or are there any other suggestions?

@og900aero If I select /a/file.txt and /b/file.txt, and do a paste them to /, what will happen?

Just reminded by @asim215 on Discord, I thought of a tricky question we've never considered - how to handle multi-tabs?

Currently, yank allows users to copy and paste between multiple tabs. With the new mode, does it mean that when a tab has files selected, other tabs will no longer be able to select files? Or does it mean that we will lose the feature of cross-tab file operations?

If you were to perform operations on the same location with files of the same name on different routes, then the current setup could remain, so

{ on = [ "p" ], exec = "paste", desc = "Paste the files" }, { on = [ "P" ], exec = "paste --force", desc = "Paste the files (overwrite if the destination exists)" },

In other words, you copy to p by leaving the first one copied and renaming the next one, and to P the last file with the same name would overwrite the previous one.

I do not support the introduction of different colors for files in different places. I think the different colors should be associated with actions. For example: Select - green (might better color is purple) Copy - yellow Cut - red

In the case of selections made on different tabs, two solutions are possible:

• Selections made on each tab (select, copy, cut) are independent of each other. This is more difficult to solve and I think it unnecessarily complicates the code
• All selections (select, copy, cut) on any tab are automatically synchronized with the other tabs. This is a simpler solution and does not complicate the code unnecessarily

Furthermore, I consider it important that if copying from different places to one place is realized, then there should be a function such that when the copy or cut operation is realized, the selections are automatically deleted after select, copy, cut. Otherwise, an action that we do not want may occur afterwards (deletion is an example). It would be good to link this action to a button, for example, because I have had many files selected for copying, but I changed my mind and wanted to delete the selection for copying, but I don't know, I can only delete the simple select action with ESC. The copy, cut mark is no longer there. I had to exit the program and then back in to get them deleted.

[asim215]

Here is my usecase which I mention in discord.

Actions: 1) select files in tab1 and press 'x' to cut them; 2) switch to tab2 to clear target directory by deleting files/directories using 'D' (permanent delete); 3) put files in the target directory by 'p' key.

With independent selections and actions for different tabs I able to remove selected files/dirs in (2) without affecting (deleting) files in source directory (1). And then put them (3) in target directory.

Therefore I find this way which yazi works right now is better for me, than having shared selection across multiple tabs. With which I am force to do steps (2) -> (1) -> (3). With current implementation both ways is possible but with different one by pressing delete at step (2) I will remove selected files from source directory on step (1). Because selection will be shared without assinging to action immiediately. Therefore only 2-1-3 be possible. For exaple in dolphin file manager you can cut files, then make cleaning in target directory, then put files there.

[sxyazi]

@Tweoss:

In the comparison to Mac's Finder, though, Finder only has a single blue selection color. This does lower the mental work to understand selections. I think, perhaps, one reason to have a single selection state is for operations that don't conflict like copying and moving do. Bulk renaming would be one such operation.

Having colors, then, just distinguishes behavior for moving and copying. Other operations still use that selection.

Does this mean using different colors ONLY for copy/paste operations and ONLY for conflicting files (when both /a and /a/b are selected, and /a/b is a conflicting file)?

And NOT using different colors for batch renaming of /a/b? If that's the case, we wouldn't be able to predict the user's intended action before the user actually presses a key.

@Tweoss:

For those reasons, perhaps we could treat each tab as a register, and enable pasting from different tabs with some bindable command. By default, p in a tab would paste from that tab's own selection. I'm not sure how we would have keybinds to paste from different tabs, as the numbers are already used to switch tabs. Ideally, 1p would paste from the first tab, but that is a conflict.

I can see how this register approach could add complexity to the mental model, so perhaps it is not the ideal approach.

@og900aero:

Selections made on each tab (select, copy, cut) are independent of each other. This is more difficult to solve and I think it unnecessarily complicates the code

Yeah I believe this would add to the user's cognitive load and could hinder users from utilizing the multi-tab functionality.

It would also pose an obstacle to achieving a "side-by-side layout" similar to Ranger in the future. In short, Ranger achieves a side-by-side layout by merging two tabs into one, which requires convenient file interactions between tabs. For more details https://github.com/sxyazi/yazi/issues/51#issuecomment-1718033508

This problem is tricky, unfortunately as of now, I haven't come up with a better solution, and this would be one of the barriers preventing the implementation of this RFC.

@og900aero:

I do not support the introduction of different colors for files in different places. I think the different colors should be associated with actions. For example: Select - green (might better color is purple) Copy - yellow Cut - red

Nope, according to this RFC, we won't have colors for cut and copy anymore. They will all ultimately be just selections, dependent on what action the user takes after selecting (cut or copy, based on one key pressed), and we can't predict the user's behavior.

@og900aero

All selections (select, copy, cut) on any tab are automatically synchronized with the other tabs. This is a simpler solution and does not complicate the code unnecessarily

I'm not sure if this is reasonable; maybe it's the only way to keep the current behavior, although we would still lose tab-specific selection capabilities - it would lead to all tabs sharing a single selection source.

[asim215]

@sxyazi I agree. I think each actions must have separate queue of files on which it is operating. We just can assign to each action different color or symbol beside selected files.

For example: Simple selection without action is without symbol. After selection and pressing cut we can put symbol 'x' on the left side of file and color coded it. For yank -> 'y' with different color. For past files 'p' for recently pasted files until new past happen, then remove 'p' marker.

Current behavior is better than having one selection buffer across all tabs in my opinion.

[hakan-demirli]

Why don't we just let the user customize select buffers/registers and operations together with key bindings in lua? If the select and command parts of the API are separated any implementation can be achieved by the user.

By default yazi can ship with a script that utilize a single SelectBuffer and multiple functions for move/copy concept where you decide what to do with them. Something like below, a psuedo code.

buffer = SelectBuffer('red')

bind, space, buffer # select/delesect file

bind, c, function move(buffer){
     for file/dir in buffer:
        # perform move operation
}

bind, p, function copy(buffer){
     for file/dir in buffer:
        # perform copy operation
}

Or a user can implement a design with two select buffers/registers and a single paste operation.

cut_buffer = SelectBuffer('red')
copy_buffer = SelectBuffer('yellow') 
buffers = [cut_buffer,copy_buffer]

bind, c, cut_buffer    # select/deselect for this specific buffer
bind, y, copy_buffer # select/deselect for this specific buffer

bind, p, function paste(buffers){
     for buffer in buffers:
         for file/dir in buffer:
            # do whatever you want
}

SelectBuffer Object/API can even be further customized via arguments to indicate wheter it works on multitab layout etc.

SelectBuffer('red',single_tab=true) # select is only visible in the current tab
SelectBuffer('red',single_tab=false) # select is visible across tabs

This will also cut down the future issues from people who are migrating from other terminal file managers. WIKI might contain configs for lf, ranger and mc which should help attracting more users who are reluctant to learn new paradigms.

[og900aero]

Anyway, I like the vifm file manager solution the best for me. There is no separate button for selecting copy and cut, but there is only a simple selection, and the paste function is divided into the following:

little p -> paste with copy big P -> paste with move (cut)

[sxyazi]

@hakan-demirli:

Why don't we just let the user customize select buffers/registers and operations together with key bindings in lua? If the select and command parts of the API are separated any implementation can be achieved by the user.

Hmmm, I don't think these modes can coexist well. Handing over the decision-making to users also means transferring the tricky problems we currently face to them.

Additionally, as we add new features, we must constantly consider not disrupting the various configurations users might have, and file copying and moving belong to the baseline of a file manager — users generally shouldn't need to configure it.

@og900aero:

Anyway, I like the vifm file manager solution the best for me. There is no separate button for selecting copy and cut, but there is only a simple selection, and the paste function is divided into the following:

Yeah that's exactly what this RFC aims to achieve. I want to know how vifm handles multi-tab issues, or does it not have multi-tabs at all? I haven't used vifm...

[hakan-demirli]

transferring the tricky problems we currently face to them

This is indeed a valid point but neovim project is a strong counter example against it. Neovim users indeed has to deal with all the intricacies and internals of an IDE but only if they wish to customize further. The whole project distinguish itself from its predecessor vim by offering extensive APIs and performance improvements. The complexity and problems are not directly transferred to users but to plugin developers. So, yazi can be seperated to two yazi-core and yazi where yazi-core offers high performance async APIs to plugins and yazi is just a wrapper using sane defaults.

But I understand if such a thing is outside the scope of yazi and such feat might not be achievable considering the limited number of contributors compared to neovim.

[og900aero]

@og900aero:

Anyway, I like the vifm file manager solution the best for me. There is no separate button for selecting copy and cut, but there is only a simple selection, and the paste function is divided into the following:

Yeah that's exactly what this RFC aims to achieve. I want to know how vifm handles multi-tab issues, or does it not have multi-tabs at all? I haven't used vifm...

vifm doesnt have multitabs. Vifm works like mc dualpane, but there is a twist, because the second window can be switched to preview. See in the photos. Anyway, this solution is not bad either. With the help of this, I got used to mc and started to get used to the one-window solution, because if I want to copy or move files, then switched two panes, if not, then I used it as one pane with preview. I assigned the switch to the letter i. Then came to ranger, then lf, and yazi :)

[Tweoss]

@sxyazi I know you mentioned that adding a queueing mechanism for sequential command execution would be complex. How would you feel about if instead of an arbitrary number of dependency levels, instead there were just two?

I suggested earlier (in parentheses) that perhaps we could move / copy inner files and directories before outer directories. This would mean a few levels of queueing. However, if the original directory is never modified (as in the copy case), all copies can proceed in parallel.

Thus, the only issue is when we move entries and their parent directories.

If we were able to have just two groups, where one group was guaranteed to finish before the other, then we could move all the topmost directories into a /tmp directory. Then, because we have a guarantee that these /tmp files will never be modified, and thus the paths will not be broken, we can copy all files and directories into the destination in parallel.

Say we have a directory structure like this.

a
- b
- c
  - d
e

If we want to copy /a/b, /a/c, and /a/c/d to /e, we would simply copy them to /e/b, /e/c, and /e/d resulting in the below structure.

a
- b
- c
  - d
e
- b
- c
  - d
- d

Now, if we want to move /a/b, /a/c, and /a/c/d to /e, we would first move the topmost directories to /tmp.

a
e
tmp
- b
- c
  - d

Then, we would copy from /tmp into /e. Thus giving us the below structure.

a
e
- b
- c
  - d
- d

Note that d now appears twice. This behavior is different than if we queue move operations by hierarchy. I feel like if we tried to avoid this duplication, then we would have to have arbitrary levels of queueing. However, I'm not sure if this is true.

[rasmus-kirk]

@hakan-demirli:

Why don't we just let the user customize select buffers/registers and operations together with key bindings in lua? If the select and command parts of the API are separated any implementation can be achieved by the user.

Hmmm, I don't think these modes can coexist well. Handing over the decision-making to users also means transferring the tricky problems we currently face to them.

Additionally, as we add new features, we must constantly consider not disrupting the various configurations users might have, and file copying and moving belong to the baseline of a file manager — users generally shouldn't need to configure it.

@og900aero:

Anyway, I like the vifm file manager solution the best for me. There is no separate button for selecting copy and cut, but there is only a simple selection, and the paste function is divided into the following:

Yeah that's exactly what this RFC aims to achieve. I want to know how vifm handles multi-tab issues, or does it not have multi-tabs at all? I haven't used vifm...

Don't know about vifm but nnn has a single selection buffer that is shared by all tabs, furthermore it is also shared by all instances of nnn. This means that if I open two different terminal sessions and open nnn on both, they will share the selection buffer. All nnn sessions write to a single file (~/.local/state/nnn/selection or something) which is just a list of filepaths:

/path/to/file/a
/path/to/file/b

This is very useful for a tab layout that is tied to the display manager. It also allows for easy integration of scripts that works on the selection (custom batch-rename, playlist creator, etc), by just having the script load in the ~/.local/state/nnn/selection and pass it to external commands.

[fritzrehde]

lf also has a similar feature where the selection buffer is shared between all instances of lf, if I remember correctly.

[og900aero]

It looks like this ticket was died. Any chance of this happening?

[sxyazi]

How about "Keep yank but allow cross-level yank, then merge #313"? This is currently the easiest to implement and doesn't disrupt existing user behavior; it would only be an enhancement.

If using select instead of yank, copying/cutting files comes from the selected files, this would result in losing the ability to copy/cut across tabs because the selection status of different tabs is independent.

As for multi-instance state synchronization, it is an independent and opt-in feature, I would like to try implementing it through the plugin system and discuss it separately, such as which states need to be synchronized (selection status, yank status, etc.), when to synchronize (only at startup or in real-time), and how to implement it (as a synchronization plugin or an RPC plugin).

[og900aero]

As for multi-instance state synchronization, it is an independent and opt-in feature,

It is also a good solution to begin with, if the selection for copying can work from several independent libraries/files. But the best solution would be to select any file anywhere, synchronize it to another tab, another instance of yazi in real-time, and have a separate command for copy and cut, which is executed on the selected files and/or folders.

[sxyazi]

As for multi-instance state synchronization, it is an independent and opt-in feature,

It is also a good solution to begin with, if the selection for copying can work from several independent libraries/files. But the best solution would be to select any file anywhere, synchronize it to another tab, another instance of yazi in real-time, and have a separate command for copy and cut, which is executed on the selected files and/or folders.

It conflicts with https://github.com/sxyazi/yazi/issues/319#issuecomment-1849163109 and https://github.com/sxyazi/yazi/issues/319#issuecomment-1849614660

[og900aero]

As for multi-instance state synchronization, it is an independent and opt-in feature,

It is also a good solution to begin with, if the selection for copying can work from several independent libraries/files. But the best solution would be to select any file anywhere, synchronize it to another tab, another instance of yazi in real-time, and have a separate command for copy and cut, which is executed on the selected files and/or folders.

It conflicts with #319 (comment) and #319 (comment)

Actions:

select files in tab1 and press 'x' to cut them; switch to tab2 to clear target directory by deleting files/directories using 'D' (permanent delete); put files in the target directory by 'p' key. With independent selections and actions for different tabs I able to remove selected files/dirs in (2) without affecting >(deleting) files in source directory (1). And then put them (3) in target directory.

It is not a good idea to issue different selections and actions on two different tabs of a file manager at the same time. This is specifically a very big mistake that can cause quite big problems. It is no coincidence that there is no known file manager that allows this.

[sxyazi]

@og900aero Hmm, to the best of my knowledge, any file manager that supports multiple tabs behaves in this way. Whether it's a TUI or a GUI, they all allow operations independent of tabs and enable copying or moving files between tabs. I use it like this every day, and otherwise, I'm not sure what the purpose of having multiple tabs would be.

[og900aero]

@og900aero Hmm, to the best of my knowledge, any file manager that supports multiple tabs behaves in this way. Whether it's a TUI or a GUI, they all allow operations independent of tabs and enable copying or moving files between tabs. I use it like this every day, and otherwise, I'm not sure what the purpose of having multiple tabs would be.

Yeah. That's normal for copy or cut between tabs (example yank files on tab 1 and paste in tab 2), but not normal for yank files on tab 1 and cut files on tab 2 and select files on tab 3, and paste operation whatever tab, because in such cases it is not possible to clearly decide what the good solution is. This case is not supported by any known file manager.

[Brixy]

Thank you for all the feedback.

I think it boils down to two concepts:

1) Select files/folders -> cd somewhere -> press p (paste) or v (move).

Color coding etc. is a bit easier, see https://github.com/sxyazi/yazi/issues/319#issue-1960166678.

2) Select files/folders -> x (cut) or y (yank) -> cd and to other stuff -> p to move or copy files.

The bolded part is probably very important for most people, as mentioned in https://github.com/sxyazi/yazi/issues/319#issuecomment-1849614660.

In combination with #313 2) is probably what most people want, expect and are used to, even if coming from GUI file managers.

(If -- in addition -- x and y could be used simultaneously [and maybe even accross folders] it would be a phantastic addition. But it’s more complex than expected, see https://github.com/sxyazi/yazi/issues/319#issuecomment-1838484347, https://github.com/sxyazi/yazi/issues/319#issuecomment-1849025168 and other comments.)

EDIT: Cross posting. I did not read your latest comments before posting this 😉

[sxyazi]

@og900aero Hmm, to the best of my knowledge, any file manager that supports multiple tabs behaves in this way. Whether it's a TUI or a GUI, they all allow operations independent of tabs and enable copying or moving files between tabs. I use it like this every day, and otherwise, I'm not sure what the purpose of having multiple tabs would be.

Yeah. That's normal for copy or cut between tabs (example yank files on tab 1 and paste in tab 2), but not normal for yank files on tab 1 and cut files on tab 2 and select files on tab 3, and paste operation whatever tab, because in such cases it is not possible to clearly decide what the good solution is. This case is not supported by any known file manager.

I think you've confused some concepts. Please take some time (perhaps around 10 minutes) to carefully read the content of this RFC and the discussion below.

In short, Yazi is currently not exhibiting the behavior you described, nor is it heading in that direction. I don't want to provide further repetitive explanations here, sorry.

[sxyazi]

Thank you for all the feedback.

I think it boils down to two concepts:

1) Select files/folders -> cd somewhere -> press p (paste) or v (move).

Color coding etc. is a bit easier, see #319 (comment).

2) Select files/folders -> x (cut) or y (yank) -> cd and to other stuff -> p to move or copy files.

The bolded part is probably very important for most people, as mentioned in #319 (comment).

In combination with #313 2) is probably what most people want, expect and are used to, even if coming from GUI file managers.

(If -- in addition -- x and y could be used simultaneously [and maybe even accross folders] it would be a phantastic addition. But it’s more complex than expected, see #319 (comment), #319 (comment) and other comments.)

EDIT: Cross posting. I did not read your latest comments before posting this 😉

Perfect summary!

[evanescente-ondine]

What about a poll ?

[rharmonson]

Anyway, I like the vifm file manager solution the best for me. There is no separate button for selecting copy and cut, but there is only a simple selection, and the paste function is divided into the following:

little p -> paste with copy big P -> paste with move (cut)

There is no one right way to delete/copy/move files but I came here to see if vifm's method had been considered.

In vifm d+d deletes selected file(s) and moves to a trash directory which can then be p to paste (move) or u to undo. Ultimately, it results with one very comfortable (to me) delete or move operation.

Outside of the yazi's delete feature, I love what I am seeing. It a very nice file manager.

[jyothisv]

My two cents: conflicts arising out of multi-direct selection need to be addressed anyway as they happen now also when selecting files from fd's output.

Suppose we have files named a.txt in two or more sub-directories. Searching for a.txt using fd would list all of them. Now we can select, yank/cut, and then paste them into another directory. If this sequence is done using yazi, the output file would be just one a.txt (I don't know if there is any guarantee on which one). Similar operations in lf copies all files - one file would be named a.txt and the others would have suffixes like ~1~, ~2~ etc. This makes more sense to me.

[evanescente-ondine]

The renaming scheme should be customizable, just like graphical file managers ask how to rename individual files in case of conflict. But any scheme would do imho.

[sxyazi]

So, how about this proposal? Let's start with the simplest approach.

This RFC covers too many aspects (abolishing yank, cross-level selection, multiple tabs, state synchronization, conflict resolution, custom renaming schemes), and there are conflicts between them, making it challenging to implement this RFC.

[jyothisv]

So, how about this proposal? Let's start with the simplest approach.

This RFC covers too many aspects (abolishing yank, cross-level selection, multiple tabs, state synchronization, conflict resolution, custom renaming schemes), and there are conflicts between them, making it challenging to implement this RFC.

This covers one important use-case for me: within the same tab, I would be able to select files from multiple directories, go to the destination directory, and only then decide whether to move/paste.

[Brixy]

So, how about this proposal? Let's start with the simplest approach.

I would like to second this -- despite the original proposal of this thread.