[svlug] About mc

J C Lawrence claw at kanga.nu
Sun Jan 20 16:44:02 PST 2002


On Sat, 19 Jan 2002 23:58:50 -0800 
Erik Steffl <steffl at bigfoot.com> wrote:
> J C Lawrence wrote:
>> On Sat, 19 Jan 2002 02:57:42 -0800 Erik Steffl
>> <steffl at bigfoot.com> wrote: 

>> I have use for a file manager no more than once or twice a month.
>> I'm not going to learn the keys, and if I do I'm unlikely to

> in mc they are right in front of you. you don't have to learn
> anything.

I find myself having to read the function key labels near every
time.  I'd rather not, especially as they're abbreviated.

>> remember them.  That's the primary reason I explicitly don't want
>> function key based bindings and do want letter based bindings.

> just wonder how you remember whether r is for remove or for
> rename:-) mnemonics are easier to remember but you still have to
> remember them.

That's why I prefer them to be configurable so I can change them to
my default pattern.

>> As an aside I have a particular dislike of function keys in the
>> general case, and with the exception of (rare) VT switching or
>> window size controls, just never use them.

> you can also use esc-n where n is a number...

Hardly better and far slower (especially as I don't generally use
ESC for anything else).

>>> It is kinda arrogant from a program to not let you assign any
>>> keybindings but IMO it's not serious usability problem.

>> I generally consider it critical.

> do you remap all the keybindings in vi? in emacs? in other
> programs?

I've rebound much of the keyboard in XEmacs, and yes, I do similarly
in other tools as well.  A computer is a tool -- it adapts to and
serves its user, not the other way 'round.

>>>> aren't you using command line?
 
>>>From bash, yes, from the file tool, no.

> it's not really from, it's more like parallel to file tool (the
> way it works with mc). why not having BOTH file manager and
> command line available? 

Because for 28 days out of the month I've no use for it, on those
two remaining days it only needs a couple minutes.

> it doesn't limit you in any way and it's simpler than ctrl-z
> etc. (nothing prevents you from using ctrl-z though).

Except that Ctrl-Z works everywhere, with everything.

> ? you work in ONE directory for any extended period of time? 

Yup. One directory, or a small set of directories ala:

  .../dir/src
  .../dir/include
  .../dir/lib
  .../dir/etc

so I'll sit in .../dir for days/weeks at a time.

> that's kinda strange. 

Depends on what you're doing.

