Re: Your mc efforts is a great job !!!

[Pavel Roskin <proski gnu org>]

Hello!

I'm moving this discussion to mc-devel gnome org with permission of my
correspondent.

On Mon, 27 Oct 2003, Nikolai Bezroukov wrote:

[snip]
> >>    * TCP based client-server mode of work.  This is not very well
> >>      documented, but really impressive feature that makes the usage of
> >>      MC more flexible and permits cross platform usage. Although the
> >>      serial and parallel line client-server capability were available
> >>      in OFMs long ago this is the first implementation of TCP/IP based
> >>      link.
> >
> >This is just a non-standard protocol to access remote files.  It's now
> >obsoleted in favor of FTP, SSH and Samba.
> >
> I cannot say anything about real implementation, but I respectfully
> disagree about the idea of this being obsolete. In no way this is a
> obsolete feature. On the contrary this a unique flexible possibility to
> execute remote commands too and see the results on the panels.  Its rsh
> + rcp with some very interesting twist (panel view of results) and as
> such is far from being obsolete.

I'm not sure you are talking about mcfs.  mcfs doesn't allow you to
execute any remote commands other than whatever is already supported by
mcserver.  That's the standard file operations supported by FTP plus a few
goodies like chmod.

I believe we are much better off supporting standard servers that can do
the same rather than our own ineffective and possibly insecure server
(it's insecure already because it uses no encryption).  In particular,
SFTP support would be interesting to add.

[snip]
> >I have a similar patch for the hotlist, but I want to overhaul the event
> >model first.  If F10 is associated with an entry, it should take priority
> >over F10 for dismissing the menu, and it should happen automatically.
> >
> Depends on the complexity implementation. If the semantic can be
> achieved with a different hotkey or even with a checkbox, then this
> would still be better than nothing. IMHO, this F10 is not cult-style OFM
> thing like F5 or F6 and  I probably can survive with Ctrl-F10 ;-)

I just mean that the high-level code should not be fooling the low level
code to get the result.  Until recently, many dialogs had to override the
default callback to implement the default "OK" button.  That's the things
I want to prevent because they make it hard to write new code.  Not just
for others, but for me as well.

> Again: we have what we have. This is an imperfect world, and overcoming
> limitation is the way to do things.  BTW Turbo Vision style Unix
> libraries are available for Unix. See
> http://sourceforge.net/projects/tvision/

I know.  But the widget library is in a much better shape now that it was
even two weeks ago.  There is no need to change it at this point because
it would mean rewriting 50% of the code or so.  And our dialog code is
portable too.

> >>    * One of the first and still one of the best implementation of FTP VFS.
> >>    * Powerful search capabilities. Like in NC5 XTree VFS can be
> >>      emulated  panelize command, but without macros this emulation is
> >>      pretty painful.
> >
> >I don't understand this.
> >
> In many OFMs you can see "flat branch contents" mode usually bound to
> Ctrl-B: in this mode all files and all directories in a branch as if
> they are in one directory (with duplicates, if path is hidden; BTW that
> is the easiest way to see duplicated in your source tree).

I was confused by "VFS" meaning two different things on adjacent lines.  I
still don't know what NC5 XTree VFS is.  I have never used NC5.

> >>    * Synchronizing the directory on the passive panel with the
> >>      directory on the active panel hotkey  (Alt-O)
> >>
> >Yes, that's something I really, really miss in Far.  So much that I
> >started using mc in Cygwin if I work on Windows.  Yet some users keep
> >asking me to restore old behavior.  That's the first candidate to the
> >forthcoming "Advanced options" dialog.
> >
> I strongly agree that this is a really important hotkey to have. But as
> for FAR this is not quite true. In FAR you can use Alt-F1 (or Alt-F2
> depending where is the passive panel and panels will be synchronized the
> way Alt-O does it.  This is classic OFM feature that in present in
> almost all DOS/windows implementations. In FAR macro probably can be
> written too.

I didn't know that!  Indeed it's better than cd Ctrl-] that I used.  Thank
you!

