Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Softpanorama University Library

The Orthodox File Manager (OFM) Paradigm

by Dr Nikolai Bezroukov

MC line -- power of DOS to UNIX ;-)

Introduction

Gnome connection controversy and Miguel "exile" from the project

Historical notes

MC advanced features and contributions to the field

MC shortcomings and deviations

MC codebase

Introduction

MC is the leading Unix OFM originally written in 1994 by Miguel de Icaza (of Gnome fame/defame, see Jamie Zawinski joke about "Attention Deficit Teenagers" above) and Mauricio Plaza when they both were students at the Facultad de Ciencias in the Universidad Nacional Autonoma de Mexico.

While first started as an exercise in learning C, it resonated within the community and have grown into an important project. The vast majority of  OSS projects forever has just one (initial) developer. Unlike them, mc enjoyed substantial level of support almost from the start: the initial developers initiative was overtaken by the other more capable then the original authors programmers to the extent that they probably barely recognize the code inside.

This explanation makes  less strange the fact that  Miguel de Icaza, who maintains huge personal weblog, never was able to write any documentation about mc internals. He might just do not know much about the product ;-). Anyway, it is important to understand that Miguel role was limited to initial implementation and several gifted programmers helped to enhance mc to the level when it represents the state of the art of both Unix OFMs and OFMs in general.  The current version is pretty complex and mushy. None of the original code survived more then ten years of development, only original architecture mistakes are still present...

MC influenced a lot of others OFMs, including two important Window-based OFMs: FAR and FC. The functionality of MC starting from v. 4.1 was impressive (although stability of versions 4.5x were not). While mc almost died when Miguel in his obsession to imitate Microsoft tried  to perform "gender change operation" on the codebase: to convert it into analog of Windows Explorer for Gnome, version 4.6.0 thanks to the efforts of Pavel Roskin returned mc to its command line interface roots and improved stability, although much more needs to be done with the aging huge C codebase. 

Formally MC is the part of GNU project. But GNU/FSF does not provide any real support for the projects other then some basic and poorly maintained source tree storage infrastructure. Therefore in reality being part of GNU represents only some (substantial in 1996-2000, now tiny) PR advantage in comparison with the independent status.  In short mc is one of the many large, semi-abandoned GPLed project written in C that is survives due to heroic efforts of individual volunteer developers, who are struggling to provide life support to a pretty sick creature, which survived the attempt of gender change operation and whose health deteriorated further under the weight of the huge codebase. The latter  probably had outgrown the capability of a single volunteer maintainer, even a talented and dedicated one to see the whole picture. 

Still despite past and current problems, mc filled previously empty niche and as such was/is amazingly successful. Unlike most open source projects it managed to survive the departure of the both original authors and a couple of maintainers, the feat that positions it heads above many of the competition.

MC developers found multiple ways to increase the power of OFM in Unix environment and the resulting product looks very natural for Unix. For Unix sysadmins who know bash I would like to note that there is no excuse not to use mc on the command line (other than adopting a different OFM file manager ;-): this is just a new generation of command line shell interface. Strangely enough the capabilities of OFM as specialized window manager somewhat similar to screen were never understood by the development team. Although mc went farther then most Unix OFM projects and provided support for the Ctrl-O operation (hide panels and expose shell screen) they never managed to enhance it to usable status -- there is no way to shrink panels to see part of terminal screen (the "half screen" capability and the capability to hide each panel individually  is present in NC line since the NC 2.0).  That limitation extend on the editor and taken together they limit the usefulness of MC in debugging shell and Perl scripts.

Please note that you do need to use bash for mc: an integrated shell window (Ctrl-O) does not work with ksh or other shells. As bash is pretty portable and now is widely used as a primary interactive shell on Solaris and other Unixes it looks like close integration with bash was not an entirely bad design decision (the decision that just happened because Linux was the main development OS). Still we need to remember that screen avoids this dependency so this should be generally considered as a deficiency.  

The version 4.6.0 that I evaluated in this edition of the book is a pretty mature product. It's considerably better and more usable than previous versions, although it is still remains slightly "gnome-biased" and portability is rather limited. It is also based on glib (and 4.6.1 is based on glib2 which IMHO was a blunder). Those decisions remain a source of a controversy in the mc development community.

Pavel Roskin, who is the current maintainer of  mc provided very strange explanation of  his position on the issue: it was essentially along the lines "I would prefer mc to be written in C++, but as it is impossible let's use glib".  Later under of the influence of suddenly waked up to the situation Miguel,  he changed his position into supporting glib2: huge and rather obscure library with functionality not very suitable for OFMs. Using libraries instead of reinventing the bicycle is a trandard programmers practive (see Pavel's summary below) and is important taking into account of the size and complexity of the codebase.  but the key question here is the number of primitives that can be beneficially used and how much they shrink the codebase and what kind of errors they really prevent, if at all. In case of glib the answers is "not much, not many" and if this is true then Pavel implicitly moved mc in " One Miguel Way": toward Microsoft-style products that requires special installation instead of a portable tool for sysadmins like classic Unix tools. In case of glib2 portability is doing down the tubes. But Roskin's obscure reaction was still rationally explainable in a sense that the codebase definitely has outgrown the size of maintainable (taken into consideration the current pool of developers) pure C-based open source product.  Actually this fact created a new opening for deco and similar lightweight OFMs.

Previous versions of mc were less OS/library dependent (although not by much). Still v. 4.1.35 (reviewed in the prev edition of the book) has tremendously important to mc developers as the last "gnome independent" version. It was also the  version when I felt that MC became a leading Unix-based OFM, comparative in functional capabilities to the best Windows implementations (despite its clumsy and undocumented codebase.). That's why later it became the base of forks for developers who reject usage of glib/glib2 in the project (see below). 7

MC introduced several important innovations -- most notable was external panelize command and user menu visibility predicates. MC also pioneered FTP VFS (available from version 3) as well as TCP based client-server mode of work. It also has some interesting Linux-specific innovations -- like file undeletion in ext2f file system. At the same time "look&feel" of mc is pretty archaic and interface is much less flexible then in FAR. Among most visible problems are:

• There is no ability to sort columns of panels with a mouse click on the title
• The built-in editor cannot be minimized to one panel and works only in full screen mode
• Key panel elements (current file on active panel, the current file on passive panel, path to active panel, path to passive panel, highlighted files on active/passive panel, etc) are not exportable to the editor.
• Panels are "non-shrinkable" and non-resizable asymmetrically sized panels possible in FAR are impossible in MC). This is very important in Unix as such attributes as ownership and rights require a lot of scarce and are more important on active panel then on passive. 
• Implementation of history is inconsistent and does no encompass all menus.

MC is one of few UNIX OFMs implementations that has been ported to Win32 platform, although Win32 port was not very impressive and recently died from malnutrition. Still Cygnus version of 4.6.0 can be used in Windows and even provide some advantages over FAR due to better implementation of  shell library concept (F2).

Gnome connection controversy
and Miguel "exile" from the project

Due to Miguel de Icaza blind orientation on Microsoft imitation (Miguel MScopycat Icaza ;-) the connection of MC development to gnome development proved to be a very mixed blessing. The main reason for this was not the idea of creating a GUI version of mc (gmc), but the idea of putting Windows Explore straitjacket on a pretty solid OFM manager. Essentially Miguel come close to destroying his project and only brave efforts of Pavel Roskin  managed to preserve the main codebase (see below) and prevented forks from taking over.

Due to problems with deteriorating quality of the codebase in version 4.5.x and its excessive Gnome dependence (many people including myself think about Gnome as OSS bloatware) several developers continue to enhance 4.1.35 codebase with the explicit aim to remove all connections with the gnome and glib. In this sense forks of mc are pretty much alive and well fed by the resentment with the original codebase branch.  

Here is one letter that provides some insight into the situation and the level of resentment about the current (remaining) connection of mc and gnome project via glib. This is not completely correct as glib is a general purpose library that probably has more connections with emulating STL, but still from the psychological standpoint this is a valid point (for more information see the whole discussion on Nov 14-Nov15, 2003 in mc-devel) :        

... ... ... 
 
Ali> I also share the opinion that re-using code is a wonderful
Ali> thing. But it only makes sense in large projects such as re-using
Ali> a framework of standard libraries under GNOME for
Ali> example. Standard libraries are librsvg, libbonobo, libbonoboui,
Ali> libgnome, libgnomeui, gnome-vfs and so on. This makes a lot of
Ali> sense and is the right way to go. You can count on my vote for
Ali> this whenever someone shows up infront of me and asks whether
Ali> this is a good thing or not. Depending of making glib a standard
Ali> library is also something that needs to be viewed by the
Ali> individual.  There are people who believe it to be standard,
Ali> others think of it as a graphical helper library for GTK+ and
Ali> GNOME. Last one is valid for me.
Ali>
Ali> I only believe that this is not a good thing for midnight
Ali> commander. It's by far the only console application that I've met
Ali> in all the years (that I personally use) which has this
Ali> requirement.

I agree with you. I won't even bother to download and try it out an
mc that has libbonobo in it. Or anything else, for that matter -- I'm
slowly extracting myself out of gnucase and a couple of other tools
that use it. As the guy in in Pulp Fiction said, "sewer rat may taste
like pumpkin pie, but I'll never know, because I won't eat the filthy"
thing.

I've already had too large a portion of my life wasted by the gnome
people.  Maybe in fifteen years when a generation of programmers have
passed through, and I can be reasonably sure none of the original
people are still writing parts of it, I'll look at it.

It's important to consider that kind of mindshare that a project can
lose by releasing successive worse and worse releases.  Especially
when there is a hype associated with it that is so clearly at odds
with what you see on your screen.

Ali> I'm also into making rescue systems. I must admit that I recently
Ali> started with it but it was something I always wanted to do and
Ali> understand correctly. But I don't belive that such stuff should
Ali> depend in the initrd image rather than one step later in the root
Ali> image after you pivot_root'ed into it - But I'm not to judge here
Ali> how people are doing their stuff. For the interested ones, you
Ali> can get a dead simply rescue/boot/backup bash script from my
Ali> webpage which generates such a cd for you, e.g. creating an
Ali> initrd, copying busybox onto it, then creating a syslinux disk
Ali> out of it and then later on creates a root image with some files
Ali> on it.
Ali> 
Ali> http://www.akcaagac.com/tools/files/shell/cdimage.sh

I made a single floppy linux that has mc on it:

http://rgr.freeshell.org/flinux/mc-link/

It was more pain that it needed to be.  At one point I dug up out of
the Slackware archives the slackware package from mc 3.5, and
attempted to use that, and it lacked some feature which I have
forgotten. Then I went back to a more recent version and commented
out whole swaths of troublesome code.  It seemed that I could pick any
source file and randomly delete stuff and mc would get better.  At
around that time the 4.6 version was released, which was a large
improvement, and the only thing I needed to delete was some stuff in
mcserv.

I like the current mc, and I think it is going in the right direction
in general.

>> If you think in dependencies: there's an uglier dependency of mc,
>> namely slang. My experiences show that mc compiled without slang
>> (only ncurses) has lot ot problems. IIRC even the developers say
>> that compiling against only ncurses is not recommended.

I compiled mine with ncurses.

>> Ncurses ships a big terminfo database, but it's possible to compile
>> some terminfo entries hardwired into ncurses. We have the most
>> common terminals (linux, xterm, vt100 and screen) compiled into
>> ncurses, this makes its size bigger about 2kB or so, which is
>> nothing. And then ncurses applications perfectly work on these
>> kinds of terminals without any terminfo database. Slang, however,
>> isn't able to hardcode some terminal entries. So for a slang-mc to
>> work properly, you must have the terminfo entries installed.

I did not know about compiling the terminfo's into ncurses.  I put a
single terminfo entry (linux) on my floppy.

Ali> I am already peeking to the MP fork of 4.1.35 -> which now became
Ali> 4.1.40.
Ali> 
Ali> http://mc.linuxinside.com
Ali> 
Ali> It's based on a pre glib/gnome version of midnight commander,
Ali> which was heavily bugfixed and some nice little features got
Ali> added even backported from 4.6.0. The entire size is less than
Ali> half of what midnight commander became now. I only had some
Ali> problems with the colors when started up but got told a
Ali> workaround for this with the -Y classic color option that I
Ali> haven't paid attention for. I do share some of the sights from
Ali> olegarch here and I'm already in contact with him, whether we can
Ali> create a mailinglist and continue working on that one. I have
Ali> raised my opinion on the current situation of midnight commander
Ali> from a users perspective and I'm not forcing my opinion on
Ali> others. There are quite a lot of nice stuff in 4.6.0 no doubt but
Ali> some things have also changed for the bad. I primarily want is a
Ali> console filemanager that I can use to delete some junk, move some
Ali> dirs and rename some stuff - which not depends on glib.

It looks interesting.  In the cursory inspection I just gave it, I was
only able to compile it in the --with-included-slang configuration.
Compiling with -Os and stripping, with options as close to what I used
in mc 4.6 as possible, I get an executable of 4.51 MB, while my mc 4.6
executable is 3.98 MB.   I fiddled with the config options and
recompiled it three times.  Basically, it reminds me of mc 4.1 which
would not allow me to turn off enough options to fit it on a floppy
system.  However, I think it is good that multiple groups are
maintaining different versions of mc.

However, it is important to note that mc 4.6 is smaller, or can be
configured to be smaller, than it's predecessor.  The difference in
size is larger than the additional 171k of glib.

That's why I think mc is on the right path.  I agree with Pavel's view
on the various issues.  I would tend towards avoiding glib myself if I
were coding, but then I haven't contributed any code lately, and glib
is small enough that it has not stopped me from doing anything I want
to do with mc.

--Rob

Arpad Gereoffy  also joined this discussion. Here is the summary of A'rpi position on the issue:

> Koblinger Egmont wrote:

> > Gabucino votes for glib1

> No, I vote to no glib at all! A two panel filemanager doesn't need all these
> sophisticated stuff! Check Volkov Commander, it's a 64kb DOS COM executable
> (and imho it's much faster/stabler/better than mc, pity it's on DOS).
> 
> But this argument is getting very very pointless, it seems Pavel apparently
> listens to noone, likes reinventing the wheel, dropping simple support for
> many OS'es, and his dictatoric means of maintaining resulted in the
> appearing of many mc forks...

Ok, I think it's time to comment on this thread.
I've just ran through this thread, read the most, but not all mails, sorry
it's way too much offtopic and flame and PR text.

As I already told in private to Ali, my opinion on these:

glib issue: i don't care of glib, at all. first when i noticed it in 4.6, i
didnt liked it, but i can understand and accept that it simplifies mc code,
and moves some bugfixing and maintaince and porting work to the glib team.
i will like if glib is removed, but i don't mind if it remains there.
anyway i'm against including glib as-is in mc source, it's total nonsense.
i'm not against code sharing, it's a good thing, if it's well done.
(and no, i won't work on glib removal of 4.6, i simply has no time for
something i don't care.)

Forks: since i'm "owning" 2 of them (4.1.35-Axx series and amc-4.6 cvs),
i can't simply say here that i don't like them :)
but the reason of forking was not glib at all. it was gnome (!=glib) in case
of 4.1.35-Axx, and other buggy broken bloat in 4.5.xx series. when i did
that fork, there was no 4.6 (at least i wasn't aware of it), and the 4.5.x
series was so broken to be totally unusable, and does not worth to fix it.
i've worked a lot on the -Axx fork, to fix known bugs, add most-wanted
features and fix VFS/extfs drivers, especially the oh-so-broken FTPfs.
then i stopped that work, due to MPlayer project and other works.

the next fork, amc-4.6 was done after 4.6.0 release, due to my patch sets
for 4.6.0 being rejected by maintainer with no (or not acceptable) reasons.
but i want to note, that i have nothing bad with current 4.6.x
maintainer(s), i see and can accept that he tries to keep the baseline mc
code as clean as possible, and fix all issues and remove obsolete code
before starting (re-)adding funcy features.

i should have done the same with mplayer years ago, keep it clean, and
refuse all feature patches until the code is cleaned up and bugfree.
(so i could avoid restarting from scratch nowdays, with mplayer-g2...)
but it isn't so simple, there is a big demand from users for new features,
so we must either accept these patches for the mainstream code, or make a
fork which focuses on features instead of cleaness and bugfixes. such fork
can be the testbed for such patches, before they gets accepted for the
mainstream code. this is teh reason, why i made amc-4.6, to accept and
test verious patches being refused from mainstream code. 

unfortunatelly i was too busy to work on this fork, or even maintain it,
so it died as fast as it born.

I was recently told about a new fork, the mc-mp (aka 4.1.40-preXX).
it is said to be based on my 4.1.35-A12 code, but it miss many of the
features and fixes i made in -A12 from it, so maybe it isn't true.
(anyway it should be true, as some of my code is there in mc-mp, even
if it doesn't work due to other changes...)

also, it has a strong DN (dos navigator, some of you maybe remember that old
thing, ran by people on dos who didnt like (the imho much better, and less
bloated) volkov commander) feeling, especially in colors and some fancy
features (like clock in the corner etc). even with -Y option it still has
unusual look-and-feel compared to mc or vc or nc.

besides of that, it's a nice try, i like it. it is based on 4.1.x series,
but has the good parts of 4.6 backported, like the builtin df and find-file
code, and the editor. the vfs code is based on teh old API, which works
better (imho) for non-local filesystems than the 4.6 one.

(remember, i failed to port my ftpfs fixes to 4.6, due to new api lacking
some basic features) also, the mc-mp maintainer guy said something 
(i dont know that code, so i cant decide) about the new dialog boxes code
being much worse in 4.6.

BTW, could someone list the features and advantages of 4.6.x over the
4.1.x series (release or the forks: 4.1.35-Axx or 4.1.40/mc-mp) ?
i'm interested in both code-level (internals) and user-level (features).

i think it's a very important information for the decision, so we can
see if it does worth to work on mc-mp (and backport interesting things
from 4.6) or it's better to port -Axx and mc-mp features to 4.6-based fork
(be it amc-4.6 or make another). some time ago (2003 spring) i thought
the second is better, but after checking the mc-mp, and talking with his
author i'm unsure now. 

What i saw in 4.6 was some API changed, heavy usage of linked lists, 
internal types and other OOP things make it less readable.
It wouldnt be a problem alone, if i see same amount (or more) advantages of
4.6, to balance it. but it seems the interesting features of 4.6 (over 4.1)
were easy to backport to 4.1, so why bother with 4.6 any more??


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu

The bad thing about this debate is that it was clear that many developers linked glib and Miguel fiasco with conversion of mc into Microsoft File Explorer emulator. His insistence on preservation of  the link between mc and Gnome, due to the version 4.5x troubles served as an allergen for many developers.

Pavel Roskin  assessment of the situation "That's an invalid argument.  Maybe there is a problem with perception of glib as part of GNOME, but I cannot fix perception by technical means." missed an important social component of the situation: the explicit betrayal by him and Miguel of the idea of the reasonably light-weight, portable multiplatform tool and conversion of mc into yet another bloated open source application with a lot of  unmanageable and semi-debugged code.  The question arise: if a maintainer is enable or unwilling to extract a small relevant for the product subset from a huge library and enhance it, what value the usage of those primitives has for the project and is not it negative  ? As Ali Akcaagac noted:

On Sat, 2003-11-15 at 18:29, Miguel de Icaza wrote:

> Not everyone has the same goals, some people want features,
> some people want to fit things in a 64k segment.

I think this is getting worse now. We shouldn't move in a gray corner
here by itching people. Regardless who started it, we are only talking
about software here.

> I already pointed out to Linux. Few people run "stock" Linux, most
> people run a distro-fork-Linux. There is nothing wrong with that.

- And again some are trying to manifest Microsoft innovations on Linux,
but most people already mentioned how much they dislike it.

- Some people are using blog entries to write 20 pages about their
business product + code examples to manifest Microsoft innovations, but
most people use blogs to describe their daily feelings.

- Some companies are trying to sell GNOME as their product, but most
individuals are working on it as individuals in their spare time.

What an illusion... isn't it ? No bad feelings but I think we should
play fair again and concentrate on what's important. After all we are
pro Midnight Commander users, we do like it, thus we do like to improve
it. That people have different opinions is nothing new.

While static linkage of glib looked like a reasonable compromise due to Pavel's huge role of the maintainer of 4.6 branch and the load that he took for a year or so, his decision to adopt glib2 was a bad one:  he failed to understand that glib2 usage opens door to other non-portable or "gnome-style" decisions in best Miguel Ms copycat style. At this point his position did not matter much as he was at the end of his cycle of active mc maintenance (his last significant contribution was  4.6.1-pre1 released December 24, 2003), but by the mere fact of being an official maintainer of the project he can effectively block any dissent. Here is Pavel Roskin 's  "an exercise in glib-defense" letter (red italics are mine -- nnb)

Let me sum up the arguments as I see them.  It should be easier than to
reply individual messages.

1) glib is easy to remove

I don't care if it's easy or not.  Just because it can be done, it doesn't
mean it should be done. [Note that he avoids the explanation of the fact
how glib can make codebase smaller, less probe to errors and more maintainable -nnb]

2) glib adds code size at the runtime

