Classic/modern behaviour selector at conspicuous place

[sergey-feo]

(excuse me for my bad english)

At this time mc has default behaviour that differs from modern in many cases. For example this things is absolutely unexpected for new users:

• double esc;
• ctrl-a, ctrl-c, ctrl-v, ctrl-x do not work in editor;
• F7 in place of ctrl-f in editor;
• persistent blocks enabled.

I suggest make some selector classic/modern behaviour at conspicuous place. For example, we can add "load classic settings" and "load modern settings" after "save setup" in "options" drop-down menu.
"load classic settings" will be for behaviour like mc-4.6. "load modern settings" will be for behaviour that expected by most users at current time.
"save setup" then should be "save settings as...".

This will be good compromise between saving defaults as its was in mc-4.6 and users expectations (imho).

[sergey-feo]

P.S. "load modern settings" will load all settings: key bindings, skin, single-esc option and all other options.

[gotar]

Replying to sergey-feo:

• double esc;

Options->Configuration->Esc key mode: Single press (master branch).

• ctrl-a, ctrl-c, ctrl-v, ctrl-x do not work in editor;
• F7 in place of ctrl-f in editor;

These should be easily definable in mc.keymap.

• persistent blocks enabled.

I don't know what this is.

I suggest make some selector classic/modern behaviour at conspicuous place. For example, we can add "load classic settings" and "load modern settings" after "save setup" in "options" drop-down menu.

It'd be nothing but cluttering interface IMHO. If these key combinations are unused they might be as well added to default configuration (with some exceptions like ctrl-c or ctrl-z) since mc supports multiple bindings. It could be even merged with mc.keymap.emacs as nothing overlaps.

[sergey-feo]

Of course many things can be configured. But we speak about this problem: from year to year expected (for new users) look-and-feel is more and more far from classic mc's look-and-feel. Users expect one behaviour and mc gives another. It was decision do not change default mc's behaviour as far as I know. So, mc will always give unexpected (for new users) behaviour by default. Now mc can be configured to modern behaviour in most parts. But the fact that user must learn many configuration aspects of mc to make mc "just work in normal way" is annoying for new users. Many potential users of mc do not use it because of this fact. It is not my imho, i know this :-) You are not know about persistent blocks, somebody do not know about keybindings (this feature has no user interface and afaik undocumented), somebody about skins, etc.
So, mc should be as much nearly to modern look-and-feel as possible but should not break classic mc's look-and-feel - in one time! Some parts of this problem can be solved with multiple keybindings. I am not insist that groups of settings ("classic" group and "modern" group) is the best solution. But problem should be solved - with this solution or with some other solution.

P.S. Persistent blocks is "постоянные блоки" in russian translation (editor's option). When some text selected and persistent blocks is on (mc's default, emacs'es default), inserting symbol does not delete selected text. When some text selected and persistent blocks is off, inserting symbol deletes selected text. This is not default for mc but this is default for notepad, kwrite, word, edit field in firefox.

[zaytsev]

Many potential users of mc do not use it because of this fact.
It is not my imho, i know this :-)

Oh really? What are your statistics? How many thousands of new users have you polled?

[gotar]

Replying to sergey-feo:

from year to year expected (for new users) look-and-feel is more and more far from classic mc's look-and-feel. Users expect one behaviour and mc gives another.

If you talk about users not familiar with text terminal, they simply shouldn't use terminal applications. Shortcuts I've been referring to (ctrl-c, ctrl-v) are parts of GUI, do you know ANY TUI application making use of ctrl-c? ;) It's been 'break' since DOS.
PS: shift-delete, shift-insert and ctrl-insert equal ctrl-x, ctrl-v, ctrl-c in GTK.

But the fact that user must learn many configuration aspects of mc to make mc "just work in normal way" is annoying for new users. Many potential users of mc do not use it because of this fact. It is not my imho, i know this :-)

