[svlug] About mc

[Erik Steffl]

J C Lawrence wrote:
> 
> 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.

  ? most of them are not:

1Help   2Menu   3View   4Edit   5Copy   6RenMov 7Mkdir  8Delete 9PullDn
10Quit 

  the only confusion is menu <-> pullDn (menu is user menu, pull down is
the application menu).

  a little bit more detail about function keys (Fn <-> esc-n):

  mc uses ctrl and meta modifiers, if meta is not available it uses esc
(esc, then key). since the function keys are not as common and generally
it's harder to make them work the meta n (n=1, ..9, 0) double the
function of Fn. So the safest bet is to hit esc-n, that should work in
most situations. I wasn't sure why you dislike function keys - if the
reason was that they are not as widely available (or don't work) then
esc-n would be a good solution.

  as far as speed goes you can also use meta-n instead, that way you do
not have to leave the home row. on debian (i386 arch) the meta seems to
be the window key (at least that's what it is on my system and I don't
remember doing any changes in this area). it's still not as good as
whatever you want it to remap to but it's somewhat better as far as
typing goes.

...
> > 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.

  so use it with mc just like you would with list. it's hardly a fault
of mc that it provides additional functionality (that does not limit you
in any way).

...
> > 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

  yes, but not a (boy)|(girl)friend/spouse, i.e. it's ok to have more
than one friend.

...
> > 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.

  for a gui program there is no excuse not to have context sensitive
help. why should a user have to go someplace else and go through
irrelevant info when program knows exactly where the user is a can
provide relevant help information?

> >> 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.

  mc can be used then, even though the order of operations is slightly
different:

  1: mc
  2a: select files
  2b: type the command
  3: hit ctrl-x t<enter>
  then F10 if you don't want to use mc anymore...

  it has the same effect as you describe, it's a little bit less
effective as far as typing goes (but not much) - it shouldn't matter if
you use it rarely, if you'd use it more often you would probably already
be in mc.

  2a and 2b can be done in any order.

  2a: there are several ways to select files you want to use:

    insert tags/untags files
    + enables you to type in shell patter or regexp (configurable)
    meta-? is a simple version of find+grep
    ctrl-x ! let's you run any program that returns list of files (e.g.
find)

  you do not have to use all the fancy file picking mechanizms, if you
want to stay simple you can use insert and possibly +

  3: you can edit the resulting command line before hitting enter
(unfortunately not using your shell, it gets into shell history though).

  you have to know the ctrl-x t spell though. then again, you have to
know select if you want to use it so it's basically the same (and
there's context sensitive help in mc when you forget the keybinding).

  note that while what I describe is somewhat complicated you can use it