Many other things do.  Those who design embedded systems should consider
what can be removed or disabled.  I believe that glib1 should be used and
linked statically to eliminate unused code.  Maybe glib2 should have
better support for embedded systems, e.g. it should be possible to
eliminate some unneeded features, like selection of the malloc
implementation.  Also, some sources could be split to make smaller object
files and this make linking more fine-grained.

3) glib adds (or will add) dependency on GNOME, XFree86 etc

That's an invalid argument.  Maybe there is a problem with perception of
glib as part of GNOME, but I cannot fix perception by technical means.

4) glib may have its own bugs

Yes, but I'd rather trust the list code written by somebody specifically
writing the list code rather than the code by somebody implementing e.g.
directory list in mc.  There are some little details that are hard to get
right if you are thinking of something else

I must admit that glib makes it easy to make certain errors with lists.
I don't know if alternative implementations were considered.  But I don't
know of any replacement for the list functions in glib.

5) glib has an unstable API

Unless you specifically disable deprecated functions, it should be
backward compatible.

6) glib is hard to compile

That's true for glib2 because of its dependency on libiconv, gettext and
pkgconfig.  I still cannot get the build script build-glib2.sh to work on
FreeBSD 5.1.  This needs to be fixed.  In particular, recent versions of
gettext hardcodes the ".so" suffix in some places.  Also, glib doesn't
detect libiconv properly in some situations (it uses headers not matching
the library).

On the other hand, we have glib1 now, and it's easy o compile.

7) glib brings additional dependencies

glib2 doesn't bring any additional dependencies for full-featured mc.  We
are using gettext already, and libiconv is used if the charset conversion
is enabled.  If you are building an embedded system, use glib1 for now,
but help glib2 developers to make glib2 leaner (optionally).

8) glib brings no real benefits to mc

Not true.  A lot of string operations are simplified by functions like
g_strdup_printf(). It may seem easy to replace each function with an
equivalent not using glib, but it may not be so easy to understand and
modify the code using standard string functions.

9) we don't need glib2, let's just integrate parts from glib1

glib2 has potentially useful code, such as Unicode support and the event
loop.  If we were using the event loop, porting mc to BeOS with its
braindamaged socket-only select() would have been trivial.  We cannot rely
on Unicode support in libc if we want to stay portable.

10) glib is not portable

glib1 is portable.  There are minor issues with some OSes, but they are
trivial to fix.

glib2 has issues with one of its dependencies, namely gettext.  I'm not
aware of portability issues in glib2 itself.  These problems can and
should be fixed before we drop glib1 support.

11) the alternative to glib is glibc

We cannot rely on GNU extensions if we want to stay portable.  There are
many libc implementations that crash on free(NULL).

12) shared libraries are inconvenient, fault prone etc

Shared libraries are good enough for OpenBSD.  Modular design is good
enough for spacecrafts.

13) users won't find glib, especially the glib-devel package

If you are compiling code, you are supposed to understand something.
Otherwise, use precompiled packages, including mc.

IMHO using glib2 (4 meg monster gzip package on Solaris; in comparison glib1 is less then 800K) plus libgcc (another 9M compressed package for Solaris) creates a distinct "gnomebloat" smell for any console-based product.  And both mc 4.6.0 and 4.6.1 unfortunately depends on it:

Freeware for Solaris

mc-4.6.0-sol9-sparc-local.gz GNU Midnight Commander (also referred to as MC) is a user shell with text-mode full-screen interface - installs in /usr/local. Packages that mc uses are libiconv, glib, and either libgcc or gcc.

So on Solaris, unless you create a statically linked executable,  you need to install at least three libraries (libiconv, glib2, and libgcc) just to use mc on a particular server. Pavel Roshkin may not care at all, but administering multiple server is what most sysadmins are doing and mc is the tool for sysadmin first and everybody else second (only very stupid developers would use it as a poor man IDE environment in XXI century). 

Is this a writing on the wall for mc future and dooms it outside Linux ?  At least it is clear that this is no longer a portable product that you can use of any server you need to work with.  And as most admins need to work with dozens (sometimes hundreds) of servers. 

May be mc will illustrate again that a C-based open source product has some natural limits and is at some point a bloated codebase means that the product outlived its usefulness and people just need to bury the corpse and move on.  It looks like despite the codebase availability, open source software really could die due to bloat  (at this some point the product codebase can both exceed the capabilities of the developers to support it and capabilities of the users to install it on multiple servers/workstations/pc).

Historical notes

MC was originally developed in Mexico by Miguel de Icaza  and Mauricio Plaza when they both were students at the Facultad de Ciencias in the Universidad Nacional Autonoma de Mexico. At the beginning it was just a learning C exercise.  But the project got traction (may be due to the popularity of GPL at this time) and later even survived the departure of the initial developers. The history of Midnight Commander can be traced using archive at source-mc-old.

One of the first description about those initial days of Midnight Commander was published in January of 1998 in a pretty funny, April 1-style (but dated March 1998) interview  for Linux Focus.  As Miguel de Icaza recollected:

LF: How old are you?

Miguel: 27, no 25. I was borned in 72. Listen I remembered now, I wrote the Midnight Commander when I was 20. That was 94 or 93? I believe so. I remember that I wrote the Midnight commander for Linux. I developed it on the Sun because it was faster than the shity PC, but it was for Linux. Shit! when was it? I don't remember, I must be in the MC.

The initial versions (see for example version 0.3 that was released in May, 1994) were extremely primitive (no Ctrl-U, F2, F3, F4 functionality at all). F5, F6 functionality was implemented via system commands. The user menu was added in version 0.4. Here is a relevant section of NEWS file that provides some insight into the level of problems the were solved at this stage:

Version 0.4

- User Menus (F2 key).
- Quick search of files in a panel (Alt-filename takes you to that file).
- Char quoting (C-q).
- exec() enhancements.
- now you can suspend the program (C-z).
- The find file command now seems to be very stable.
- misc bug fixes.

Version before 0.9 were were called MouseLess Commander. Mouse Support was added in version 0.9  and the name was changed to Midnight Commander.

Version 0.9

- Mouse Support.
- Internal Copy command (it no longer uses cp).
- Verbose Copying of files.
- Confirmation on Overwrite and on Delete.
- Support reverse sorting.
- Many visual enhancements.
- Per panel options are saved and restored.
- New truncation of names in the panels.
- History in Input Lines (M-p and M-n).
- Input line enhancements.
- Dialog boxes are nicer than before.
- Cache in gid and uid translators.
- More keybindings for the Input lines.
- Better kill management in Input Lines.
- Bug fixes.

Essentially mc became a more or less usabel obly after contributions by Janne Kukonlehto. Version 0.14 that was released September, 1994 was the first that behaved more like Norton Commander. It already contained standard mc naming scheme in user menu. Here is the contents of  user.menu file from the distribution:

# %f is the currently selected file name
# %d is the directory name of the current panel
# %F is the selected file in the  passive panel
# %D is the directory name of the  passive panel

A       Dumps the currently selected file
    od -c %f

B       Edit a bug report and send it to root
        vi /tmp/mail.$$
        mail root < /tmp/mail.$$

G       Display the file with roff -man
    nroff -man %f | more

H       Call the info hypertext browser
        info

J       Copies -R . to other panel with tar
    tar cf - %d | (cd %D && tar xvpf -)

K       Makes a release of the current subdirectory
    echo -n "Name of the distribution file (without extension): "
    read tar
    ln -s %d `dirname %d`/`basename %d`.tar
    cd ..
    tar cvhf - $tar | gzip -f9 > $tar.tar.gz

X       Extract the contents of a compressed tar file
    tar xzvf %f

At the beginning the pace of development was really amazing. One of the first usable version (Version 2.1) was released in February, 1995 one year after the initial version. It was probably the first with the new name.  A lot of code was contributed by Janne Kukonlehto. README file listed six co-authors: Miguel de Icaza, Radek Doulik, Janne Kukonlehto, Fred Leeflang, Mauricio Plaza and Dugan O. Porter. Here is the relevant fragment of NEWS file for this version:

Version 2.0

Now users are able to define their own display

- User defined display formats.   Now you can configure the file display to suit your needs.   For example, you can say which information you want to see displayed   instead of our defaults.

- User definable program layout.   Panels could be shown vertically or horizontally; panels could be different sizes, you can hide or show most program windows (command line, keybar or menubar).

- Output window. Now, it's possible to see part of the last program output on the Linux console without having to switch screens via an option in the layout menu.

- New View modes: Quick view: as you browse your files, each one is displayed on the other panel on the idle time.

• Tree view: let's you browse your directories by traveling a tree. We have two traveling modes available. And the tree does not take your precious time: it's build on the fly, as you browse your disk (you can always loose your time if you want to :-).
• Info view: Gives you information on the currently select file and the current file system as you move.
• User view: Let's you define a directory listing and the format you want to use.

- New subshell support (concurrent shell execution)

The Midnight Commander will now spawn one copy of the shell, so you get better performance and you can use shell functions, define variables and execute complete shell commands. Supported shells: bash, zsh. If your shell is not supported, then the old mode is still available.

- Dialog box manager: Almost all the new configuration options are configured with this new dialog manager, easy to use if you are familiar with dialog boxes in DOS and Windows.

Available widgets: check buttons, buttons, radio buttons, input lines and list boxes (So you can take our code and use it on your applications).

- New option configuration. Now the program options are configured with a dialog box.

- Chmod and Chown commands: For changing permissions as well as ownership of files and directories, uses our new dialog manager.

- Color customization support Now you can change the default color of the program with any of these: environment variable, Colors section in the init file (colors per terminal type) and command line.

- User menu and extension enhancements: Execution understand the %t macro (tagged files). User menu also has a new macro to let the user specify options. You can hide and show entries in the user menus by using conditions. Auto detect best match depending on a regexp.

- Viewer: Goto line command, horizontal scrolling, on the fly uncompression (and we don't eat unneeded cycles of CPU), allow non gunzip operation. - Internal move command: Now, we don't rely anymore on system commands in /bin, so the program is more robust and is much faster. Bunchs of code come from the GNU fileutils.

- The Tree view and normal views allows wrapped incremental searchs of file names. - Mask rename: Now it's possible to do things like rename *.pas in *.bak - Compare directories command - Allow panels to be in Long mode without forcing the user to a single panel. (You can even have two long panels). - F10, C-g cancels as well as ESC ESC. - Improved help system. We updated and spelled the help system and added a lots of links. The Web page is constructed with the same tools.

- Allows tagging of directories: Now you can copy, rename, move and delete complete directories. You are not limited anymore to files.

- View output (screen save/restore) on Linux console. On old Linux systems, only b&w is supported, on newer Linux systems (1.1.67 and newer), we also support color screen save/restore and cursos positions. - 8 bit clean support. if ncurses is 8 bit clean, you can see international characters (we include a patch against ncurses 1.8.5).

- Visual feedback while i-searching files.

- Much more intuitive, you have to use it.

- It's better than aspirin.

- New memory allocation debugger. During testing time, we used a powerfull memory allocation debugger, so the program will not eat all your memory, and will make a good use of your memory. - Now it also runs on hppa-hp-hpux9, hppa-hp-hpux7, m68k-apple-aux and sparc-sun-netbsd1.0. The best platform to run it is Linux, of course, since that's where most of us develop it.

- Inode sort option.

- Nice progress status indicator. We have two of them: a moving dash indicator and a progress bar indicator for file operations.

Version 0.15

- Uses GNU autoconf. Currently, it has been ported to this configurations: i386-*-linux1.0 i386-*-linux1.1 mips-sgi-irix5.2 mips-dec-ultrix4.3 rs6000-ibm-aix3.2.5 sparc-sun-sunos4.1 sparc-sun-solaris2.3

- Improvements to the internal file viewer: Wrap/Unwrap mode. Hex mode. Hex searches. Now you can view compressed files (gzip, compress, zip, pack and lzh). Performance enhancements, now it's much faster. Works on systems without mmap. - Mouse Support now also works on xterms. If you run in the Linux console, you will still need the gpm mouse server to use the mouse support, but if you use xterms, then you're lucky and can use the mouse support when using xterms.

- Help system and man page. Both were updated and has many more hypertext links inside, the help system can also be used with a mouse.

- If running on xterms, now you can see the output of the last program you ran by using the C-o key combination. - Switch panels command (C-u) - With filter command per panel. - With auto mounting/umounting on chdir feature. - cd now expands tildes (~, ~user)...

Version 3.0 was released in September, 1995. This was a milestone in MC development as it contained the initial version of FTP VFS (by Jakub Jelinec). In this version he also implemented the tar VFS. Later ftpfs was enhanced by Ching Hui. In an interesting twist Pavel Machek wrote Podfuk, which was Coda server (first it was a NFS server) that used the mc-vfs internally and allowed any Unix application to browse any mc VFS. Podfuk was successfully ported to Solaris.  Here is the fragment of NEWS file for version 3.1:

Version 3.1

This has been finished:

- Enhanced ftpfs:
  - Displays progress bars.
  - Supports netware and windows nt servers
  - Better support for symlinked files.
  - Handles those warez sites file names.
  - Increase the directory cache timeout.
  - Cache flushing (C-r)
  - If you append a /~ to the directory, you will log into your home
    directory (this is done by default if you use the menus to connect).
  - More robust.
- Subshell fixes (it should not hang any longer).
  - Fixes prompt handling for zsh and tcsh users.
  - Fixes variable expansion for tcsh (now you may edit files).
  - Rewrote the sync code between the parend and child, should not hang
    any longer.
- Better command completion.
- Keypad handling enhanced:
  - Special key treatment for +, -, \ and now may be configure to
    only take place if you do not have a command typed in.
  - Now the + and \ bindings when ran on the Linux console work
    may use the keypad and M-+ and M-\ and leave the + and \ keys
    free.
- Better handling of the line drawing chars on OSF/1 and AIX.
- Enhanced tar/compressed tar file systems.
- Global kill ring.
- Added undelete feature for Linux systems: now you may recover deleted files
  on ext2 file systems with the Undelete file system.
- Symlink commands (for symlink lovers).
  see the docs on C-x C-r,  C-x C-l, C-x C-s keystrokes.
- New macros:
  %b and %B return the basename of the selected filename
  %var{ENV-VAR} expands to the contents of ENV-VAR variable.
- MC may be invoked as a viewer (mc -f flag).
- Added Unicode support on the Linux console (run with mc -N)
- Tons of bug fixes, the code is cleaner and hopefully 
- Allow a vfs pathname to be passed as a startup directory.

This is a list of people that put their effort into making the 3.1
release:

Adam Tlalka, Antonio Palama, Carl Thompson, Ching Hui, Dugan Porter, Gerd
Knorr, Ilya Rybkin, Jakub Jelinek, Janne Kikonlehto, Juan Grigera, Juan Jose
Ciarlante, John Davis, Marcelo Fabian Roccasalva, Perry Francis Nguyen,
Sergey Ya Korshunoff Steven Hirsch, Thanh Ma and Torben Fjerdingstad.

Version 3.0

- Virtual File System: You now can browse tar, compressed tar and 
  file systems over the network as if they were local subdirectories;
- Slang support, you don't need ncurses anymore (but you can still compile
  with ncurses, if you want).
- New mc.ext format, for details see the sample mc.ext file provided.
- Append option if you try to copy/move a file onto already existing one.
- Internal cd command uses CDPATH variable if set (like in BASH).
- Find file command is much faster.
- External panelize command - finding files using unlimited number of
  criteria - actually spawns an external command and it can be find, awk,
  grep -l or anything else.
- Learn keys makes setting up of mc on terminals with broken
  terminfo/termcap databases easier. It just asks you to press keys which
  are not working.
- Advanced chown command.
- C-PgUp and C-PgDn takes you to the previous and currently selected
  directory respectively on the Linux console.
- You can choose between 7 data bits, iso-latin-1 (0-127+160-255) or
  other (0-255).
- Confirmation for overwriting, deleting and exiting added.
- Viewer has growing buffers.
- Filename, username, hostname and variable completion (M-Tab) on all
  input lines plus command completion on appropriate places of command
  line.
- Following of symlinks at changing directory.
- Viewer now supports bold faces and underlines, and it fits the 
  information on the screen better.  Now you can also specify the starting
  mode for the viewer depending on the contents of the viewed file.
- Mask rename and copy.
- Colors now let you specify the intensity of the colors you want.

This is being worked on:
- Virtual File System: FTP file system.
- Tcl/Tk and XView versions of the program (preliminary versions are
  up and running).

The number of contributors increased and eight of them were listed as co-authors: Miguel de Icaza, Janne Kukonlehto, Radek Doulik, Fred Leeflang, Dugan Porter, Jakub Jelinek, Ching Hui and Mauricio Plaza. It's not clear whether the success was purely accidental (being in the right place in the right time) or largely due to the organizational abilities of Miguel. This version was also ported to NT by Juan Grigera and for some time the NT port was the part of the distribution, before it died form malnutrition. Here is how Juan recalled the situation in his interview to Winplanet :