Really, are there any clicking-users willing to use mcedit instead some GUI editor? Are they aware that EVERY text mode application requires double-esc (or other hacks - I personally use .Xresources to rebind xterm's escape)?

Seriously, here in Poland we've got this saying: if you want to hit the dog, you'll find a stick. I doubt any GUI-user would use TUI application, unless it's made so GUIsh, that it became some gnome commander.

You are not know about persistent blocks

No, I just don't know designatum of these words.

, somebody do not know about keybindings (this feature has no user interface and afaik undocumented), somebody about skins, etc.

Well, half of the most powerful mc options isn't available via configuration dialogs. That's one of the reasons it's not for everybody.

P.S. Persistent blocks is "постоянные блоки" in russian translation (editor's option).

Does everyone here comes from Central-East Europe?:)

When some text selected and persistent blocks is on (mc's default, emacs'es default), inserting symbol does not delete selected text. When some text selected and persistent blocks is off, inserting symbol deletes selected text. This is not default for mc but this is default for notepad, kwrite, word, edit field in firefox.

Great you've mentioned emacs - that's TUI. Just like vim and plenty others. The main difference is that TUI is designed to work efficiently with keyboard only, while GUI without mouse is terrible. This is for different kinds of people.

[zaytsev]

Actually, I think we should first remove this stupid command mode from vi and finally introduce the long-awaited traditional shortcuts, that new users are familiar with, e.g. ctrl+c / ctrl+v etc.

[andrew_b]

Actually, new Linux users are GUI users, they come to Linux from Windows or Mac. They don't like and don't want read docs.

In general, at the current time MC is used by old Linux/Unix? users or IT geeks. Yes, MC now is tool for geeks. :) I believe that MC users are able to tune MC for their wishes.

If you think that some MC features are documented badly or undocumented at all, MC development team would welcome any help to improve the MC documentation.

So, I'd close this ticket as wontfix.

[gotar]

Replying to sergey-feo:

P.S. Persistent blocks is "постоянные блоки" in russian translation (editor's option). When some text selected and persistent blocks is on (mc's default, emacs'es default), inserting symbol does not delete selected text. When some text selected and persistent blocks is off, inserting symbol deletes selected text. This is not default for mc but this is default for notepad, kwrite, word, edit field in firefox.

I've found this as recent feature introduced in #2155 - indeed it may be hard to find which option toggles this (or even if it's possible at all), especially without help - pressing F1 in Editor options returns 'Cannot find node [Editor options] in help file'. So it's a matter of missing documentation and maybe some beginner's tutorial for now.

Eventually, alternate config files can be shipped (ini, keymap - just like skins) and selected via #2165.

[zaytsev]

Actually, this feature is now in and on by default if persistent blocks are turned off. So this point is invalid.

I don't know, maybe allowing for making bundles, such as "ini + keymap + skin" is not such a bad idea, then a bundle can be selected from the options and all the parameters would be changed accordingly...

[gotar]

Replying to zaytsev:

Actually, this feature is now in and on by default if persistent blocks are turned off.

But persistent selection in ON by default (and undocumented).

[zaytsev]

Persistent blocks are on by default since day zero, they have been there forever and they are documented in man mcedit (and can be switched off in editor options, whereas the checkbox name is self-explanatory).

It's true that maybe man2hlp conversion for mcedit might not be working completely right, but it's a different ticket.

[andrew_b]

Replying to gotar:

pressing F1 in Editor options returns 'Cannot find node [Editor options] in help file'. So it's a matter of missing documentation and maybe some beginner's tutorial for now.

Yes, mceditor help is almost empty (#1561).

[gotar]

Replying to zaytsev:

Persistent blocks are on by default since day zero, they have been there forever

Yes, I know. In fact I've never disabled them. I even didn't know what that is.

and they are documented in man mcedit

Isn't this ticket about people not reading man pages?:)

Anyway, manpage says "Do not remove BLOCK selection after moving the cursor" - capitalized word should be removed.

(and can be switched off in editor options, whereas the checkbox name is self-explanatory).

Well, it's not self-explanatory - after some googling of this term I've found ​http://docs.kde.org/stable/en/kdesdk/kate/kate-part-selection.html and tickets #316, #1489 only, that seems relevant. My point is, this is more subtle tune that is hardly having common, well-known and recognized name, so it will be hard to switch by anyone used to contemporary regular editors. My previous point was that such people won't use mcedit anyway:) which makes this part of discussion purely academic.

[zaytsev]

My point was that OPs point is irrelevant, I had nothing to say about your input :)

My only conclusion from this discussion is that it might make sense to consider bundles, but apart from me, it seems, nobody supports this idea.

[sergey-feo]

I feel a summary opinion for this ticket is "we are geeks and mc's behaviour is ok for us and so it is ok for other geeks. Any other users should use their GUIs and should not use mc".

So I will try to rotate problem and see it from other side. Other side is time. I think that mc's current behaviour is not very comfortable for users. So user - geek or not - should change this behaviour to one that is comfortable for him. For most users - geeks and not geeks - most comfortable behaviour will be DOS/Windows-like (imho!). Procedure of reconfiguring mc can get many time. Some users is ready to spend time for reconfiguring programs, some users are not ready.
Time is the most valuable recource that any man has because we live only one time and this time is limited.

I suggest to do something to reduce time cost of reconfiguring mc to DOS/Windows-like (useful by most users) behaviour.

[sergey-feo]

P.S. To gotar:

PS: shift-delete, shift-insert and ctrl-insert equal ctrl-x, ctrl-v, ctrl-c in GTK.

This key combinations is not work in mc on most popular terminals.

[andrew_b]

Replying to sergey-feo:

For most users - geeks and not geeks - most comfortable behaviour will be DOS/Windows-like (imho!).

inho is not an agrument. My imho has the same cost as yours.

[sergey-feo]

My mistake was using "windows" word :-)

Lyrical Digression.
Please imagine the world of programs that all have different behaviour.
No de-facto standarts like "ctrl-c ctrl-v". This world's OpenOffice? uses <ctrl-x a> for copy and <ctrl-x s> for paste. Firefox uses shift+f6 and alt+f6 for this tasks. Bash uses ctrl-z and ctrl-/.
Emacs of this world does not use arrows keys. Nautilus requires triple Esq, Dolphin single, Konqueror double F10 for cancelling operation. Mouse processing is also absolutely different in this world: you will click hyperlinks in Firefox by right button and open context menu with middle button. In Opera you will click hyperlinks with double left button and open contex menu with triple left button. Menu "File Edit View..." will be different also. You will have unique menu in each program. Scrollbars of most programs works like xman's one.
Each program of this world can be reconfigured. Some programs have good GUI that allow fast reconfiguring. Some other programs have only config files without GUI. Some programs have mixed GUI and non-GUI configuration system. Some other programs have many config files with strange syntax at strange places.
User must spend a lot of time to read many docs and reconfigure all software that he/she using or user must use uncomfortable (and so time-eating) software environment.

It is bad that mc will be program of this imaginary terrible world.

[gotar]

Replying to sergey-feo:

PS: shift-delete, shift-insert and ctrl-insert equal ctrl-x, ctrl-v, ctrl-c in GTK.

This key combinations is not work in mc on most popular terminals.

All of them work in xterm. And you CAN NOT use ctrl-c anywhere, just forget it. As ctrl-a and ctrl-f are already used by EditExecuteMacro and EditSaveBlock there's not much sense in binding ctrl-v to EditXPaste, because one has to reconfigure or learn remaining anyway. And DOS/Windows behaviour usually sux.

[sergey-feo]

Replying to gotar:

PS: shift-delete, shift-insert and ctrl-insert equal ctrl-x, ctrl-v, ctrl-c in GTK.

This key combinations is not work in mc on most popular terminals.

All of them work in xterm.

There many other more popular terminal exists that do not support this functionality in mc: ​http://www.linux.org.ru/polls/polls/5191157

And you CAN NOT use ctrl-c anywhere, just forget it.

Why not? Because of soft with too old behaviour? It should be changed :-)

As ctrl-a and ctrl-f are already used by EditExecuteMacro and EditSaveBlock there's not much sense in binding ctrl-v to EditXPaste, because one has to reconfigure or learn remaining anyway.

This ticket is exactly solution of this problem. User should be able switch all settings to modern by one mouse click (or two) and so EditExecuteMacro and EditSaveBlock will be remapped to other keys, not ctrl-a and ctrl-f.

And DOS/Windows behaviour usually sux.

DOS/Windows behaviour is most based on IBM CUA (​http://en.wikipedia.org/wiki/Common_User_Access), Apple HIGs and Microsoft's initiatives. DOS/Windows behaviour is result of great work of unifying programs look-and-feel, making them easier to use and lesser time consumption. Both KDE and GNOME copy DOS/Windows behaviour in most parts.

[gotar]

Replying to sergey-feo:

There many other more popular terminal exists that do not support this functionality in mc: ​http://www.linux.org.ru/polls/polls/5191157

So report the problem in their bug trackers.

And you CAN NOT use ctrl-c anywhere, just forget it.

Why not? Because of soft with too old behaviour?

Because ctrl-c sends INT signal just like ctrl-z ('undo') STOP and ctrl-\ QUIT.

It should be changed :-)

Maybe it's you who should change operating system if you can't adapt to the standard?

This ticket is exactly solution of this problem. User should be able switch all settings to modern by one mouse click (or two)

User not willing to configure his environment won't bother to do even this one click.

And DOS/Windows behaviour usually sux.

DOS/Windows behaviour is most based on IBM CUA (​http://en.wikipedia.org/wiki/Common_User_Access), Apple HIGs and Microsoft's initiatives.

Nice - I see there shift+del, ctrl+ins and shift+ins not ctrl-x, ctrl-c and ctrl-v.

DOS/Windows behaviour is result of great work of unifying programs look-and-feel, making them easier to use and lesser time consumption.

So mc is DOS-compatible. Windows doesn't follow CUA, you must report this in MS bugtracker.

Both KDE and GNOME copy DOS/Windows behaviour in most parts.

That's why I don't use any of them.

BTW most of GNOME configuration options are available only via gconf. The most powerful KDE options are available only via files. Most Windows options are tunable only by register.

[sergey-feo]

Replying to gotar:

There many other more popular terminal exists that do not support this functionality in mc: ​http://www.linux.org.ru/polls/polls/5191157

So report the problem in their bug trackers.

Already done:
​https://bugs.kde.org/show_bug.cgi?id=59256 - 7 years ago;
​http://bugzilla.xfce.org/show_bug.cgi?id=5937 - 1 year ago;
​http://sourceforge.net/tracker/?func=detail&aid=2890032&group_id=124080&atid=698428 - 1 year ago
​https://bugzilla.gnome.org/show_bug.cgi?id=310305 - 5 years ago

And you CAN NOT use ctrl-c anywhere, just forget it.

Why not? Because of soft with too old behaviour?

Because ctrl-c sends INT signal just like ctrl-z ('undo') STOP and ctrl-\ QUIT.

I think it is not the problem to use ctrl-c for copy to clipboard instead of receiving INT signal: mc already uses ctrl-\ for "quick access dirs" instead of receiving QUIT signal. So why not use ctrl-c for something instead of receiving signal?
It is conflict of de-facto standarts: ctrl-c is for INT signal in CLIs and for copying in Windows graphical applications. Perhabs we need a new FreeDesktop?'s HIG that solves such problems but will not conflict in most parts with Unix traditions, IBM CUA, Apple's HIG and MS traditions.

User not willing to configure his environment won't bother to do even this one click.

There are different users exists :-)

BTW most of GNOME configuration options are available only via gconf. The most powerful KDE options are available only via files. Most Windows options are tunable only by register.

Most options available througth gconf/files/registry but most useful options available througth GUIs.

At the begin of discussion I suggest a solution for fast switching to modern behaviour: groups of configs (keyboard + other). I see that people don't like this solution. So I suggest another solution: make additional archive with alternative configs that can be downloaded or not downloaded with mc. I believe that other solutions are possible.