Re: copy/move live-update

[Mooffie]

On 10/15/16, Yury V. Zaytsev  wrote:
> On Fri, 14 Oct 2016, Rikishi 42 wrote:
>> [snip]
>
> This could be an interesting feature to implement: if I remember
> correctly, Volkov Commander did that [...] it removed the selection
> dynamically from the files already copied, so you could literally see how
> your files float from one directory to another.

Good news: MC already does this. But it doesn't repaint the panel, so
you don't see anything happening there.

I wrote little snippet for mc^2 to repaint the screen as files get unmarked:

https://gist.github.com/mooffie/8ebf543f1dbd717410744114be9cc31f

(You can also drag the progress dialog to see the file list beneath.)

>
> if I remember correctly, Volkov Commander did that [...]

I know this feature from Dos Navigator. Seeing this was a huge wonder
for me. Like seeing Wolfenstein 3D for the 1st time. I was a teenager
in school back then and I couldn't understand how text partially
obscured by the dialog above it (the progress dialog) could change. It
even worked when the shadow of the dialog fell on it!
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: Norton Commander's make-believe features

[Mooffie]

On 10/15/16, Rikishi 42  wrote:
> On 14/10/16 15:35, chris glur wrote:
>>> ..the presence of very basic defects in the file
>>> management functions.
>>> [...]
>>> Peter Norton would not be happy.
>>
>> Please describe some of these.
>
> - copies are made in the disk order, instead of taking the sort order
> that is chosen for the display

MC does use the display order, for marked files.

For subdirs it uses the disk-order, but so does your beloved Norton
Commander, and FAR, and Volkov, and Dos Navigator (I've just checked
all of these; To be exact, they seem to use name order, but I suspect
this comes from the DosBox/Wine emulation layer).

> - when some of the files are allready on destination, and one choses to
> skip, their number and volume should be substracted from the total
> count/size. In that way the estimates mean something.

This doesn't look like a really useful feature. And, as @Mike
explained, it's not at all one that's easy to implement.

> - the move function still copies all, before removing the files, meaning
> that we gain nothing in volume until all has been copied

Here I agree with you.

(@Yury explains why the current behavior is intentional (to make the
entire move operation atomic), and this certainly makes sense when one
thinks about it, but it might be nice to have an option to turn this
off.)

>
> - the move function doesn't give an estimate during it's work

It does.

> NC (it's ancestor) [was] a file/dir manager, not a terminal.
>
> I'm amazed at the resources and time that go into the terminal maintenance
> and development
> [...]
> Peter Norton would not be happy.

DOS wasn't multitasking. NC was spawning a new COMMAND.COM instance to
process each command you typed, and went into hibernation till it
finished. Unix, OTOH, is multitasking. MC spawns only one shell
process, and communicates with it. This makes a huge difference (and
is why, I guess, many MC users appreciate it and don't switch to any
of the other similar Unix filemanagers).
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc