Re: ALT ('-') and ALT('+')

[Pavel Roskin <proski gnu org>]

Hello!

> Is it reasonable to make ALT('=') do Select All as well? I use it all
> the time and that triple bucky gets a bit... bothersome.

The code for the file selection keys is messy and needs a serious cleanup.  
Adding new key combination to compensate for brokeness of the existing
code is hardly reasonable.  Additional complexity will be an additional
obstacle for those who will clean up this code.  People learn keys, and
then you can reassign those keys to something better.

There are several things you can do to make it more convenient for now.  
You can use a terminal that has separate escape sequences for the keypad.  
You can use only_leading_plus_minus.  You can even use "Learn keys" to
assign your favorite combinations.

Have you tried "Learn keys" for that?  If yes, why didn't you like this
approach?  I think that the "Learn keys" dialog has two problems - one is
that users cannot find it when they need it.  The other is that they don't
realize that it can help them.

The answer (hard, but still not ideal) would be to implement remappable
keys and a to write a much more complex dialog to assign keys to actions
(as opposed to matching physical keystrokes with escape sequences).  This
would also mean stripping hardcoded keys from the menus, breaking all
translations.  It was discussed many times, but nothing was done.

I think it can be said about the current state of the project that most of
the simple patches have been applied.  The remaining stuff is mostly hard
and involves redesign.  The unfortunate thing is that very few people
actually want to do the hard stuff.  Most contibutors simply try to
"overstretch" old bad design.  Remember e.g. chaining video players with
the "||" operator, which was an obvious (and wrong) extension of the same
idea for the Word doc viewers.

> I see that those functions avoid the directories. It's a paltry matter
> to comment out the lines in cmd.c that check for dirs, but there must be
> a reason someone did that to begin with.

At least two reasons.

One is that the new dialogs are harder to code than to use input_dialog()  
or other ready dialog.  Just a little details - when XView was supported,
all the dialog had to be created backwards, i.e. starting with the widgets
that are last in the Tab order.  Even the title of the dialog had to be
drawn manually until recently.  Most importantly - the dialog API is
undocumented.

The other reason is that the selection for directories is in fact
supported.  Just add slash at the end of the pattern.  Usability of this
feature was obviously neglected, so that not only most users are unaware
of it, but even the developers trying to improve this code!

I cannot apply your patch for two reasons:

1) It makes it harder to select only files if I want to.

2) It replaces one random choice with another one instead of giving the
user the choice (and giving the choice to the user means a checkbox with
an obvious name, not an extra paragraph in the manual).

> that way you can select all, then reverse the selection to get the
> directories all selected? Two keystrokes.

Don't you realize that this inconsistency (invert affects directories, 
select doesn't) is just another bug?  It's not right, it's just tolerated 
by users, unlike files on ftp beginning with "2000 " :-)

> Usually the subdirs are a minor component of a directory structure, and
> it's the files you want to work on, usually.

Let the user decide.  I'll appreciate if you check popular non-free file
managers (Far, Norton Commander, Windows Commander) and make the behaviour
consistent with at least with one of them if possible.  At least some
users won't have to learn news keys when they start using mc.

> Also, the unselect-all SHOULD do directories, shouldn't it.  That's what
> it's for, to unselect everything, isn't it?  Right now it won't touch
> selected directories.  Isn't that wrong? If it's not wrong, could
> someone please explain why?

Maybe because something (just like like you) didn't like writing new 
dialogs?

-- 
Regards,
Pavel Roskin