Rename operation behaviour is not natural to file managers

[igorp1024]

After renaming the file in mc cursor stays on same position it was though the file is being put to the file list according to sort order.
I.e., if there 3 files

file1
file2
file3

and I'm renaming the first file 'file1' into 'zfile1' cursor will stay on the first position. 'file2' will be the first file in the list and 'zfile1' will be the last.

Desired behaviour: cursor should be focused on 'zfile1'

[gotar]

Such behaviour would be really annoying when renaming multiple files - each time one would have to move to previous position. I'd vote for keeping current status.

[andrew_b]

Replying to gotar:

Such behaviour would be really annoying when renaming multiple files - each time one would have to move to previous position. I'd vote for keeping current status.

I agree. I prefer the current behaviour too. But if the requested behaviour will be implemented then it must be optionized.

[realstudent]

Hello.
Yes, behaviour in topic desc very irritate, please somebody extend behaviour in optionized style.
Thanks.

[igorp1024]

Ok, then we have inconsistency in UI in similar operations:

1. in case we create the directory the cursor jumps on it
2. in case we rename file/directory cursor stays where it was

Either after creating the directory cursor should stay where it is, or it should jump to the renamed file after renaming.

[igorp1024]

Replying to gotar:

Such behaviour would be really annoying when renaming multiple files - each time one would have to move to previous position. I'd vote for keeping current status.

Multiple files can be handled in different way. In this case the cursor can stay on it's original position.
I speak about single file renaming.

[gotar]

Replying to igorp1024:

Multiple files can be handled in different way. In this case the cursor can stay on it's original position.
I speak about single file renaming.

And how are you going to recognize if I want to rename single file or many files in a row? AI?

[gotar]

Replying to igorp1024:

Ok, then we have inconsistency in UI in similar operations:

1. in case we create the directory the cursor jumps on it
2. in case we rename file/directory cursor stays where it was

What's the similarity between create and rename? These actions have nothing in common. Hint: rename is NOTHING like delete-create.

Either after creating the directory cursor should stay where it is, or it should jump to the renamed file after renaming.

Well, or maybe always jump to random file, that would be consistent.

[igorp1024]

Replying to gotar:

Replying to igorp1024:

Ok, then we have inconsistency in UI in similar operations:

1. in case we create the directory the cursor jumps on it
2. in case we rename file/directory cursor stays where it was

What's the similarity between create and rename? These actions have nothing in common. Hint: rename is NOTHING like delete-create.

Hint: I spoke about UI. Not about operations. So, please be attentive before flaming/trolling.

Either after creating the directory cursor should stay where it is, or it should jump to the renamed file after renaming.

Well, or maybe always jump to random file, that would be consistent.

Stop flaming/trolling.

[igorp1024]

Ok, gotar, maybe I was a bit rude. I'm sorry.
One more proposal: mc can learn a lot from it's elder brothers (other filemanagers). The went a huge way of UI improvement.

[gotar]

Replying to igorp1024:

One more proposal: mc can learn a lot from it's elder brothers (other filemanagers). The went a huge way of UI improvement.

Well, first of all mc is not as young, I'd say it is the elder brother of others. And for the UI: others gone to graphic mode, while mc remains text-only. The main difference is expectation of input device one will use, i.e. some pointing (mouse, tablet, touchscreen) vs plain keyboard. While moving cursor around with pointing device causes no problem and so the distance can be sacrified on the altair of Other Comfortable Things, using keyboard to jump 40 lines (possibly over network etc.) could be painful.

But let's analyze some cases:

1. creating directory

if one creates a directory he wants either to simply have it (doesn't matter where cursor ends) or move something there. In the latter case items can be moved from the other panel (so newly created dir should be easily accessible) or should be tagged before mkdir and after this it's enough to open the new dir in other panel (easy to do with alt-o).

So - this is brand new item we either want to do something on, or don't care.

2. renaming sth

here we want to alter existing file. I see to reason to assume one wants to do more things after (especially - why not before?). So why change positioning that was worked out?

And if one do have a need to quickly find renamed files just change sorting order to ctime.

[igorp1024]

Replying to gotar:

Replying to igorp1024:

One more proposal: mc can learn a lot from it's elder brothers (other filemanagers). The went a huge way of UI improvement.

Well, first of all mc is not as young, I'd say it is the elder brother of others.

I mean that mc was dead for years. And begun to evolve several months ago when people from mc.redhat-club.org shake up the community and project owner.
Let's say: it should learn from matured file-managers (not elder from the lifetime point of view).

And for the UI: others gone to graphic mode, while mc remains text-only. The main difference is expectation of input device one will use, i.e. some pointing (mouse, tablet, touchscreen) vs plain keyboard. While moving cursor around with pointing device causes no problem and so the distance can be sacrified on the altair of Other Comfortable Things, using keyboard to jump 40 lines (possibly over network etc.) could be painful.

I didn't speak about graphics mode. I completely agree that all functions should be accessible from keyboard. When I speak about usability I mean convenience of use, but not using the mouse. mc should have console-based UI as now.
Concerning networking access. Yes I agree. It can be a problem in case of rereading directory list over slow ssh connection. But time goes on and we have wide bandwidth access. And mc is used on the desktop. On slow connections it's easier to get rid of mc and use plain shell (and mass renaming performed by shell one-liner script). So I think it's not an excuse for the mc.

But let's analyze some cases:

1. creating directory

if one creates a directory he wants either to simply have it (doesn't matter where cursor ends) or move something there. In the latter case items can be moved from the other panel (so newly created dir should be easily accessible) or should be tagged before mkdir and after this it's enough to open the new dir in other panel (easy to do with alt-o).

So - this is brand new item we either want to do something on, or don't care.

Sure, cursor jumps on new item.

2. renaming sth

here we want to alter existing file. I see to reason to assume one wants to do more things after (especially - why not before?). So why change positioning that was worked out?

Because it the same file that was before. It just now has a different name. Nothing else. For example, gnome-commander(linux), krusader(linux) and far manager(win/console-based) after file renaming put cursor on new file name (unlike mc at the moment). I can't test other DOS console-based file managers (Norton Commander and Volkov Commander), but AFAIR Volkov also did the same as before-mentioned managers.
Also seeing the file with a new name can help you quickly to check whether there was any typos made in the new file name or not. If we have a lot of files we can easily lost the new file with accidentally made typo in first letter of the name (for example it's possible to hit two keys and press enter when editing first letter of the file name).

And if one do have a need to quickly find renamed files just change sorting order to ctime.

This requires extra actions from user. Usability requires to make user actions as less as possible. I don't speak about possibilities of finding files. I speak about usability.
I would say that it is possible to leave cursor where it is by using command-line equivalents like mkdir and mv.

To sum up my personal opinion.

1. UI of mc stopped in development long time ago. It's mature brothers has more convenient UI (I do not consider graphical UI as more convenient, I speak about usability - ease of use of UI)
2. To put cursor on the new file name is more natural for human (NEW BEHAVIOUR).
3. I agree that somebody will found more convenient current mc's behaviour but they just used to it. So it's good idea to make NEW BEHAVIOUR optionized and switched ON by default.

So if you want to argue, please keep in mind that I started this ticket because of glitches in mc's UI usability. Not because of impossibility to perform operations in it.

[andrew_b]

Replying to igorp1024:

3. I agree that somebody will found more convenient current mc's behaviour but they just used to it. So it's good idea to make NEW BEHAVIOUR optionized

Shure. If this new behaviour will be implemented, it will be optionized.

and switched ON by default.

Definitely, no. OFF by default. I guess there will be many requests to restore the old behaviour. People do not like to change their habits.

[igorp1024]

Replying to andrew_b:

and switched ON by default.

Definitely, no. OFF by default. I guess there will be many requests to restore the old behaviour. People do not like to change their habits.

That's pity. This means that mc will stay a tool for geeky admins and not user-friendly. :( But I understand that people got rid of their habits with pain.

BTW, Alt-O keyboard shortcut behaviour DID change! :) It was remapped to Alt-I. :)
Was there many requests to switch it back? I think if we make it switched on by default it will have not so killing consequences.

p.s. It would be great idea to get usability specialists in mc development team.

[igorp1024]

I think if we make it switched on by default it will have not so killing consequences.

I mean the NEW BEHAVIOUR...

[ossi]

actually, the "new" alt-o behavior is the old one - the one you know as "old" was a temporary glitch, so it was moved to alt-i.

anyway, i find the habit argument somewhat irrelevant in this case. it would adversely affect only people who blindly start doing something with the next file after doing the rename, which is probably not too many.

i'd argue that moving to the new name is much more commonly useful than staying on the next one. in fact, the only case i can imagine where the latter is useful at all is renaming a series of files independently, but in this case it would be wiser to move the already renamed files to a new directory in the same go (which would also automatically force the old behavior of staying on the next file).

regarding adding an option for that, i think it's a bit stupid.

[igorp1024]

Replying to ossi:

actually, the "new" alt-o behavior is the old one - the one you know as "old" was a temporary glitch, so it was moved to alt-i.
anyway, i find the habit argument somewhat irrelevant in this case.

It was just an example of such "user-affecting feature" which was introduced despite somebody can find it inconvenient. I agree that we should not tend to habits but to sense.

i'd argue that moving to the new name is much more commonly useful than staying on the next one. in fact, the only case i can imagine where the latter is useful at all is renaming a series of files independently, but in this case it would be wiser to move the already renamed files to a new directory in the same go (which would also automatically force the old behavior of staying on the next file)

Sorry, didn't get your point. Are you pro or against new behaviour?

[gotar]

Replying to igorp1024:

That's pity. This means that mc will stay a tool for geeky admins and not user-friendly. :(

Average users don't use mc or any other terminal app - unless they're forced to. Text tools are used only by power users since 10 yrs.

BTW, Alt-O keyboard shortcut behaviour DID change! :) It was remapped to Alt-I. :)