> generally traversing the directory trees is easier using file
> manager (less keystrokes, you see what's happening) 

TAB completion is your friend.  ido.el under (X)Emacs make it
especially attractive (it really is most amazingly sweet).

>>> on modern desktop machines there is no excuse for programs not
>>> to have context sensitive help.

>> Which I rarely to never use.  Not worried.  Not interested.  I'm
>> not a fan or much of a user of "modern desktop" design.

> not modern destop design, modern desktop machines: there are no
> space (HD or RAM) constraints that would excuse lack of readily
> available on-line doc (man page, context sensitive help etc.). how
> else would you learn how to use a program?

A man page is not context sensitive help.  However it, and perhaps a
README, is enough for the majority of cases.  For the rest throwing
something under /usr/share/doc handles most other cases.

>> SELECT <file-spec> <command>
>> 
>> Brought up a scrolling text list of the matching files which
>> could be cursored among and tagged/untagged with SPACE.  Hitting
>> ENTER ran the provided command on all tagged entries.
>> 
>> That alone under bash would remove 90% of my need/wish for a file
>> manager (I faintly understand you can do something not entirely
>> dissimilar under zsh, but I haven't looked into that yet).

> it's not exactly the same but that kind of functionality is
> covered by command line auto-completion, 

Aye, that's a standard (and heavily used) feature here.  it doesn't
do much however for the "I want to run this command on some
arbitrary selection of those files" case.

>>> but how do you work with compressed/tar-ed files?
 
>> I unpack them.  Not a problem.  It is relatively rare that I work
>> with tar.gz files that I don't want them unpacked.

> but you just use too many keystrokes and too much attention to
> do it - you have to know how to uncompress it (gz, bz, rar etc.),
> you have to check it first whether tar creates it's own single
> directory etc. it's quite uncomfortable...

Hardly.  I very rarely deal with anything but tar.gz, but for the
unusual cases where I get .tar.bz files I've a little script whapped
up that will auto-detect and unpack either .tar.gz or .tar.bz
without my needing the check.

>> interface.  Conversely I'm starting from the view that a file
>> manager is something I only use when the command line is
>> inconvenient for some particular problem, and thus only use a
>> couple times a month.

> but I spend more time in file manager than that...

Err, to repeat the point, I don't.  File management is perhaps less
than 3% of my time, if that.

>> LIST (which I last used ~8 years ago under DOS and OS/2) does
>> what I actually want.

> I don't get it. What is it that LIST does that mc does not? 

Faster, smaller, lighter, more unobtrustive, easier/more-intuitive
cross-directory operations, default/expected key bindings, less
cruft.  I don't want a swiss army knife.  I just want a small fruit
knife.

> btw I didn't even find any way to configure its key bindings. and
> generally I found it unusable...

Perhaps I'm just used to it (tho I don't know how it is now as it
was years ago that I last used it).

>> mc enforces a UI which I find nearly unusable and supports a raft
>> of features that I find distracting from what I'm

>  ? every UI program enforces its UI. every CLI program enforces
> its UI as well. LIST does. not sure why you are singling mc out.

Because I don't like mc's choices?

> the extra features: you don't have to use them. mc presents you
> with two (or one) panels with lists of files that you can fairly
> easily perform basic file operations upon (if you don't remember
> keys just look at the status line). you don't even have to know
> about any other fancy features. how is something that you never
> see on the screen distracting you?

Silly examples: The may MC handles cross-directory operations is the
exact opposite of what I prefer.  mc requires the other pane to be
on the target and the current pane to be the source.  Aaaargh!  That
catches me almost every time.  The second confirm/edit/etc step
under mc when doing a tagged file operation is something I've never
wanted (or used) and would really like to never see.  

  ObNote: I'd also much prefer it if mc left me in the directory it
  was viewing when I exited, rather than the directory I started it
  from.

> you can fire it off anytime you want and quit it with single
> keystroke, it's not a monster that would take forever to start up:

Arguably that's little different from list.

> jojda:~>time mc

  $ time mc
  real    0m0.469s
  user    0m0.000s
  sys     0m0.040s

  $ time list
  real    0m0.098s
  user    0m0.070s
  sys     0m0.020s

No promises on not having a slow finger, tho I tried not to.

> you can even run it with command line, it's not some internal
> funky CLI, it's your login shell, basically unchanged, you just
> hit ctrl-o to make panels disappear (but you _don't_ _have_ to use
> this feature, you can just quit mc or use ctrl-z)

I like the bash command line and want it to be my default CLI UI.
Nothing else, just bash as configured by my .bashrc, under an xterm
as configured (and keys re-bound) as per my .Xdefaults.  I like
that and would like to stay with it, augmenting it only in the areas
mentioned, not replacing or changing large chunks of it.

> also: menu bar, command line, status line, hint line can all be
> turned off so you're left with panel(s) only.

I'd rather (almost always) have visible the bottom end of scrollback
(usually the last 20 or 100 lines depending on window size, with a
further 5K lines available under PgUp/PgDn)).  That I find useful
and use dozens of times a day.  The vast majority of the time I
don't have a use for the panes.

> mc is not an integrated solution. 

We disagree.

Stylistically I'd prefer something that handled mail far closer to
the way MH approaches handling mail than the way that any of the
mbox-based tools do.

>> Hurm.  John Crowe's list (OSS) seems a fairly good starting
>> point.  Its got most of the basic supports there already.  I
>> really should take some time off and just hack it into shape.

> he recommends mc as well:-) just checked the web page.

Yeah, I know.

> the more you're explaining the more I find your position strange.
> everything that you write (apart from keybindings configuration)
> points to mc. yet you don't like it. is it something personal?

Nope, just what I've written.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.




More information about the svlug mailing list