[svlug] About mc

J C Lawrence claw at kanga.nu
Mon Jan 21 00:53:01 PST 2002


On Sun, 20 Jan 2002 23:48:18 -0800 
Erik Steffl <steffl at bigfoot.com> wrote:
> J C Lawrence wrote:

> for a gui program there is no excuse not to have context sensitive
> help.

Perhaps, but its not something I look for or worry much about.

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

Yeah, I've used mc for that a couple times, tho I usually seem to
have to go hit the man page, README or somewhere to figure out what
the tag-paste key is (C-x t).  Shrug.  My bad.  Wished they'd copied
the Emacs or CUA instead

  C-x t under XEmacs is touch-buffer.

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

Umm, you're missing the point.  I spend less than 3% of my time
doing file management of any type, be it via a file manager or not.

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

The linux list is wimpy and not what I want.  What I've been looking
for is a clone of Vern Buerg's LIST (which I used under DOS and
OS/2).

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

If the cursor is on a file then it brings up a dialog.  If the
cursor is on a directory then it auto-selects that as the target.
Thus the fast operation is:

  C:/dir/> LIST
  <tag some files>
  <move cursor to dir>
  C  # copies files to dir without confirm or dialog

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

Arrrgh.  Why not TAB like everything else?  Why M-TAB?  Yeesh!
(don't answer that, I know the answer, I just don't like it).

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

Umm, but I do and can change them (albeit with some difficulty).

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

I'll assume from prior comments that you use vi instead of XEmacs.
Why?

Take your answers and apply them in reverse and I suspect you'll
find many of my reasons for not wishing to use mc and looking for a
much more vi-like tool (well, minus vi key bindings).

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

In mc:

  In pane 1 tag some files.

  Move to pane 2

  Navigate to a directory.

  Hit copy key (forget what it is).

Fails.  Why?  mc requires focus to be in the source of the tagged
operation, not the target.

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

If I haven't indicated, in any possible way, a target, then I can
live with a dialog.  If I have indicated a possible target, for
instance by having the cursor on a dir (LIST behaviour), then use
that and don't ask me.

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

Actually you can but you need to use a wrapper ala the one Marc
recently posted.  However, you're also right, I hadn't thought about
the *nix implications and was merely working off the old OS/2
recollections from 10 years ago.

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

I've no problem with IMAP, freely advocate it to others who seem to
need it, but don't like or use it much myself.  I'm an MH user.
Much of the MH preference is stylistic -- I really like the MH
approach of building a mail system as a collection of tiny single
purpose command line tools each of which only does one thing.

My default mail access patterns in descending order:

  exmh atop nmh if I local

  exmh atop nmh under an SSH X11 tunnel if remote on fast enough
  link

  MH-E under XEmacs under SSH (TTY) if remote on a slow link

  TWIG atop Apache-SSL/mod-ssl under UW-IMAP if remote on an
  untrusted or non-SSHable system

Twig (which is web based) gets run about once a year that way, but I
keep it as a fall-back in case I'm really stuck (damned rare).  Most
of my remote work is exmh under SSH forwarded X11.  The 10% or so
that's left gets done under MH-E under Xemacs in a tty under SSH.

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