It was not. This change was so invasive that we had reverted it in PLD. Then it was reverted in mc itself and the NEW function got it's own keybinding (alt-i).

Was there many requests to switch it back? I think if we make it switched on by default it will have not so killing consequences.

Yep, it will be reverted by distro maintainers and cause nothing but chaos.

p.s. It would be great idea to get usability specialists in mc development team.

Yeah, and some of them should take care of vim! ;)

[gotar]

Replying to ossi:

anyway, i find the habit argument somewhat irrelevant in this case. it would adversely affect only people who blindly start doing something with the next file after doing the rename, which is probably not too many.

So don't think about files, but consider entire panel view. I don't want it jumping from from beginning to the end and back after every rename. It's not window application with SCROLLBAR and tiles so one could easily make out with the new position.

[igorp1024]

p.s. It would be great idea to get usability specialists in mc development team.

Yeah, and some of them should take care of vim! ;)

Yes. :) VIM is horrible.
p.s. I use VIM. It's powerful, but usability is not on it's side :)

[igorp1024]

So don't think about files, but consider entire panel view. I don't want it jumping from from beginning to the end and back after every rename.

Have you ever used Far Manager or Volkov Commander? They are console-based file managers (from windows/dos platforms). They do renaming in the way I'm advocating. So, it's not a feature of graphic-based file managers.
If you need to rename multiple files and want the cursor stay in it's position you can use bash oneliner. It's not rocket science for people who are clever enough to use mc.

The problem with current behaviour is that user cannot see the file with a new name and can't check whether it has correct name or has some typos in it. And more: where is the file? Is it here or it is gone due to unknown reasons? Clever and attentive people will always figure out. But UI should not enforce user to made redundant efforts. It's against usability.

It's not window application with SCROLLBAR and tiles so one could easily make out with the new position.

So, you are against.

[gotar]

Replying to igorp1024:

Have you ever used Far Manager or Volkov Commander? They are console-based file managers (from windows/dos platforms).

I've had a very short period with VC AFAIR ca. 15 years ago. Since 11 years I don't have any OS other than Linux and don't use filemenagers other than mc.

The problem with current behaviour is that user cannot see the file with a new name and can't check whether it has correct name or has some typos in it.

Well, apparently I don't do typos then:)

And more: where is the file? Is it here or it is gone due to unknown reasons?

For me it's always where it should be after rename. I don't really care to exactly spot this. Maybe we should think WHY people do rename files?

I think we're missing some important issue here: rename == move. When I 'rename' file to a directory it's simply moved there (no way to move selection along) - of course selection could be moved to destination directory, but in case of directory rename we still don't get information either it was renamed or moved to already existing dir. The same applies when I 'F6' file to the other panel. So there are already 3 exceptions to be made in order to handle the NEW behaviour (first one was renaming multiple files).

So, your version needs distinction between rename and move and doesn't clarify what to do if they're both the case (mv file /some/directory/new/name). One more analogy to the graphical managers: rename there is simply rename, drag'n'drop is move.

I think it's not usability but confusing. Yes, I'm against.

[igorp1024]

Replying to gotar:

The problem with current behaviour is that user cannot see the file with a new name and can't check whether it has correct name or has some typos in it.

Well, apparently I don't do typos then:)

Sorry, I speak about usability (i.e., what is easier to understand and convenient to use for GENERIC human). It's not a topic about things that I/somebody like/dislike and I/somebody got/didn't get used to.
Ok, if it seems like I'm speaking about my personal habits and perceptions then let it be so. Maybe you're right. But as for me I think I'm defending habits of GENERIC human. Not mine.

====

Ok, let's finish this discussion. I think we figured out that the feature should turned off by default. The only sane and convincing argument is that there are a lot of people who just got used to existing state of UI and distro maintainers can revert this requested feature and it will produce a real hell.