"I was using Norton Commander under WinNT (that was in 1995, there were only betas of '95) and was tired of losing long filenames when moving/copying files. So I downloaded the mc DOS port (a port of mc 1.0 made by Antonio Palma) and started to write system specific parts of a DOS curses (which ended to be copyrighted) and then succeeded to compile it with Visual C 1.0 after some work, but it was old. So I tried the latest version (3.1.x) and after hacking it sent a mail to mc-development, telling I had ported mc to NT. Miguel encouraged me to keep the port within mc distribution (rather than separate it from the project), and patiently diffed the sources, hacking here and there. I then made a draft of the slang port which John Davis seriously hacked, so every part in the port was then distributable. Windows '95 had to wait a while (until I installed it on my machine) since Win32 API would not work just the same as in NT (w95 failed to create a console)."

I also asked him about the support he got from the Unix / NT community:

"The developers community is pretty active, the list is always having new volunteers. Unix developers welcomed the port and supported it. Recently, Alexander Dong and Dan Nicolaescu have contributed changes, being the first two developers compiling mc under Win32. From users I know little since I am not subscribed to "mc" list. I never heard a word form an NT/95 user, not even bug reports. Maybe mc was still too much a beta to be used (some really ugly bugs such as failing to delete a non empty dir in w95 --due to w95 returning ENOACCESS instead of ENOTEMPTY-- were only fixed last week)."

In 1996 Miguel de Icaza supported KDE, but in 1997 he sensed an opportunity in the Red Hat desire to have its own graphical desktop and RMS desire to have a GPLed desktop and jumped on it abandoning his old friends in KDE community. Soon he became a prominent figure in Gnome project and  RMS's poster boy for promoting GPL and KDE jihad. Here is one of the letter from KDE List about this event

Re: Miguel de Icaza by fled on Tuesday 10/Jun/2003, @01:36

I'm sure Miguel is a nice guy and all, but he did pretty much betray KDE. Back in 1996, he was almost fanatic about KDE. In the comp.os.* newsgroups back then, he said a lot of positive things about KDE and backed it wholeheartedly (remember that he was the developer of mc, and as a result, he was already well known among free software circles. ) After learning about then-license of Qt, he completely switched views, said things that were in DIRECT contradiction of what he said months before that about KDE. He literally went from being one of KDE's biggest supporters to one of it's biggest enemies overnight. Later on, he talked about making a desktop that was based on the Scheme (!!) programming language. This eventually became GNOME.

Norbert Warmuth became a co-maintainer for the program in 1997 and 1998 as Miguel de Icaza became mainly public spokesman of the Gnome project. It looks like based on his successful mc experience he decided to make career porting to Linux other DOS/Windows originated software, starting with Microsoft desktop ;-).

It was Norbert Warmuth who produced the last stable version of mc, version 4.1.35, the version that later because the base-version for forks in the "overcomplexity revolt", when Miguel de Icaza drove mc development into the "Microsoft File Explorer imitation swamp".

Version 4.1.35 was released in June, 1998 and can be considered as a local peak of the mc development effort followed by a long slump.  The team of developers included 10 names ( Andrej Borsenkow, Radek Doulik, Ching Hui, Jakub Jelinek, Janne Kukonlehto, Fred Leeflang, Mauricio Plaza, Dugan Porter, Paul Sheer and Norbert Warmuth).

In October 1999 Miguel quit his job and moved to USA to participate in the IPO boom, the fact that was promptly reflected on Slashdot ( Slashdot Miguel de Icaza Quits Day Job). Here is the initial info from Miguel diary:

Here's the full diary entry... (Score:3) by kip3f (kip.acm@jhu@edu) on Tuesday October 26, @03:11AM (#1587083) (User #1210 Info | http://www.acm.jhu.edu/~kip/)

October 25 OH MY GOD! I have not updated this page in ages. Crazy stuff. So many things have happened since the last time I wrote stuff: My university is still packed with idiotic students. This time the striking students have decided what can be researched and what not, depending on whether it is helping "imperialists" or the "population of mexico". Someone described this as facist. The first time someone uses the word facist correctly. I went to Boston and to Atlanta (for ALS). We got a secret investor firm to invest in our supper-dupper free software company to develop free software and provide kick-ass applications for users all around the globe. So, I am quitting my current job and moving to the US to pursue this new venture with my friend Nat. Exciting times.

As Miguel got involved  in his  "Microsoft on Linux" vision with the Gnome playing the prominent part of it, he was trying to use his previous (and only) successful project as a leverage, but in a very strange way. I think that mc development went in a wrong direction largely due to IPO-inspired change in Miguel de Icaza priorities: while it was nice to adopt MC as a standard Gnome manager, and even to create a GUI version of it, paradoxically Miguel did not want to develop an OFM-style GUI-based file manager. He just wanted to  "Microsoftize" mc by emulating File Explorer, a very weak file manager indeed. As I mentioned above that was the move that almost killed mc. Moreover even at this point the weaknesses of Miguel de Icaza as a project manager became too evident: the codebase was huge and poorly documented. No architecture-level description of mc was ever written. Like many initial authors of other open source application he just was unable to keep up with his grown child.  Objectively, he just needed to be replaced anyway, independently of his new Gnome hobby. 

Microsoft File Explorer emulation in GUI version of mc led to the situation when Gnome version of mc (gmc) was looking very different from the console version. There was actually no valid reason why it should be called by the same name, when it exhibits almost none of traditional OFM functionality. In no way it was a "Commander". Despite claims that the stability is improving it actually deteriorated to the level when it became a big problem for users.  Situation with the quality of the codebase was even worse. Still announcements remains pretty brave and optimistic as you can from the announcement of "hybrid" version 4.5.4:

