mc 4.7.0-pre1 marking directories with -/+/*

[Theodore Kilgore]

On Fri, 14 Aug 2009, Paul Hartman wrote:

> On Fri, Aug 14, 2009 at 2:46 PM, Theodore
> Kilgore<kilgota at banach.math.auburn.edu> wrote:
>>
>>
>> On Fri, 14 Aug 2009, Paul Hartman wrote:
>>
>>> Hi,
>>>
>>> I have used mc for years and can't live without it. :)
>>>
>>> I recently updated to mc 4.7.0-pre1 so I can see what's new and the
>>> first thing I noticed was now directories are marked as part of -/+/*
>>> operations by default. For - and + there is a "Files Only" checkbox,
>>> but I can find no such thing for *. I have three questions:
>>>
>>> 1) Can I make "Files Only" checkbox remember its setting?
>>> 2) Is there a setting to toggle whether * marks dirs?
>>> 3) Or maybe a global "Files Only" to make -/+/* behave like previous MC?
>>>
>>> I also realize it's a -pre1 so maybe the options related to this new
>>> functionality simply don't exist (yet) or are not in the UI.
>>>
>>> I often use the Compare Directories function to compare files in two
>>> directories, which marks the differences. In my case I actually want
>>> to find the duplicates, so I would press * in one panel to invert the
>>> selection and press F8 to delete the duplicate files... now it selects
>>> the duplicates along with every subdirectory (since they were not
>>> marked as part of the compare operation). It's not a big deal but if
>>> there are many subdirectories it can take a while to un-mark them
>>> (since there is no "Directories only" option in -/+ that I can find).
>>>
>>> If you need more info, or if I should create a ticket instead, please
>>> let me know.
>>>
>>> Thanks for the great work!
>>
>> I have not yet tried any pre- version, but I have been running a recent SVN
>> tree version for a while, now. The switch from marking files with
>> Cntrl-Alt-Plus to marking files _and_ directories is something which seems
>> to have come in recently. I have also found this change to be annoying,
>> irritating, inconvenient, and, under some circumstances, positively
>> dangerous (think of someone who wants to delete files and not recursively to
>> delete subdirectories, for example, or who wants to move all files but not
>> recursively to move all subdirectories from an FTP site and discovers that
>> one has initiated a very different course of action and it is too late to
>> stop it!).
>>
>> I think it is natural that one might naturally want to mark files for some
>> purpose, and not sudirectories. Why change a thing like that?
>
> There are certainly times when I would want it to mark subdirectories,
> and it is indeed something I have desired MC to have -- I'd just like
> to be able to decide when it will include dirs and when it won't. I
> like having options. :)

Paul,

What you say has its merits and attractions. But for me that has not been 
a problem. Far more frequently, I need to mark the files and not the 
directories. But when I want to mark the directories, too, there is the 
Insert key. Just start at the top of the tree, in the directory of 
interest, and hold it down. Then it will cause the first directory present 
to be marked and will march downward, marking the rest of them. It is far 
more irritating (and, as I said, sometimes dangerous because a years-old 
and therefore expected and habitual pattern has been broken) to have to 
_remember_ to use the insert key to _unmark_ the directories after the 
Keypad-Plus has marked them, in the eventuality that you only want (for 
example) to delete everything that was just marked.

Perhaps you are right, though and it would be better to have some 
additional key combination which would mark everything in sight. Perhaps, 
Cntrl-Keypad-Plus or Shift-keypad-Plus would be good for that. But to 
change suddenly the behavior of something well established is, in my 
opinion, a thing which is bad in itself. It brings up problems similar to 
the fact that, with my wifes car, one twists the turn signal handle to 
turn on the windshield wiper The corresponding twist of the same handle on 
my car turns the headlights off! I see no need to emulate that kind of 
behavior in software.

Theodore Kilgore