> >Sorry, but this needs to be rephrased.  I don't understand anything.  You
> >forgot Alt-r but described it.  I'm not aware of a key that jumps to the
> >last subdirectory.  It can be useful, but I don't see such key.
> >
> The idea is to have access to top and bottom directory in the current
> panel (which of course depends of your sorting mode) via hotkeys.

As I said, I'm not aware of such key in mc.

[snip]
> >chown, chmod and "advanced chown" work on multiple selected file files.
> >We don't have "change attributes" at all - I cannot change e.g.
> >modification time of a file.
> >
> No. The current implementation if links in mc is really really clumsy.
> This functionality *should* be available via  F5/F6. IMHO the current
> implementation via menu  is *very* inconvenient.

I actually agreed with you about links.

> >There are Shift-F6 and Shift-F6 that come close.  Ctrl-F5 and Ctrl-F6
> >should be used for sorting lists.
> >
> True, but I do not agree with your FAR style usage of
>
> Ctrl-F5 and Ctrl-F6 I do not think that FAR implementation is a good
> idea. It's better to have a shortcut for F9-(LR)-S and then select the
> mode with the second keystroke. FAR solution takes some time to learn
> even for heavy users like me and I always forget which key is which mode.

That's which we need key mappings.  It's hard to get everybody to agree on
keys.  But we must come with reasonable default, whatever it means.

> >>    * Absence of key remapping and macro capability. Without key mapping
> >>      capability (and macro capability) several key bindings make a
> >>      DOS/Windows user accustomed to, say, FAR,  not very comfortable,
> >>      at least at the beginning (I can judge this from my own
> >>      experience...)
> >
> >Agreed 100%, but I'd like to know what you miss most.
> >
> That's a difficult question to answer. I will think about it. From the
> bat may be Alt-F1, Alt-F2 are the top.
> Also inability to use something like Alt-F5 Alt -F6 for creating links
> in Unix env drives me crazy. .

Too bad Alt-Fn is universally used by window managers.  DOS and Windows
console don't have this issue, but X clients do.  Linux (and IIRC FreeBSD)
console is even worse - Alt-Fn can bring you to another virtual console.
As a result, you can end up in a different mc, in a different directory
and delete something wrong.

I'm not against Alt-F1 and Alt-F2 in the "newbies" keymap.  It should be
possible to intercept X events in principle, but I suspect it's not easy
and may need changes in xterm and/or window managers.  I don't have time
to investigate it, but it would be great if somebody researched this
question.  If we want a certain feature to be widespread in two years
time, we should be acting now.

> >>But it looks like the major architectural weakness of MC is the
> >>absence of a build-in scripting language. There are rudimentary
> >>attempts to invent some rudimentary scripting languages is some parts
> >>of mc (for example in user menu), but they are just weak and
> >>inconsistent attempts to solve a generic problem by inventing ad hot
> >>mini-languages for each case. Currently probably the best way to
> >>script mc is to use a programmable keyboard (like EnduraPro/104
> >><http://www.pckeyboard.com/ep104.html>, FOCUS FK-9200, or MCK-142) or
> >>use Expect.
> >
> >Again, it's something that needs to be implemented and maintained.  There
> >is not enough manpower to maintain even the existing featured in a good
> >shape.
> >
> That might be not that simple and there might be some savings.  For
> example slang interpreter <unsaved:///doc/html/slang.html> may be easily
> embedded into mc to make it extensible. And that provides an opportunity
> to cut "feature creep" that takes a lot of efforts to maintain by
> implementing some features via macros.

I'd rather go with something more suitable for writing anything from
syscalls to multi-dimension arrays.  Also, it would be helpful if the
language was specifically designed to be embedded.  I thing Perl or Guile
will be fine, but I didn't research this question.  Anyway, it's all in
the far future.

> >If you don't mind, we could move this discussion to the mailing list
> >mc-devel gnome org   If you are OK, I'll repost this reply to the list.
> >
> OK.

Moved.  By the way, please don't use HTML in your messages - it doubles
e-mail traffic and can be mistaken for spam.

-- 
Regards,
Pavel Roskin