• Internationalization support! As part of the GNOME effort French, Korean, Italian, Russian, Spanish translations are available.
• Editor support syntax highlighting (really work nice);
• History on all input lines;
• A lot of VFS improvements: better tar support; better ftp support (reget support is here!); more ftp sites are recognized.
• New GNOME edition. The Midnight Commander is the default file manager for the GNOME desktop environment (http://www.gnome.org).
• Better error handling; Small improvements; consistency; and stability.
• Colored directory listings by file type;
• cleaned up the widget usage in the code;
• bzip support;
• security fixes (/tmp race conditions), etc.

In reality both the development direction and the quality of the architecture were lost. The absence of high level documentation created pretty high barrier of entry for new developers. The codebase turned into a huge mass of uncommented C-code hacked together by many different people without a proper central control, architecture and style enforcement.  A lot of code was not extensible and things that need to be parameterized long ago (for example keystrokes) were still hardwired. All that led to a situation when making even trivial changes to mc became not so trivial undertaking. There were also places in the VFS code that were written without any thought of security.

Still despite putting the project in such a trouble, personally Miguel de Icaza enjoyed a phenomenal personal success due to pretty shrewd playing of his Gnome card: in the end of 1999 he even got the second Free Software Foundation Award for the Advancement of Free Software. It was a rather controversial decision by RMS, to say it mildly,  because the other finalist was Donald Knuth This decision actually served a bad advertisement for RMS himself: it looks like RMS and Miguel decided to replay a typical script from the Internet boom kickback's page.  FSF accepted generous donations from Eazel; at the same time Miguel de Icaza , an Eazel's co-founder (with Andy Hertzfeld and Bart Decrem) was sitting on the board of directors of the Free Software Foundation.  See FSF fiasco with KDE Jihad: support of Gnome rose serious question of conflict of interests. Anyway, here is the part of the announcement:  

New York, New York - December 15, 1999 - The Free Software Foundation (FSF) bestowed its second Free Software Foundation Award for the Advancement of Free Software on . The award, a one-of-a-kind handmade quilt, was given to the 27-year-old Mexico native for de Icaza's excellent work on the GNOME project. The ceremony was held in conjunction with The Bazaar, an EarthWeb event currently taking place at the Jacob Javits Center in New York City.

de Icaza headed a team of more than 300 programmers worldwide, most of them volunteers, in the development of GNOME. GNOME is a user-friendly graphical users interface (GUI) and programming platform for GNU/Linux. GNOME 1.0 was first released in March, 1999 and has since had a step-up release.

"Miguel's efforts have done a great deal to bring the free software model into the mainstream," Peter Salus, chairman of the Free Software Foundation Awards Committee said. "The GNOME project enables a new generation of computer users to access the power of GNU/Linux."

From the end of  2000 it was clear for everybody that the decision to imitate Internet Explorer undermined the project to the extent that the project is doomed. Web site (www.gnome.org/mc) was not updated since September 2000. Here is a pretty typical quote Mc down the drain

From: "Marc" <mphaan@hotmail.com> Date: Mon, 18 Sep 2000 15:40:54 +0200

Where is Midnight commander?

I managed to download some old tar files but now there is no documentation. The link called "documentation" on the MC
site brings you to a website where documentation of some software group is managed.

Why isn't MC kept simple like it used to be? Wasn't that one of the success factors of this piece of software?

Why is there not a simple procedure on the MC site that explains where to get it and how to install it even though the
redirected links are there?

Last question. What simple filemanager for the HP UNIX 10.20 could I use, where to download and how to install?

Mac

Re: Mc down the drain

From: Michael Schmidt <mschmidt@fh-koblenz.de> Date: Tue, 19 Sep 2000 08:13:41 +0200

On Mon, Sep 18, 2000 at 03:40:54PM +0200, Marc wrote:
> 
> Where is Midnight commander?
> 
[...]
> Why isn't MC kept simple like it used to be? Wasn't that one of the success factors
> of this piece of software?

My personal point of view is that a few people have put too much graphics tittle-tattle and too much feature tittle-tattle into mc, 
would have been much better to stabilize mc's runtime solidity. 

> Why is there not a simple procedure on the MC site that explains 
> where to get it and how to install it even though the redirected 
> links are there?

Don't know, perhaps certain persons do not like that for any reasons.
Sorry, but one may get this impression.

> Last question. What simple filemanager for the HP UNIX 10.20 
> could I use, where to download and how to install?

The mc version I have compiled under HPUX-10.20 and which runs here 
until today without known problems is mc-4.5.33.
Feel free to get the sources tarball from our site at: 
ftp://ftp.fh-koblenz.de/pub/gnu/mc/

A historically interesting log of mc bugs for this period can be found on Debian mc page.  Some of them were pretty nasty:

I have found something, which I thing is a bug in the midnight commander.
If I set chmod of  a file to 222, and later try to open it with the internal
editor (F4), there is a message that reading was not successful  and contents of
a file is wiped. I use  mc-4.5.55-7mdk on mandrake linux 8.2. It is rather rare
case, but can cause losing data. 
                                  with regards  Ireneusz Dybczyński  

I do not understand why it was necessary to cripple mc when there was a competing and highly visible project to create a GUI based file manager for Gnome (Nautilus aka "Windows Explorer on steroids"). Nautilus has a manager that was tremendously over hyped and enjoyed huge financial support (which does not prevent the Eazel that Miguel de Icaza co-foundered from folding in May 2001, not even being able to finishing Nautilus.)  Here is one (Dec 31,2001) review of the product: 

Nautilus is a next-generation GNOME file manager from the folks over at Eazel. I've been hearing a lot about Nautilus lately, and I was curious to see what all the hype is about. This article covers my experience installing and running Nautilus. The impatient can bypass my obtuse rambling and skip straight to the summary.

Before I begin, I should mention that I am biased. I was a contributor to EFM, and I am an active developer for the next version of Enlightenment. On the other hand, Eazel has a lot of talent on their development team, so they should easily be able to take file management to the next level and impress an old-school Mac zealot such as myself.

First of all, the automated installer is very similar to the one provided by Helix GNOME; in other words, it absolutely sucks. It "recommends" you download the installer script to your /tmp directory, cd to /tmp, then run the installer script. If you try to do anything tricky, such as run the installer script from a directory other than /tmp, or run the script as root (as opposed to the "recommended" method of running as as a user and letting the script run su), the installer script bombs out completely. The Helix GNOME installer gets points for allowing you to customize how much crap to install; the Nautilus installer doesn't give you any choice at all. So what if I have a recent Mozilla nightly build? According to the Nautilus installer, what I really want is the M18 RPM. Oh yeah, the Nautilus installer told me I had an obsolete version of Gnumeric and proceded to remove it. Unfortunately, it couldn't find a more recent version, so now I have no Gnumeric. Thanks Eazel! I appreciate how GUIs and desktop environments remove the underlying complexities. Nautilus and Helix GNOME have managed to eliminate the particularly pesky ones: configurability, adaptability, and common sense.

... ... ...

Summary

The Good:

• If you're currently using GMC, Emacs, or a wet paper bag as your file manager, Nautilus will be an improvement.
• If you have ludicrous amounts of RAM, Nautilus will finally allow you to test that swap partition.
• Eazel has a neat looking logo.
• Dumb people who listen to the hype on Slashdot and try to use Nautilus will now be operating at a quarter of their previous speed.
• Zooming to 400% in order to read text files is much more fun than typing head in an open term.
• You can install KFM now, and EFM will be out within two years. Also, bash is just a terminal away.

The Bad:

• There doesn't appear to be a way to turn the goddamn toolbar text labels off.
• Modem users may feel inclined to attack the Eazel developers with rocks and pointy sticks after wasting an entire evening downloading this piece of crap.
• Contrary to popular Redmond lore, A million cryptic configuration dialogs does not make a usable program.
• GNOME is going to ship with Nautilus eventually.
• The Eazel installer does not deserve the right to remove my old, stable software (eg Gnumeric) and replace it with nothing.
• The Nautilus download page requests an email address to spam in order to download their bloatware. They will get spam complaints from the people using eat@me.com and suck@it.net.

Nautilus is, as Tom Gilbert puts it, all about well implemented dumb ideas. Sure, they've got CORBA, gdk_pixbuf, and GNOME integration, but none of these things matter if using Nautilus makes me want to punch my monitor. In order to succeed, both Eazel and GNOME need to realize the Free Software movement isn't about making a better implementation of Microsoft's shoddy computing interface...

There was some understanding that the situation with gmc and mc is not sustainable. See for example an interesting suggestion to merge GUI version with terminal version by Pavel Machek, who proposed to run "gtk on curses" (see  Cursing gtk).  Theoretically this is an interesting idea, but in reality it never fly because gtk is just too generic for the text interface, unless you try to re-implement Borland Turbo Vision. But that was the only attempt to bridge the growing gap between classic and GUI-based OFM coding.

The first brave (and successful) attempt to save the project was made in December 2000 by a talented Hungarian programmer Arpad Gereoffy (of MPlayer fame). He decided to create a bugfixed, stable derivative of the version 4.1.35 as opposed to overcomplicated 4.5.x source tree. It added the following features (the quote below was taken directly from the version announcement):

This is a bugfixed and enhanced version of the Midnight Commander 4.1.35. FTP is nearly rewritten, many small bugs are fixed, and some interesting features added, for example:
- Better syntax highlighting in editor
- Allow file/dirsize to be > 2GB
- FTP supports FXP (direct server-to-server connection)
- FTP transfers without copying to TEMP
- Fixed ZIPfs, added ESP support.

• Download
• About:
  The goal of this project is creating a stable, well-working, useful version of well-known Midnight Commander, without bugs. I'm bored waiting for bugfixes, so I did it. I'm fixing all bugs reported by my friends, or by YOU!

Why is it an alternate version of mc, instead applying patches to main mc project? The original mc is now about v4.5.49, with more and more bugs, and some very bad structure changes. I like mc 4.1.x series much better, it has well-designed structures, easy to add new features. Maybe I'll port these changes to 4.5.x series, when it gets stable. Btw. I back-ported all new useful things appeared in 4.5.x.

That probably created some excitement in the "remaining developers" of the "official" version of mc. Later in May 2001, even more brave attempt to restore the original roots of the program was made by Pavel Roskin, who decided to return the mc to its original roots without abandoning of the 4.5.x codebase. Actually this move was approved by Miguel himself, who after discussion with Pavel wrote in his May 2001 letter:

I met with Pavel Roskin this weekend (the joys of living close to each other) and we discussed a bit the future of MC, here is more or less what we talked about:

* In about a week I will branch the module "mc" in the CVS repository. The branch will keep the GNOME code, and the HEAD branch will drop support for GNOME and fully deprecate tk and xview (they were already, but there is some cruft here and there that needs to be removed).

* MC has accumulated some bad code over the years that we would like to clean up at some point. At this stage our objective is to go for maintainability and cleanliness in the source code to encourage people to contribute.

Part of this is dropping entirely the multi-"frontend" support that we had. Another part will be cleaning up after the mess we have done in a few spots (vfs has a few "interesting" pieces as well as some of the older code).

This cleaning of the codebase was a non-trivial job to do, taking into account level of the deterioration of the code and all GUI-related, age-related, and multiple developers-related warts in the mc source. Not many developers survived "gmc/File Explorer" phase of development. I would especially note Andrew V. Samoilov who joined Pavel in saving the project. To give you some insight about the problems here is a relevant quote from Pavel's letter (mc-devel gnome org, 15 May 2001):

I have fixed most warnings in the MC source. Many of them were trivial. For example, a variable was declared, but the code where it's used was commented out. Now that variable is surrounded by ifdef..endif with the same condition.

It also turned out that a lot of code that is compiled for GMC is not used. I removed the functions that caused warnings, i.e. they are declared but never used.

I also wrote a simple analyzer of the link map and found that several files in the "gnome" directory don't supply any functions or variables to the linker. Some of those files had modification dates in 1998. Those file have been removed.

I haven't done any analyzis on the function level (it's possible too). The warnings concerning SLang and signal handling are left for a while. It will be easier to clean them up after the text-only branch is created.

Pavel also resurrected the website and moved it to http://www.ibiblio.org/mc/ Actually his work on removing gnome code was started after the release of v 4.5.55 (the last version that supported mc/gmc hybrid):

GNU Midnight Commander 4.5.55 has been released.

Development of the GNOME frontend will continue on the stable branch only: "Branch_MC_4_5_x". All GNOME support will be removed from the head branch in the next few days.

NEWS:

- Mostly bugfixes and portability fixes.  Making things work as they were meant to work.

- Text edition improvements. - Ctrl-O supported in the viewer and editor. - Better terminal support. Should not need "Learn Keys" on rxvt and xterm in most cases.

- GNOME edition improvements. - Find dialog rewritten. - Editor and viewer ask whether to save modified file when closed from window manager.

- Editor. - New syntax rules - S-Lang, PO files, Octave. - Alt-B goes to matching bracket.

Version 4.6.0 that was the first "after-Gnome" version of mc that can be called stable (on Linux). In addition to removal of graphic interface, and the code was somewhat cleaned. This was a very timely step that probably saved the product. There were also some minor, but nice refinements. For example, the text editor in this version remembers the last edited line and reopens the file with this fragment. A nice feature for any lightweight editor. The current directory can be displayed in the Xterm header. Pavel also answering most of the questions in mc users and mc development list and the traffic noticeably increased.

Although the version 4.6.0 seems to be more or less stable, but due to the past problems with the 4.5.x tree and the fact that 4/6/0 still uses glib, some developers continue to enhance version 4.1.35-based fork that still survived as a fork of the codetree despite the existence of 4.6.0. A fork of 4.6.0 codebase Advanced Midnight Commander  (AMC) also emerged:

A'rpi previous work on 4.1.35 was picked up and moved on the Sourceforge by Oleg Konovalov under the name Midnight Commander 4.1.X-MP. The latest code snapshot is mc-4.1.40-pre8.tar.gz dated Sept, 2003. The codebase size is approximately the same as in 4.6.0 (both are ~1.4M is Scr directory; I excluded mc.hlp in case of Amc and changelogs in case of mc), so it looks like is no big difference in the size of the codebase  (parameter, which is important for developers if, for example, one version has at least 20% advantage over the other).

Midnight Commander 4.1.X-MP should be more portable.

Here is how Oleg described his project:

Midnight Commander 4.1.X-MP

The goal of this project is creating a stable, well-working, usefull console-only version of well-known Midnight Commander, without bugs and garbage, like tk, xv and gnome. I'm bored waiting for bugfixes, and A'rpi's ESP team stops their work in this direction too, so I did it. I'm fixing all (found) bugs, reported by my friends, and made some really pleasant new features, like real-time clock, or file groups colorizing.

Still the development of 4.6.0 remains the main branch that is used by various distributions and absence of large discrepancies in the sizes of the codebase make the forks future problematic, unless they can shrink the code base. Essentially with the equal size of codebase they face uphill battle with the 2.6.0 and despite resentment that many feel about the usage of glib it might be better to join efforts and to discontinue the fork. Another factor that strengthen mc 4.6.0 position is that Pavel Tsekov released mc 4.6.0 for Cigwin (see Index of -release-mc), that proved to be usable:

The Midnight Commander visual shell has been updated to version 4.6.0a-20030721-1 .

This release will _NOT_ work with versions of Cygwin prior to 1.5.0 .

Along with the ability to work with large file this new version will bring you a lot of bug fixes and some exciting new features. This release is based on the CVS codebase as of 21 July 2003.

A list of some of the visible changes follows:

* The ministatus bar is redrawn if a search invoked by M-s or C-s was canceled.

* The 'Free VFS now' menu item was removed. The functionality can be accessed now from 'Active VFS list' dialog.

* Treat Shift-Backspace as Backspace.

* Add backward search support to the internal viewer.

* Some fixes to the ftp VFS.

* Emacs style file locking support for the internal editor.

At the same time the usage of glib proved to be a really hot point among the developers and its continued use by Pavel generated quite a lot of resentment. As one developer mentioned " ... I've been using mc (except >=4.5) for about 7 years without glib dependency, and I see not a single reason to just let that dependency occur, or evolve to a higher degree."  As I noted before, a considerable number of developers view glib as "Gnome crap":  an artificial link to Gnome project supported by  Miguel de Icaza despite of the interests of the mc community.

In my view this is more connected with Pavel's inclination to move to a higher level language (C++) as a development language. C++ with its OOP features and STL is definitely a better, higher-level language for writing filemanager or other dialog intense applications; actually writing interfaces was always the main application area for OOP. Glib can be (to a certain extent) viewed as STL-style crutches for C:  an attempt to emulate some part of C++ standard library (for example lists)  in a regular C. But you cannot be half-pregnant and adopting glib essentially position a developer between two chairs. Alternative approach would be preserving C as a developing language and adding a scripting language support (even S-lang, that mc currently uses only as an interface library). That approach might provide better return on investment then half-move from C to C++ typical for Gnome project in general. Moreover glib-based path of development is not without problems as for the complexity (especially with glib2) because like STL it adds another layer of indirection, the layer that makes understanding of the program internals dependent on the knowledge of glib.

All-in-all it looks like it was due to Pavel's support glib connection survived "disengagement" of the mc community with Miguel de Icaza.

The version 4.6.1-pre1 further improved the stability, but was postponed till December 2003 due to a break-in in Gnu CVS repository savannah.gnu.org/ in early November (compromise was discovered Dec. 1, 2003 and Savannah was back online Dec 23,2003, but a known good backup was dated September 16.  See more details on savannah.gnu.org/) a lot of patches were lost. For this and other reasons only 4.6.1-pre1 was released in later 2004.

After that Pavel Roskin  was unable to continue active development for personal reasons and the next prerelease 4.6.1-pre2 was created only at the end of 2004.  Like in many other projects when the maintainer "disappears" without officially relinquishing his responsibilities the project stagnates. So after "saving" mc in 2002-2003 Pavel essentially sank in 2004-2005.

What will happen with mc next remains to be seen.  

MC advanced features and contributions to the field

• The best naming system for macro substitution symbols in OFMs, much better then in original NC (with or without VC/FAR enhancements). It should become standard in all OFM implementations:
• %f The current file name.
• %F The current file in the  passive panel.
• %d The current directory name.
• %D The directory name of the  passive panel.
• %t The currently tagged files.
• %T The tagged files in the  passive panel.
• "%u" and "%U" Similar to the %t and %T macros, but after the operation all the files are untagged (can be used only once per menu entry).
• %s and %S The tagged files if there are any. Otherwise the current file.
• %cd This is a special macro that is used to change the current directory to the directory specified in front of it. This is used primarily as an interface to the VFS.
• %view the invocation of the internal viewer
  
• "%%" The % character
• "%{some text}" Prompt for the substitution.
• "External panelize" command (executing an arbitrary command and putting the resulting file listing in a panel, so that it can be used for navigating. This was really great idea that was still never implemented in other OFMs. MC implementation need capabilities of hiding full path like in FAR.
• 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 was probably the first implementation of TCP/IP based link (master-slave connection over TCP/IP).
• Implementation of "visibility predicates" in the user menu. MC pioneered concept of context-sensitive user menu items. Each item has it's "visibility predicate" which determine conditions under which the this item will be displayed in the menu.
• Advanced implementation of user selection with the ability to dynamically assign external Editor and Viewer. Both can be assigned depending on the result of a predicate (or even script) evaluation.
• Command completion in all dialogs. That's really highly helpful feature for advanced users.
• Implementation of command console interface. Probably the first "Ctrl-O" (shell output window view) support of Unix console. Addition of path from the left and right panels (Ctrl-[ and Ctrl-]) were implemented as Ctrl-X P and Ctrl-X P. Pasting the file name (Ctrl-I) is Ctrl-X T. There is also a hotkey for active panel directory path Alt-A and for quick cd command.
• Full power of regular expressions in selections, for example the list "*.txt; *.bat; *.inf; *.doc" can be specified as "*.(doc|bat|inf|doc)".
• One of the first implementations of FTP VFS.
• RegEx-based search capabilities. Like in NC5 XTree VFS can be emulated using panelize command, but without macros this emulation is pretty painful.
• Dynamic construction of the directory tree. The idea itself is rather interesting taking into account the real height of directory tree that we see in Red Hat and other Linux distributions with Gnome installed. But unfortunately the existing implementation breaks OFM doctrine as the tree is build from root, not from the current directory and that somewhat limits its usability for quick search of files and navigation.  The directory tree expand/collapse should happens automatically in the vicinity of the user view on the tree. Currently you need manually use F2 (rescan) to open the branch that interests you.  Still the problem here is the cost of full scanning of the tree in a typical unix system.
• Configurable display information (you can select your own directory display format) and the circular ring of predefined display formats switchable via Alt-T.
• Synchronizing the directory on the passive panel with the directory on the active panel hotkey (Alt-O)
• Attempts to provide some hotkeys for working with the current directory. Jumping to the top file, middle file and the last file on the panel are provided (only Alt-G (the top) and Alt-J (the bottom) actually work now); That can be extended to potentially more useful jumps to the top subdirectory, middle subdirectory and the last subdirectory in the current panel (often there are only two or three subdirectories; in this case those three keys select subdirectory unambiguously).
• Pressing F3 in viewer exits the viewer. That seems to be a minor thing but this feature proved to be very useful and I recommend it as a standard key binding for viewer in any OFM.
• Dynamic Toolbar. MC 4.6.0 is probably the only Unix OFMs that supports the consent of dynamic toolbar (in Viewer, Editor, and Directory Search panel). Dynamic toolbar is a very useful instant help system and should be used whenever possible. Unfortunately, the key bar doesn't change when Alt, Ctrl, or Shift are pressed like in FAR. It's probably hard to implement it in a portable way in Unix with its limited PC keyboard support.
• The viewer supports "/" and "?" for regex search, the hotkeys that are standard for many Unix utilities (vi, less, etc).

Some of the enhancement are Linux specific, but still important. Among them I would like to mention undelete (works only on "ext2" file systems on Linux, and even there, the code inside the kernel limits the range of files that can be successfully undeleted) This operation is generally very difficult to implement on most Unix systems, and AFAIK MC is the only program that really tries to do something in this area, within the limits imposed by the kernel..

MC shortcomings and deviations

Please note that with all its shortcomings MC is still one of the best Unix command line OFM available. But of course there are shortcomings and as this is an open source program I hope that some readers might help to fix them:

• Integration with shell and windows management capabilities are extremely primitive for a Unix OFM and are worse then in NC 2.0. Strangely enough the capabilities of OFM as specialized window manager somewhat similar to screen were never understood by the development team. Although mc went farther then most Unix OFM projects and provided support for the Ctrl-O operation (hide panels and expose shell screen) they never managed to enhance it to usable status -- there is no way to shrink panels to see part of terminal screen (the "half screen" capability and the capability to hide each panel individually  is present in NC line since the NC 2.0).  This limitation extends to the editor and taken together they severely limit the usefulness of MC in debugging shell and Perl scripts.
  
  Also while we can accept dependency on bash as the necessary evil, the level integration with shell is extremely primitive.  There is no ability to panelize shell history, environment, almost nothing. As if people who wrote mc use Windows as their development platform.
   

• Inflexible visual interface. Generally interface is much less flexible then in FAR. Among most visible problems are:

  • There is no ability to sort/resort columns of panels with a mouse click on the title
  • The built-in editor cannot be minimized to one panel and works only in full screen mode
  • Key panel elements (current file on active panel, the current file on passive panel, path to active panel, path to passive panel, highlighted files on active/passive panel, etc) are not exportable to the editor.
  • Panels are "non-shrinkable" and non-resizable asymmetrically sized panels possible in FAR are impossible in MC). This is very important in Unix as such attributes as ownership and rights require a lot of scarce and are more important on active panel then on passive. 
  • Implementation of history is inconsistent and does no encompass all menus.
   