in very simple form, in that case it's basically the same as select. the
additional functionality does not stand in your way...

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

  what I was saying is that I am not all the way on the other side (as
you suggested). In fact if it weren't for mc I would probably use file
managers less than 10% (at least that was the case before I've found mc)
and be quite happy.

...> > 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.


  smaller: yes (but who cares?)

  faster: NO, see the timing of startup/exit below, and there doesn't
seem to be any detectable speed difference during operation.

  more unobtrusive: mc even let's you work in your shell, how can it be
any less obtrusive? you can have nothing but panel on the screen...

  intuitive: list is not intuitive at all, without using the help screen
you wouldn't be able to do almost anything. 'c' does not copy. v is for
NV (arc viewer) [linux version, IIRC it is somewhat better in DOS
version] etc. mc is not anymore intuitive than that but at least it is
easy to get help, it displays basic keys on the screen (if you want it
to) and lot of keys are the same as nc uses (which is/was sort of de
facto standard)

  cross directory ops: linux list doesn't seem to have any. haven't find
a way to copy a file (intuitive???). what I remember from dos version is
that it brings up dialog where you can type in the destination, which is
exactly what mc does. mc provides the oposite panel's directory as
default but you can start typing your own destination right away so it
doesn't slow you down at all, it even provides auto-completion
(meta-tab).

  key bindings: list definitely does NOT provide expected key bindings,
specially the linux version. the dos version - perhaps and if you like
those then that's a valid point against mc. still - you cannot change
them so how is it that you know what to expect when you hit r? is it
remove or rename? intuitive?

  the knife analogy is not a valid one in this case. the extra
functionality of mc does not come at significant cost - the only
difference is that the program is bigger, it does not have almost any
difference on start-up time (that's the only possible difference). the
HD space it takes up is not of concern (today and even less concern in
the future). How is the extra functionality of mc standing in your way?
If you don't know about the extra keybindings you simply don't use them.
What's the problem?

...
> >> 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?

  in one panel configuration it is basically the same as list...

...
> 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

  (sort of repeated from above) no it does not. it just provides it as
default, you can immediately type in your own destination just as if the
default wasn't there. it even provides auto-completion. what more (or
less) do you want? how is list better than 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.

  you get the same dialog in list. how else would you specify the
destination? it does not make any sense. what do you mean?

>   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.

  list or any other program does not do that either. and cannot. that's
why cd is internal shell command (child cannot change the parent process
environment, cwd etc.)

  however, there's a sort of solution for this, here's a relevant quote
from man page:

      -P     At  program  end, the Midnight Commander will print
              the last working directory.  This  function  should
              not  be  used  directly, instead, it should be used
              from a special shell function that  will  automati­
              cally  change the current directory of the shell to
              the last directory the Midnight  Commander  was  in
              (thanks  to Torben Fjerdingstad and Sergey for con­
              tributing this function and the  code  implementing
              this      option).       Source      the      files
              /usr/lib/mc/bin/mc.sh (bash and zsh users)  respec­
              tively /usr/lib/mc/bin/mc.csh (tcsh users) in order
              to have this function defined.


> > 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

jojda:~/skusobna/list>time ./list
0.010u 0.000s 0:00.10 10.0%     0+0k 0+0io 217pf+0w
jojda:~/skusobna/list>time mc

0.020u 0.000s 0:00.10 20.0%     0+0k 0+0io 388pf+0w
jojda:~/skusobna/list>

  I compiled the list (crowe's version for linux) and above are the
results on my machine. I would say that you cannot distinguish between
list and mc (as far as start-up time goes). Not sure how to measure
anything else but from visually judging the speed I don't think there's
any significant difference.

  btw on your computer it says that real time was 0.469s while the sum
of other times was a lot less - that means that there was something else
going on on the system. Or perhaps it was waiting for a disk to load the
file (mc itself, that would mean that you'd have to wait for about .5s
when you start mc first time/after a very long time - that's not such a
big deal).  Since I already ran mc I obviously cannot test the first
start right now...

> 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.

  good. as far as comparison between list and mc goes: mc is basically
the same but provides you with you shell even from within mc (and yes,
it's bash shell (or whatever your login shell is), not some internal
funky shell).

> 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.

  OK. that's what I do as well. whether you augment it using list or
using mc there's no difference in obtrusiveness, I would argue that mc
is less obtrusive because it lets you use you shell even when you run mc
(again, this functionality does not come at a price - if you don't want
it just don't use it, it does not prevent you from using ctrl-z or quite
mc etc.).

> > 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.

  so at those time do not run the file manager or use ctrl-o with mc (or
ctrl-z), that's what I do as well. have an xterm, sometime run mc in it,
depending on what I do. when I want to use command line again (in the
same xterm) I either quit mc or use ctrl-o (depending on what I think I
will be doing).

  ctrl-o has an advantage of keeping the directories of shell and mc in
synch - if you are in mc and change directory the shell's cwd changes as
well, if you hit ctrl-o and cd in shell the mc's cwd changes too (that
wouldn't happen if you used ctrl-z). again: you do not have to use this
feature and it doesn't cost you anything... IMO it makes perfect sense,
specially for people who do significant amount of work using command
line but that's just me - you might not find it useful and you do not
have to use it (or even know about it). it's not forced on you.

> > mc is not an integrated solution.
> 
> We disagree.

  how is mc more integrated solution than list? you can use it in the
same way that you use list (in principle, it's, of course, not exactly
the same).

> 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.

  what is this about? and BTW as far as email goes the best way to store
it is to use IMAP (which IIRC is what you do, or at least advocate).

> >> 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.

  but based on what you've written you want mc! (overall, apart from the
keybindings) I am quite confused - what you're saying about how you work
makes sense (I work in similar way even though not on the same kind of
tasks) but when it comes to mc you're suddenly strange... well, one way
or another, I guess that's it from me, I hope you didn't find it too
pushy... (=unless you want to continue discussion I am not goin to
continue with my mc evangelism).

	erik