• Panel navigation:
  • Xterm-related key-binding problems make the set of keys that works on a particular Xterm rather fuzzy and highly dependent on the level of understanding of X Windows environment. . For example with good luck you will have Ctrl-PgUp and Ctrl-PgDn working (for getting to parent /child directory, respectively). But there is some suspense in this area too as I have two RH8 system with one that displays normal behavior of Alt-Tab and the another that does not. It may be a problem in Xterm that I used (documentation states that they should work at least on console) and anyway, one can compensate for that with Lynx-style navigation when those functions are performed by left arrow and right arrow respectively (but Lynx solution is error prone: if you accidentally hit Left or Right instead of Up and Down the results are not pleasant.
  • Mouse support for resorting is absent (see below)
    
• Viewer:
  • While you can view the next and prev. file, you can not view the next selected file (or prev selected file) using:
    • Ctrl-F Jump to the next file.
    • Ctrl-B Jump to the previous file.

    It looks like version 4.6.0 has a bug and the next file in the panel and the prev file in the panel are shown even if there are selected files in the panel.
    

  • There is no way to invoke the editor from the viewer and vise versa.
    
  • Viewer does not support bookmarks like FAR and percentage based offsets.
    
• Editor:
  • Tab/Shift-Tab does not works for blocks, only for single lines.
    
• Working with links is possible only via File menu and is rather clumsy and somewhat "unUnix". The possibility of creation of links should be an option of copy and move operation (F5/F6) and they can be made available, say, via Shift-F5/Shift-F6 for softlinks and hardlinks respectively: the creation of the links can be considered to be a variant of the usual "copy/move" operations.
  
• Directory tree semantic is incomplete (and partially incorrect) in both tree panel and the Directory Search panel. That might a low priority item (although quick traversing of directories is definitely useful for most users), but still, the correct Directory tree semantic should be as following:
  • A regular tree panel. In this case tree replaces the passive panel Tree panel should work in three modes:
    • Quick view mode in tree traversing ("dive into the directory mode") Switchable with Ctrl-Q. This mode is similar to the behavior of Windows Explorer movement of the cursor opens the directory under the cursor in the opposite window. Mostly used for quick traversing of the directory tree in a mode similar to quick view with directories opening as we move the cursor (quick diving into subdirectories). Quick search should be available. No such mode exists. Navigation is limited to cursor keys and Enter. Quick search is available but the is no capability to find the next directory with the same prefix.
    • The default mode: The cursor can be moved independently and does not affect the opposite panel. Pressing Enter opens the directory under the cursor in the opposite panel. Copy and Move operations from the opposite panel are targeted to the current directory on the tree.
    • Information mode (Ctrl-L). Similar to quick view mode. But in this case the movement of the cursor on the tree panel opens not a listing of files in the directory but the information window should be shown that calculated statistics for the directory (number of the files, total size, number of subfolders, attributes, owners, etc).
  • The directory search panel. This panel should instantly provide a quick search window and usually in bound to Alt-F10 and should be available in copy/move dialogs via F10. This is not the case in mc (you need to press F9-C-D and then Ctrl-S to activate quick search mode). Copy/move dialogs (via F10) functionality is planned for a future version (currently it is in TODO list).

  Hotkeys:
  

  1. Tree panel
     1. In tree panel usual keys can be using for moving the directories to the opposite panel.
     2. Regular copy/move keys should also work from the regular panel if tree panel is the target. In this case the target directory is the current directory on the tree panel.
     3. Delete operation should work on tree panel.
     4. Movement of the cursor on the panel with tree representation should not lead to change of the directory on the current panel unless Ctrl-Q was additionally pressed (quick mode activated).
     5. Ctrl-Enter should paste the current directory in the command line is regular mode and move to the next directory with the same prefix (or the next directory with the same name is search prefix is empty in Quick Search mode.
        
  2. Quick view tree navigation:
     1. Invocation of Ctrl-Q on tree panel should lead to quick mode of navigating the tree -- changing tree in one panel should make current (highlighted) directory current on the second (passive) panel.
     2. Ctrl-Enter should jump to the next directory with the same prefix. If there is no text in the quick search window quick search mode should find the next directory with the same name, if any.
     3. Rescanning of the directory tree should be available via Ctrl-R and/or F2. Pressing Alt-F10 should not produce rescanning of the disk without reason.
        
  3. Both Tree panel and Directory Search Panel
     
     1. Backspace should move to the previous level of the directory tree.
     2. Gray+, Gray- should also move up/down to the next branch on the same level one level of the tree.
     3. Quick search should be activated for tree panel on invocation .
     4. Ctrl-PgUp/Ctrl-PgDn should work as usual on tree view.
  • I would like to reiterate my earlier discussion of the productivity of power users from the Chapter 1

    The idea of Alt-F10 as a instant third panel with the Directory search view (tree view) of the current disk (or mountable filesystem) is a very powerful and useful solution for a lot of typical file manipulation problems. The key word here is that it should be instant. Any scanning like in MC kill the idea. For example in FAR I almost never use tree representation of the second panel to navigate the directory tree, I use it for mainly for quick browsing. To navigate the tree I automatically invoke tree view of the current panel with Alt-F10 and navigate to the necessary directory on it

• Header and information line. Unlike the best OFMs (for example Total Commander and Norton Commander for Windows) columns headers at the top of the panel are not mouse-clickable (click on any column title should change the sorting order of the directory to this particular attribute.)
  
• Separate hotlists for left and right panel are not accessible via Alt-F1/Altl-F2. Keystrokes Alt-F1 and Alt-F2 are reserved by the Xterm keyboard driver, but one can deselect them in Gnome, so it is possible to use them the way Dos/Windows OFMs are using (for the change of the "drive" in the left and right panels: directory history is probably a reasonable approximation of drives). For any long time OFM users many motor skills are bound to this particular combination to be comfortable with something radically different. Of course one can consider favorite directory list (Ctrl-\ in MC) to be semantically a kind of replacement of logical drives for Unix, but still the choice of the hotkey is not that great. I think that it's more convenient to use Alt-F1, Alt-F2 hotkeys for viewing iether histories of left and right panel or the favorites.
  
• Better utilization of the information line at the bottom of the panel might be beneficial. Click on the information line should invoke the selection with the extension of the current file. Click on the target of the link should change the panel to the target path. Other similar possibilities to use information line may also exist.
  
• 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...)

  This problem is one of the side effects of the open source development that is biased toward power users on a particular platform, so it looks like this defect is pretty much generic and not limited to MC. And yes, there are two major groups of MC users:

  • administrators and power user with strong Unix background and motor skills
  • novices and "accidental" users with strong Dos/Windows background and mainly Dos/windows-based OFM motor skills (although that does not necessary means that they do not know Unix commands on advanced or "power user" level -- for example I know Unix shell, Awk and Perl on a pretty decent level -- some of them just have motor skills from Dos/Windows environment)

  Therefore there should be at least two key maps. Now, as for key assignments, MC serves more or less satisfactory only the first group. But even for them the choice of some key combinations is questionable (Ctrl-\). IMHO the only way out of this problem is to implement key reassignment mechanism and to provide the possibility to switch to different bindings in MultiEdit style. Even just two keymaps would probably suffice (UNIX-style keymap and PC-style keymap).

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, FOCUS FK-9200, or MCK-142) or use Expect.

MC codebase

Despite some progress achieve in moving from 4.5.55 to 4.6.0, the codebase remains in an  undocumented, messy state.  Like many other open source projects MC suffers from the absence of architectural blueprints.

Years of neglect of project documentation are quite visible: there is no any high level documentation about the structure of mc and interaction of different functions. Not even a manifest file that lists function of each file. All I found is a small note Doc/DEVEL  called "the developers' hint guide" that in 120 lines tries to communicate some requirements for the contributions.

It's interesting that Miguel actually is very prolific writer that maintains his own blog. Also it looks like at least judging form his statements he seems to be a advocate of componentization. He once stated that:

The real benefit is greater code reuse. "Code reuse is a big problem in the Unix environment," added de Icaza. He details this argument in his well-known article: "Let's Make Unix Not Suck."

"The problem is that we are not re-using enough code across all the applications in UNIX," he said. "Everybody is reinventing all the little pieces."

He even undertook a Herculean task of reimplementing Microsoft .Net in Linux environment.

But that completely contradicts his own practice in mc: in mc code C-coding conventions even on the primitive level recommended by the Part 5. Making The Best Use of C of the GNU Coding Standards are not enforced. Elementary self-documentation tricks like "the first line contains the comment that explains the purpose of the function" are missing.   No attempt to use Javadoc-style documentation scheme is visible other then in a couple of functions that use /* {{{ */  and  /* }}} */  metabrakets to delimit some parts of the program.   But that's about it. Some functions are not even properly indented. So the project that he started can serve a convincing demonstration of neglect for each and every principle that he proclaimed :-).

There are 63 C functions and 58 header files in the main source directory (Src) of the mc 4.6.0 distribution. That does not include the editor (11 C files + 4 header files), slang interface and some functions.

A historically interesting log of mc bugs is maintained by Debian.