Less is More: The Orthodox File Manager (OFM) Paradigm

by Dr Nikolai Bezroukov

Content : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : OFM1999 : OFM2004 : OFM2012

History of development of Midnight Commander

• Introduction
• Historical notes
  • Janne Kukonenko period
    • Version 0.14
    • Version 2.0
    • Version 3.0
  • Version 4.1.35 and addition of mcedit by Paul Sheer
  • Miguel moves to the USA and becomes the spokesman for Gnome project
  • MC-gnomegate and first development crisis
  • First forks
  • Pavel Roshkin saves the project
  • Glib controversy and Miguel forced "exile" from the project
  • More Forks
  • The second crisis of mc development
  • Slava Zanko and his team rescue the project
  • The third crisis in mc development (May 2015)
• Compatibility with OFM1999 standard and shortcomings
  • Interface look & feel
  • Navigational and basic hot keys compatibility
  • Shell Window compatibility
  • Compatibility of F1..F12 and other F-keys operations
  • Tree View Panel compatibility
  • Directory search panel (NCD panel or Quick CD panel)
  • Selection/Deselection
  • Quick view compatibility
  • Macro recorder compatibility
  • FindFile compatibility
  • Command line execution compatibility
  • Sorting and filtering file and directories in panel
  • User Menu
  • Additional file commands compatibility
  • Association management compatibility (extensions menu)
  • Compare directories
  • Built-in viewer
  • Built-in Editor
  • Archive virtual file system  
  • History and favorites compatibility
• MC advanced features and contributions to the field
• MC shortcomings and deviations
• MC codebase
• Architectural stagnation -- inability of key MC developers to integrate LUA support developed by mooffie
• Webliography

Introduction

MC is the leading Unix OFM originally written in 1994 by Miguel de Icaza (of Gnome fame/defame, see Jamie Zawinski joke about "Cascade of Attention-Deficit Teenagers" model of development 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. The leading developers changed several times, with two times during the major development crisis: the history of mc includes two important crisis when the product was for some time on life support and it was unclear whether it manage to survive (see Historical notes below):

• 4.1 version crisis -- This was the crisis when Miguel de Icaza almost killed the project when he trying to emulate with it Microsoft File Explorer for Gnome. Pavel Roshkin later saved the project by removing crap introduced by attempt to make it stated Gnome file manager.
• 4.6 version crisis when at some point it looked like the product is no longer developed and became abandonware. It was saved by Slava Zanko and his friends, who released version 4.8 --  a milestone version in mc history that correctly implements command window.

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 custom entries in mc user menu as well as the shell terminal window (other than adopting a different OFM file manager ;-).

Still there is one fundamental problem with mc . While version 4.8 has more acceptable implementation for sysadmin 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 from version 2.0 provided support for the Ctrl-O operation (hide panels and expose shell screen) until version 4.8 it was a pretty unusable -- shell shortcuts did not work and there is no way to shrink panels to see panels simultaneously with multiline terminal screen (the classic "half screen" capability since NC 1.0). Also impossible is to file left or right panel to see vertical slice of terminal screen (Ctrl-F1/CtrlF2) functionality in NC).  That limitation extends to 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. 

Actually version 4.8 improved MC to the extent that I created several pages devoted to it specifically, while working of OFM compatibility test. See

• Midnight Commander
• MC Context Sensitive User Menu
• MC Macro Variables
• Midnight Commander Tips and Tricks
• mcedit
• mcview

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

Janne Kukonenko period

This was the most productive period of mc development during which most of key ideas that distiguish mc were originated.

Version 0.14

Essentially mc became a more or less usable only after contributions by Janne Kukonlehto. Version 0.14 that was released September, 1994 was the first that behaved more like Norton Commander. Later versioning scheme was bumped up by multiplying existing version by ten, so we can see it as version 1.4 too. It already contained new, better then in Norton Commander,  mc naming scheme in user menu with just four macrovariables:

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

 Here is the contents of  user.menu file from this 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

Version 2.0

In 1994-1995 the pace of development was really amazing. The next important and the first more-or-less  usable version (Version 2.1) was released in February 1995, just 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

Version 3.0 was released in September, 1995. This was another milestone in mc development. In this version the format of mc.ext file got to its current form with very useful extension based on "actions". So view is one action that can be defined in this file and can trigger one response, while Edit is another. Pressing Enter is yet another and so on.  The set of macro variables  that existed from version 2.0 supported this idea.

It also contained the initial version of FTP VFS (by Jakub Jelinec) as well as 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 clear that at this point the project reached the critical mass as few open source project have that many active developers (two is already many in open source world).  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. Another sign of the success of the project was that fact that 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 1997 Miguel de Icaza started attempts position himself as a leader of some important project within open source community and essentially abandoned mc development completely while keeping formal leader role.  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.

Version 4.1.35 and addition of mcedit by Paul Sheer

Norbert Warmuth became a co-maintainer (actually he was the the second de-facto leader of the project after Janne Kukonenko 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 his career  by porting to Linux other DOS/Windows originated software, starting with "look&feel" of Microsoft Windows 95 desktop (which was actually not a bad desktop at all ;-).  Unfortunately, in the process he almost killed mc project by organizing was called "mc-gnomegate" (see below) by droving mc development into the "Microsoft File Explorer imitation" swamp.

It was Norbert Warmuth who produced the last stable version of mc before "mc gnomegate", version 4.1.35.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).  This version later became the base-version for various forks in the "overcomplexity revolt" of "mc-gnomegame". 

I would like to distinguish Paul Sheer among this enlarged group of developers. Paul Sheer  was a very talented and productive programmer, who contributed internal editor to the project (mcedit). Mcedit was an editor with several innovative concepts, that can't be found in NC-line of products. One of them was that concept of the block macrovariables (%b) to which you can pipe from external programs and that other was the concept of user menu inside the editor (editor user menu), which provided extensibility and flexibility to otherwise very simple edit. In other words this was very elegant technical solution. This was actually an innovative derivative of the vi "!" command.  

Paul was also the author of Cooledit a X11 version of editor and later IDE. Cooledit has an interactive graphical debugger, anti-aliased fonts, compiler interface, syntax highlighting for a wide variety of programming languages, UTF-8/UCS/Unicode support, Python extensibility, and many more features. Unfortunately the project died from malnutrition around 2005 (last updated 22 Jan 2005 ).  He also wrote a book on Linux system administration LINUX- Rute User's Tutorial and Exposition published by Prentiss Hall in October 12, 2001 (see also version 1.0.0 on his web site).

Miguel moves to the USA and becomes the spokesman for Gnome project

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 software 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. Which is not bad in itself, but he did it in a very strange and counterproductive (I would say architecturally brain-dead) 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 and software architect became 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, to say nothing about much more complex and ambitious project like Gnome.  Objectively, he just needed to be replaced as a formal leader (he stopped contributing anything of value to the codebase several years ago) of the mc-development team 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 an OFM. 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."

MC-gnomegate and first development crisis

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. The project web site (www.gnome.org/mc) was not updated since September 2000. Here is a pretty typical quote

Mc down the drain

From: "Marc" <[email protected]>
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 <[email protected]>
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, which Miguel de Icaza co-foundered from folding in May 2001, without being even able to to produce a a stable release of 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 [email protected] and [email protected].

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 can't fly because gtk is just too generic for the text interface, unless you try to re-implement Borland Turbo Vision. Actually this was  the only constructive attempt to bridge the growing gap between classic and GUI-based OFM coding during "mc-gnomegate".

First forks

The first brave (and successful) attempt to save the project in a tradition way (by fork) 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.

Pavel Roshkin saves the project

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 completely 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 gnome domain 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 project. 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 of the file shown on the screen. A nice, almost necessary,  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.

Glib controversy and Miguel forced "exile" from the project

Due to Miguel de Icaza somewhat blind orientation on imitation of Microsoft innovations in Unix (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 and different in its user interface and semantic OFM manager. This was a huge blunder. 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.  In a process Miguel lost any moral rights for the leadership of the project.

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. Here Pavel made an architectural blunder as the "right way" would be to adopt a scripting language instead of G-lib (such as Slang) which would make project much more interesting them it remained even after Pavel saved it.

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 for purely political reasons, despite of the interests of the mc community in portability and mininal codebase for the project. 

In my view this is more connected with Pavel's inclination to move to a higher level language (C++) as a development language then with the explisit desire to play Miguel de Icaza political game. C++ with its OO features and STL is definitely a better, higher-level language for writing filemanager or other dialog intense applications; actually writing interfaces were always the main application area for OO programming (it was mostly oversold in other areas). 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 (for example S-lang, that mc currently uses only as an interface library). That approach would definitely provide better return on investment then half-move from C to C++ typical for Gnome project in general. Pavel for some reasons rejected this avenue of development. 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.

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

More Forks

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 became reaction to mc-gnomagate and were fed by the resentment with the bloat of the original codebase branch.  

At the same time the version 4.6.0 proved to be more or less stable, so forks did not enjoy absolute superiority over "official" branch.  In such cases it is just a matter of time when they start doing from malnutrition and official branch survive the revolt as it is official version that is included in various linux distribution and this way gets to the mass user. That's what happened this time as versions from 4.6.0 to 4.6.2.pre1 concentrated on stability.

The most notable fork of 4.6.0 codebase was  Advanced Midnight Commander  (AMC):

What is AMC?

AMC (originally Advanced Midnight Commander) is my (A'rpi) branch of the well-known Midnight Commander, with my (and others') bugfix and feature patches applied.

Why ?

Because of merging in my patches to the official mc goes so slowly and as i have lots of small changes what hard to handle as patches/patchsets, i've decided to setup CVS tree for my patched mc-4.6.x tree, so
- users interested in it can easily get & test it
- it's easier to me to commit & trace independent changes, patches
- nice changelog can be generated easily from cvs log
- you can get any change as patch using cvs diff
- i can import & merge new mc releases/snapshots without messing up my patchset

You may take it as a fork (what we both wanted to avoid) but since i'll try to keep merging with official mc cvs, it isn't a real fork, more like a branch.

I'm also planning to apply some interesting patches posted to the mc-devel list by others but refused or not yet accepted/applied.

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 very 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 was included in 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 and provide superior stability. As for stability this did not happen. Essentially with the equal size of codebase they faced uphill battle with the version 4.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 Cygwin (see Index of -release-mc), that proved to be quite usable and provided huge stabilizing influence on the project: 

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.

The second crisis of mc development

After version 4.6.0 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 stagnated. So after "saving" mc in 2002-2003, Pavel essentially sank it in 2004-2005.

In 2006 project looked like doomed. Sudden rescue came from  Pavel Tsekov who became new mc maintainer and actually the key maintainer of Cygwin port.

Hello,

I am writing this message to inform you that Pavel Roskin,
the long time maintainer and developer of GNU Midnight Commander,
decided to step down as a maintainer. I hope that you'll join me
to wish Pavel luck in whatever he pursues next.

The FSF following a recommendation from Pavel Roskin appointed me
as the new project maintainer. I hope that I'll be able to justify
their trust and live up to the expectations of MC's users.

Pavel Tsekov

After mc-4.6.2-pre1.tar.gz   the development stalled completely and in 2009 the project looked  dead. Here is Slashdot take on the situation in 2009

Midnight Commander Development Revived - Slashdot

"Popular Unix console file manager Midnight Commander has experienced a stall for the last few years. Most distributions (including the conservative Slackware) shipped patched packages or snapshots. Despite that, everybody had a favorite bug or two — either inability to specify ssh connection port, or problems with interrupted FTP sessions. Or maybe copying of larger datasets. Or maybe the infamous 'shell is still active' message, which often brought unexpected changes of current directory with it. Whatever it was, we either cursed it every time, or learned to live with it. It seems that finally something many were waiting for has happened — there's some activity on mc development. Check out the new homepage, and let's hope revival is both healthy and lengthy."

Reaction of Slashdotters revealed along with amazing ignorance (OK, this is Slashdot ;-),  some interesting tidbits:

great for patch work (Score:5, Interesting)

by nevets (39138) writes: on Monday January 26 2009, @05:09PM (#26612777) Homepage Journal

I love mc!

I use it all the time for patch management. One little tidbit that most people do not know about mc is that you can cd into a patch. Edit the diffs in the patch, and copy a diff from one patch to another patch file, just like copying or moving a file.

Re:Norton is going to be pissed... (Score:0)

by Anonymous Coward writes: on Monday January 26 2009, @06:44PM (#26614417)

Konqueror supports all the keystrokes that are in MC?

meta-control-? :: search for files by regexp contents
plus/minus :: mark files
f5/f6 :: copy move
shift-f5/shift-f6 :: local copy move
f3/f4 :: view edit
shift-f4 :: create new file and open in edit
meta-enter :: paste current filename into command line

and the tricky one

ctrl-o :: see results of last command execution

Windows world has Total Commander and FAR.
Linux has only MC, and nothing else (all other commander clones lack so many features that they are not worth looking into)

The best piece of software since 4DOS. :-) (Score:5, Interesting)

by Richard Steiner (1585) writes: <[email protected]> on Monday January 26 2009, @05:15PM (#26612897) Homepage Journal

Midnight Commander is one of the tools that I could live without, but I sure wouldn't want to. I use it all over the place ... on the Solaris servers and my Windows XP workstation here at work, on my Linux, OS/2, and Windows boxes at home, on my Nokia 770 tablet, etc.

It makes it easier to delete files and directory trees with certainty (and accuracy!), the built-in editor is good enough for modifying shell scripts and even making moderate code changes to more involved programs, its built-in FTP capability is invaluable when one has to flip a lot of files or directories between hosts, and its customizable menus and panelization capabilities can add some fairly powerful capabilities to even the most dedicated command-line user.

I love my Midnight Commander!

Re:Midnight Commander should die

IgnoramusMaximus on Monday January 26 2009, @06:09PM

You totally miss the point of Midnight Commander. It is here NOT to make it possible for some clueless newb to get around learning of the CLI. It is here for those of us who use CLI all the time to speed things up immensely. I can move/copy/make quick changes to files/etc orders of magnitude faster with mc then by using raw CLI even with fancy auto-complete functionality. And then there is the Meta-Enter combo which pastes the currently selected file into your commands. mc is a great improvement in productivity for me, to the point that I get the feeling of things slowing down to a crawl when mc is not available on whatever system I am working on.

Re:Norton is going to be pissed... (Score:0)

by Anonymous Coward writes: on Monday January 26 2009, @07:19PM (#26614829)

Linux has other solutions; they just aren't commander clones.

For example, Emacs. It can run in a terminal, just like mc, but it also has arbitrary frames, just like Konqueror. And, yes, its file manager (dired) has all the same features as mc .

meta-control-? -> % g
plus/minus -> m/u
f5/f6 -> C/R
shift-f5/shift-f6 -> C/R
f3/f4 -> v/
shift-f4 -> C-x C-f
meta-enter -> no exact equivalent, but ! to run a command line on marked files, or just use shell mode

ctrl-o -> look in the "shell command output" buffer

Re:Norton is going to be pissed... (Score:1)

by bruunb (709544) writes: <bbj@@@swooplinux...org> on Monday January 26 2009, @11:23PM (#26617207) Homepage Journal

You don't need X, all you need is a terminal.

MC does not take up the 1.4 Mb + shared libs + Gnome or N Mb + shared libs + KDE , which by the way only works if you have X also.

The 100% customizable build-in menu at the touch of a finger (F2) and of course file-extension feature works great - better than KDE or Gnomes version of the file-extension association lists... that don't work in all programs anyway.7

And it is almost as fast and versatile as the CLI. "Pure" CLI is still faster if you know the way around you keyboard...

And most of all no stupid mouse you have to reach out for when you want to view(F2)/edit(F3), copy(F5) or move(F6) a file (+ many more), the only thing you have to do is to reach an inch or a bit more depending on your keyboard and you got your action. When you do "system administration" work at the terminal then the mouse is not really an option.
If you don't believe me then give it a few weeks of testing. All there is to it, that goes for any and all GUI applications, is _not_ to use the mouse if there is a keyboard shortcut, including getting to menu items etc. It won't take you long to figure out that you loose time with the mouse, in just about any thing that is not drawing or moving windows around your desktop.
GUI = pretty pictures and tennis elbow, CLI = the fastest (also the choice that you need the most knowledge about GNU utilities to use), mc = CLI made easy and you get "free" visualisation of the filesystem.

If you aren't used to the CLI or the approx. 1000 "default" GNU utilities that comes with a default GNU/*nix installation that enables you to do just about anything you can thing of, excluding what your girlfriend can do, if you have one, then mc is the best way to get things done, fast and easy.

And of course, nostalgia from the "good" old DOS days where Norton Commander and DOS Navigator (some old MIT/russian NC clone that is much better than both NC and any NC clone I've run across, including MC).

Slava Zanko and his team rescue the project

Miracle rescue came in late 2009 from Slava Zanko. He not only volunteered to became new maintainer but also bravely fought with the "old guard" who did not want to release the product from their control despite obvious trend of the project to abandonware status in 2005-2009. He also proved to be determined and persistent enough to wake up the project from a long sleep.  One of this first moves, that proved to be very useful and necessary was the move of development to a new web site http://www.midnight-commander.org/.  In open source project the person who controls website and maillists indirectly has a lot of influence on the project and this move was the ultimate disengagement with Miguel de Icaza. In August 2009 he and his new team produced  mc version 4.7.0-pre1:

This release incorporates many code refactoring changes, user interface improvements, numerous bugfixes and new features.

Changelog

Major changes since 4.6.2:

Changes in the core

    * Native UTF-8 support;
    * Support for filename charset selection in panels;
    * Reworked 'Find File' dialog;
    * New unified search/replace engine with multiple search types: plain, wildcard, regexp and hex;
    * Extended 'Learn Keys' capability;
    * Locale-based codepage autodetection;
    * Initial support for Doxygen generated docs;
    * Build system updates (autoconf);
    * Translation updates;
    * Multiple x86_64 fixes.

Editor

    * Various editor enhancements (mark/move/copy/paste vertical blocks);
    * Multiple syntax file updates;
    * Source code navigation through ctags/etags TAGS files;
    * New option: 'Persistent selection';
    * Delete/Backspace deletes selected block if 'Persistent selection' is off;
    * Ability to shift blocks to the right with Tab key and to the left with Complete key if 'Persistent selection' is off;
    * Show line numbers (optional);
    * Highlighting of tabs and trailing spaces (optional);
    * Added some hotkeys.

Miscellaneous

    * Show free space on current file system;
    * Show size of selected files in mini-status bar.

Bugfixes

    * Editor undo fixes;
    * Upstreamed many fixes from the distributions;
    * Fixed segfaults on fish permission checks;
    * Fixed fish symlinks handling and fancy names escaping;
    * Various mc .ext fixes;
    * Command line completion fixes (mainly escaping);
    * Small fixes in history handling (locale independent .mc/history entries);
    * Code cleanups, various memleaks fixed (many thanks to valgrind).

As we can see that started to enhance the built-in editor functionality which was essentially intact for more then ten years since Paul Sheer programmed it for version 4.1.35  in June, 1998. That was a good move as editor looks underpowered and neglected and produced bad impression about the project as a whole

At the end of 2011 they released version 4.8 in which they managed significantly upgrade the internal editor. Among changes/enhancements:

• New engine of the editor macro
• Multiply repeat of the recorded actions 
• Call external scripts from the editor
• Added REDO action 
• Group UNDO by action 
• Selection is not reset after execute user menu
• Vertical selection is not reset after copy/move
• More intuitive word left/right action (now the cursor stop beside EOL/BOL) 
• Double-click marks the current word. Added action MarkWord to mark word, MarkLine to mark current line
• Regexp search&replace: support escape sequences in replacement string 
• Added new entries in cedit.menu: "Sort selection", "Upper case", "Lower case"
• mc.ext: use "include" for $EDITOR entries

They also changed implementation of command window functionality. Previously the implementation was a dirty hack and the source of major embarrassment for both developers and users. Behaviors of command line windows was different from the behaviors of bash terminal windows and that was situation unacceptable for many sysadmin, who otherwise would use mc on day-to-day basis. In other words this was the major weakness of the project.

But they have no resources to implement this functionality correctly so it was a simple swap implementation, the command line windows became disengaged from mc panels: if you change the directory in command line windows and press Ctrl-O to restore panels, the directory displayed in the panels would be the same old directory.

As of end of 2012 project remain active, but starved for resources. As of October 2012 most tickets are owned by just three developers Ilia Maslakov, Andrew Borodin and Slava Zanko, with Andrew Borodin being responsible for stable release mc-4.8.1.7 and the only major changes committer.  Here is how development team looks on the website:

Name	Nickname	Country	Additional info
Andrew Borodin	andrew_b	Russia	aborodin at vmail dot ru
Stan. S. Krupoderov	iNode	Russia	pashelper at gmail dot com
Ilia Maslakov	angel_il	Russia	(il.smind at gmail dot com)
Sergei Trofimovich	slyfox,sjøtroll,skogtroll	Belarus
Slava Zanko	slavaz, slavazanko	Belarus	(jabber+gmail: slavazanko at gmail dot com)
Yury V. Zaytsev	ZYV	Germany

I think FSF can (and should) act as a charity it formally is,  not so much as a Stallman vanity promoting venture that stamps GNU label on the projects as a seal of approval of project usage of GNU license with zero financial support. It should allocate some money for important projects like GNU Midnight Commander from members dues. Actually financial transparency of FSF despite noble goals leaves much to be desired.

Also as GNU screen is also FSF project the efforts to find synergy between those two project would most likely produced great dividends. Unfortunately  as (mostly) an umbrella organization FSF has no technical standing to make this happen.

In more remote perspective because of the word "orthodox" in the name (and in approach to interface), orthodox monks, who now have computers, internet connections and some free time might also be a source of some help ;-)

The third crisis in mc development (May 2015)

In May 2015 Slava Zanko's development team has it enough and resigned:

Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site

• From: Slava Zanko <slavazanko gmail com>
• To: mc-devel gnome org
• Cc: mc gnome org
• Subject: Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site
• Date: Wed, 27 May 2015 13:56:31 +0300

27.05.2015 13:37, Paul Sokolovsky wrote: 

Hi all,

The current maintainers, namely Andrew Borodin, Slava Zanko, Ilia Maslakov, Sergei Trofimovich - please provide full disclosure of what happens within your team. Whatever it is, please show goodwill by adding Egmont Koblinger to the maintainer team, if he agrees (including discussions and commit access), to show that the project wasn't usurped by Soviet Obkom.

Yes, I confirm that our team as fact has ended to develop mc. Ilia has issues with access to internet from his work, at home he has much stronger priorities with family, the same for Andrew. As for me, I have heavy loading on work, after work I am very busy on building my house. So there is no time for development mc.

And of course, we are opened for any of our wishes to develop mc. Just let me know if someone wants to participate in development and I'll give write access to repo/wiki/transifex and I'll do some knowledge transfer about usual workflows (such as: preparing for release, code styling, where our ContinuousIntegration is placed and so on).

I hope, mc will rise again with new blood.

And I agree with Andrew: "It weren't worst 5 years in my life" Yeah, it was five happy years for me :)

WBR, Slavaz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVlotoACgkQb3oGR6aVLpqysACfROPBo1/KrzNu73zwm8kpLTEI QbsAn2Gwet6bDc0FZc4nx4Gphsl4LSTE =QFDk -----END PGP SIGNATURE-----

The discussion in the mail list highlighted typical with open source project problem of allocating time for the project. It is difficult to find a person who can invest, let's say, 20 hours per week in the maintenance. even when patches to existing version are provided by other developers that bottleneck is reviewing the patches, think about possible consequences interactions with other staff and post the results of the review in some system (Trac in case of mc). For example, see  the following email:

Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site

---

• From: "Yury V. Zaytsev" <yury shurup com>
• To: Paul Sokolovsky <pmiscml gmail com>
• Cc: mc-devel gnome org
• Subject: Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site
• Date: Sat, 30 May 2015 14:59:04 +0200

On Sat, 2015-05-30 at 15:22 +0300, Paul Sokolovsky wrote:

Everything will be done on best effort basis, just the same as was
done before, and as always the case with OpenSource projects.

That's nonsense; most successful open source projects have drivers who are either employed to invest time into it, or have other circumstances that allow them to invest 10 hours per week as a bare minimum and above.

This is where the community shines: if you have several drivers who are able to process contributions in a timely manner, it adds a lot of value, innovation, diversity, etc.

Acceptance is the first step. If that is achieved, we can discuss
technical and organizational/personal commitments aspects.

I don't buy this; the first step is getting some real work done. Then we can discuss the acceptance.

Example:

Moofie is convincing, because he's done some excellent work and then went public with it. He didn't start by showing up and saying: hey, this is my plan, you have to accept it first, and then we can see if I'm actually going to do anything. He's already proven everything to me.

You are not convincing at all, because all you have done so far is to waste a lot of time with your delusional posts (also in the thread started by Moofie!), and it seems that I'm not the only one who isn't very much impressed.

-- Sincerely yours,

Yury V. Zaytsev

One of problems in development of such projects as mc is proper development tools, especially version control system and several posts mentions some problems that are seen by developers

Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site

---

 

• From: Oswald Buddenhagen <oswald buddenhagen gmx de>
• To: mc-devel gnome org
• Subject: Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site
• Date: Sat, 30 May 2015 18:05:14 +0200

---

 

On Sat, May 30, 2015 at 02:47:02PM +0200, Yury V. Zaytsev wrote:

Under these circumstances, I can stick my own (very negative) opinion
of Github issue tracker somewhere deep down, and accept that the tools
are chosen by those people who do the real work. If they like Github
issues and they make them productive, so be it.

i'll use that as a launchpad for some general musings of
state-of-the-art hosting tools i'm aware of. this is an invitation to
discussion, and i find it interesting beyond the scope of mc.


it's obvious at first sight that the github issue tracker provides much
less formal structure than trac. and trac ain't that great to start with
(especially on the workflow side, at least as configured for mc (i
don't know what would be possible with a current version)).

in github, almost everything is done with labels. it's nice and
uncomplicated, but simply doesn't scale.

on the migration side, it seems that it's impossible to fake issue
reporters. incidentally, that's one of the two problems that i fixed
last year in mc's issue import to trac because i found it so annoying.
most advanced import tool i found:
https://github.com/trustmaster/trac2github

i find github's code review system terrible; it doesn't encourage the
workflow i want (every commit being polished), and it doesn't scale,
either.

luckily, there is gerrithub.io to alleviate the problem.


there is also an open-source clone of github: gitlab.

it is really a look-alike, so it has pretty much all downsides of
github, with the addition that no gerrit integration exists (yet).
on the upside, the issue import is probably better. tool:
https://gitlab.com/kevinlee/trac-issues-to-gitlab


there is also bitbucket, but the free version is limited to teams of
five, whatever that may mean in practice. anyone here has experience
with it?


yet another fully integrated solution (for own hosting) would be
phabricator. no personal experience with it, either.

Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site

---

• From: "Yury V. Zaytsev" <yury shurup com>
• To: Volodymyr Buell <vbuell gmail com>
• Cc: mc gnome org, mc-devel gnome org
• Subject: Re: "mc is over!?" - post by Ilia Maslakov on Russian-speaking IT site
• Date: Sat, 30 May 2015 14:47:02 +0200

On Sat, 2015-05-30 at 08:23 -0400, Volodymyr Buell wrote:

That's the reason to decommission existing infrastructure asap - you
pay for the things that work against your productivity.

I've heard this before, and you still haven't explained how it works
against *my* productivity, or the productivity of Andrew.

I personally couldn't do much else in 1 hour per week that I'm spending
on it anyways. Andrew likes it and it does make him productive: check
the git log if you need statistics. Do you think that if the tracker is
migrated to Github, I will magically be able to review 500 tickets in
this 1 hour per week or what?

A valid reason for moving in my opinion would be to reduce reliance on
privately owned stuff, and I have been slowly working in this direction,
and hope to take it further in the future, but other than that, I see no
other reasons currently to do so.

On Sat, 2015-05-30 at 08:23 -0400, Volodymyr Buell wrote:

I see that you not so interested in migration as you didn't answer my
question in private.

It's not just a matter of interest; realistically, I can scrap up to 5
hours per week for mc, which means process the mailing list ~2 times per
week; processing huge emails full of very questionable content by some
posters takes hours, so there we are. I saw your mails among others, and
I'll try to reply tomorrow.

Now in what concerns the interest, yes, it is low. For once I
wholeheartedly agree with Oswald. There need to be some very important
advantage in the migration, and if we go for it, it should be done
properly.

One advantage could be that person X steps up and shows enough
commitment to prepare a migration like Slava did, and which was later
completed by Oswald. He also declares it as a pre-requisite for him
taking over and investing serious time in the project.

Under these circumstances, I can stick my own (very negative) opinion of
Github issue tracker somewhere deep down, and accept that the tools are
chosen by those people who do the real work. If they like Github issues
and they make them productive, so be it.

But I don't buy unsubstantiated arguments about magical community of
productive and qualified members appearing out of nowhere, and doing
quality code review over large spans of time. Instead, what will happen
is that Github issue tracker will become just as dead swamp of issues
and patches, as Trac has become now. I've been part of too many
projects, and I know how successful open source projects work: there is
a lot happening behind the scenes.

--
Sincerely yours,
Yury V. Zaytsev

In his mail exchange Yury Zaytsev found another formula for Linus "show me the code" mantra ;-) -- "Yet, I recognize that it's always easier to lay out great plans on the mailing list and demand somebody else to implement them. Right?" He also come up with the plan of further development

Plans for Midnight Commander development

---

• From: "Yury V. Zaytsev" <yury shurup com>
• To: mc-devel gnome org
• Subject: Plans for Midnight Commander development
• Date: Sun, 31 May 2015 20:30:49 +0200

---

Hi there,

It seems that I'm the only member of the current team left who still wants to go on with the project, so here is my current plan.

• Ilia's private post on a Russian blog site stating that Andrew decided to resign as a maintainer caused a lot of drama, but in reality, not much has actually changed since the last half a year; the situation that has been slowly deteriorating for quite awhile.
• Midnight Commander is not going away; even if commits completely cease, I'm still up to maintaining the website and all thirds-party services, as we've been doing for the last 5-6 years for as long as I can; if this changes, a proper public announcement will be made as early as possible.
• I want to make a new 4.8.15 release in the coming months (actually, as soon as possible) from what has accumulated in the current master. It's stupid to let it rot, and besides, I can check that all the knowledge required to make a release is documented, and someone other than Slava can do it as well.
• I want to use the release announcement to call for volunteers to join the team as maintainers to contribute to bug triaging and code review. Hopefully, this helps attract the attention of distro maintainers / packagers and downstream users that do not follow the mailing lists.
• After 4.8.15 release, I want to go through the current tickets and try to commit as much of trivial and/or uncontroversial patches as possible; this might form the basis for a new 4.8.16 release.
• I'll be giving FTBFS bugs and fixes a priority, so as to at least keep mc build-able with current kernels, libraries and compilers.
• Regarding mc^2 fork, I would like to review the code and get it merged. After that, we can make a major 5.0.0 release, which may take some time to stabilize. I would need help with code review to make this happen in finite time though.
• I'm doing important and long overdue firmware / os maintenance on the builders right now, which will allow them to function for quite some time. After that, I want to migrate to Travis and integrate it with Github as a priority.
• Similarly, I want to service the Trac server; I hope that I can find out what's the problem with ticket posting delays.
• Whomever wants to help, or to join the team as a new maintainer, please familiarize yourself with current state of the art by exploring the repository and documentation on wiki. The least hand-holding you require, the more convincing you look.
• You can pick tickets that need a review, rebase the patches, do a proper review, and after you've done quite some of them, I'll be happy to commit it for you. After demonstrating sanity and perseverance for some time, we can talk about the commit bit. I think these requirements are reasonable, and not much different from any other project.
• If you want to invest a large amount of work into something to prove yourself, but are unsure about it, ask on the list. If you want to tell me (or anyone) what and how we should do, but aren't ready to invest large amounts of work yourself, then please don't.
• Regarding the infrastructure & the development process that we have set up and followed while still being active: nothing is set in stone. I'd like to believe that I'm not crazy and can be convinced by reasonable arguments. However, keep in mind that the best way to convince me is to actually do the work, e.g. if someone has been triaging Trac for some time, and can explain why it's been painful, and how a proper migration to service X that he is ready to prepare will solve all the problems and make him über productive, I'm likely to fall for this argument. In the same vein, I'm unlikely to fall for the argument that all hipsters are on Github, so if we ditch Trac immediately and move to Github issues, then suddenly there will appear a bunch of dedicated maintainers out of nowhere and start reviewing patches like crazy.
• On the subject of arguments: replying to emails, while actually _thinking_ of what you are writing takes a huge amount of time. I have very little time. This email took me more than an hour to write. Think of how these three facts interact.
• Regarding time, I can consistently make about 1 hour per week, up to 5 hours in bursts, but that's quite a bit of stress. I'll see whether I can figure something out, but in any case expect delays in communication.

   

  I will try to answer as much other emails that need to be answered from the recent threads, but I have now about 2 hours left. I hope that these points cover the most important issues though.

  -- Sincerely yours, Yury V. Zaytsev

Compatibility with OFM1999 standard and shortcomings

Overall compatibility with OFM1999 standard is fair. Recent (November 2012) compatibility testing using OFM1999 v3.1 gives  Midnight Commander  compatibility score around 61% which is less then FAR(88%) and Total Commander (63%).

As you can see from detailed test results, in several many places Midnight Commander cuts corners creating difficulties for long time OFM users, especially those who are coming from FAR or File Commander background.    

Interface look & feel

Midnight Commander provides classic OFM interface with two symmetrical panels and command line at the bottom. Command line is expandable to full shell terminal screen, but not to 50% screen with hald of panels visible. This is an architectureal flaw and difficult to correct. Symmetrical panels provide user definable fields and ability to switch to one of several predefined templates including horizontal panels. 

Midnight Command has standard information line under each panel. There is no capability to select files with the current file extention by clicking on information line. 

Both bottom and top menu are present. Top menu provides access to configuration and commands without shortcuts.  Bottom menu does not changes is you press and hold Ctrl, Alt, Shift and there is no "rolodex buttons" to see what operation are provided by F-keys with Alt, Ctrl and Shift prefixes. In view of huge number of shorcuts present in mc this is a serious deficincy. Also Command dialogs does not contain hotkey bar iether and does not change main hotkey bar. In this respect mc really sucks...  

There is an important for Unix capability to position both panels horizontally and it is present for a long time. That's a good thing.

But lack of capability to expand command line to half screen lower the mc rating in this test.

Navigational and basic hot keys compatibility: 

1. Enter compatibility. Enter results of execution if file is executable and evaluation of extension menu if not. Results are visible at the shell terminal window. There is a long time bug which produces ""The shell is already running a command". when under certain circumstances mc lost track of shell status (see Re Error The shell is already running a command ).   Ctrl-Enter does not copy the current file to command line
2. The Tab key behavior is compatible
3. Ctrl-\ is compatible (displays directory favorites list; it might be better to go to home directory of the user instead).
4. Ctrl-PgDn and Ctrl-PgUp depends of terminal used and in most cased those shortcut do not work. They should allow to move to the upper (current subdirectory) and lower level directory respectively, without changing the command line even if a partial command is already typed on command line.  In MC mouse clicks on directory can be used instead so we can judge this feature as compatible.  The importance of this feature is that it permit exit from several level of directories without changing the command line that might contain partially typed command. This way you can assemble command line while traversing directory for its components, for example file names.
5. Ctrl-R -- Reread the directory; Work for virtual filesystems for example FTP VFS as well.
6. Ctrl-U -- swaps panels;
7. Alt-F1 and Alt-F2 (Ctrl_Alt-F1/F2 In Windows) should produce the list of logical disks, in Unix list of mount points.
8. Ctrl-L is implemented with default shortcut Ctrl-X i  is produces the information about the file or directory. But it does not understand present of README or other "dirinfo" file in the directory (and there is no capability to define "dirinfo" files. Default for dirinfo descriptions in UNIX-based implementations should be README file). If multiple files match user-defined regular expression specified in dirinfo,  the first should be displayed. The file that serve as dirinfo file should be user-definable with the possibility to define it with regular expression (this way multiple files can be defined, if desirable).
9. Ctrl-Q  (Ctrl X q is used) switches to quick view.

Shell Windows compatibility

In version 4.8.1.6 implementation is better then in previous versions

1. Mc is an old implementation is it does not have tile windows manager layer. So there are obvious difficulties with implementing  to half screen vertically and half screen horizontally views on shell terminal window
2. Mc command line allows to execute multiple command with macrosubstitution of macrovariables and shortcuts to the current file to the command line (Esc-Enter) as well as  current directory ($PWD) vi Ctrl-x p    Copying of left and eight panel directories (Ctrl-[/Ctrl-]) are not implemented.  
3. Ctrl-O  maximizes  shell terminal windows (hides both panels by default):
   1. In the resulting screen standard shell terminal functionality is present
   2. If current directory was changed during the work in command window, the active directory in the panel doe not reflect the new directory on return to panel view by pressing Ctrl-O again.
4. Terminal session look& feel compatibility of OK but  there is no ability to scroll window back
5. Ctrl-F1/Ctrl-F2 functionality (hiding one panel) is not implemented.
6. Ability to shrink panels 50% or gradual shirking/expansion of panels (vertical shrinking compatibility) is not implemented

Compatibility of F1..F12 and other F-keys operations

• F1 -- compatible but somewhat outdated. Midnight Commander uses something that resembles old Norton Commander hypertext help, not the html as it recommended by the OFM1999 and as Total Commander uses. Context help is available in few cases, but treatment is not uniform and is not well implemented.
• F2 -- incompatible (means Reread source window duplicated with Ctrl-R) but user menu is available by the name of Start menu (Option Start on the top toolbar).
• F3 - compatible
• F4 - compatible
• F5/F6  Compatible: Copy/Move "overwrite" dialog windows contains information about the size and date of creation of files. Instead of Shift-F5, key shortcut  Ctrl-x s is used to creates symlink of the file you're currently on (defaults to  placing that symlink in the dir in the opposite panel).
• F7 is compatible. Shift-F7 is incompatible -- should create soft link to the current directory on active panel in the directory in passive panel
  
• F8 compatible 
   
• F9 and F10 -- compatible ( Main menu activation and exit)

Tree View Panel compatibility

• Tree panel is present and navigatio
• You can to copy files to the tree target but target of passive tree is not highlited (also it is visible in the information line.  This mode in tree part should have look& feel of Microsoft File Explorer. 
• Quick search on tree view works and is compatible -- you type letters and search using prefix is performed. Serach should be activated
• Jump to directories with the same prefix down the tree is implemented and works.  In quick search mode Ctrl-Enter should jump to the next directory with the same prefix (If no prefix is specified it find the next directory with the same name, if any). Note: search should be activated
• Movement of the cursor on the panel with tree representation should not lead to change of the directory on the passive panel.
• Noncompatible: F4 in treeview mode does not allow to edit directory attributes
• Tree browsing is OK. In this mode pressing Enter should change directory of the passive panel and Midnight Commander does exactly this
• Ctrl-Enter should copy file to the command line and it does.
• Navigation keys such as Home/End UpArrow and DownArrow work as expected.
• Noncompatible: Same level of nexsting navigation (spacebar and backspace) is not implemented.  PgUp/PgDown also can be used for same level of directory nesting navigation

Directory search panel (NCD panel or Quick CD panel)

• Initial Focus of the tree is implemented correctly:  Alt-F10 produces tree view of the current panel starting with the current directory (not root!) and provides the the ability to select new current directory on this representation with Enter. 
• Noncompatible:  Refocusing the tree. You can put any directory "in focus" (position it in the middle of the panel) by pressing F5. 
• Rescanning with F2. Implemented although speed is not that great even of SSD disks... 
• Quick search input line is provided at the bottom of this panel as it should
• Ctrl-Enter jumps down the tree to the next directory with the same prefix.
• Copy(F5), move(F6) and File Find operation dialog boxes provide the possibility to select the target from the quick tree search panel (via F10).
• Noncompatible:  Same level of nesting navigation (+ and  -) is not implemented (should navigate on the same level of nesting of directories)

Files Selection/Deselection

1. Ins  behavior is compatible. It select a single file. Cursor moves one line down on selection; If Ins is pressed on already selected file it is deselected (toggle).
2. Gray+ and Gray-  behavior is compatible. They  select and deselect file using a regular expressions (as a minimum, shell basic regular expressions). Basic regular expressions are supported, for example the expression *a*.*  selects files like my_bak.tmp and my_bat.txt, not all files). No support for Perl regular expressions
3. Gray+/Gray- operations are persistent (second selection operation adds to existing selection);
4. Gray *  inverts the current selection
5. Named (savable/restorable) selection patterns are not implemented
6. Select by file type, date range or custom script (FindFile-style selection) is not implemented
7. Selections history is implemented. Mouse clickable icon [^] is available. 
8. Ability to separate individual regex with ";" is not implemented.  
9. Extended or Perl-style regular expressions support as an option not implemented.

Quick view compatibility

• satisfactory (no communication with the editor whatsoever as there is no built-in editor). Does not work in FTP mode.
• There is quick view mode for selected files. You need to filter them first.
• There is no attempt to display extended attributes for the files, if they are present.
• In tree view quick view does not show content of each directory as you move cursor down.

Macro recorder compatibility

• Compatible only in built-in editor. It is not implemented in panel view but external macro generators can be used (although they can't access panel variables). What is really funny is that MC contain S-lang library for 10 years or so and developer never used S-lang capabilities at all. Reminds me joke about C-gulls which can write DOS programs in any OS ;-)

FindFile compatibility

• Generally compatible
• Supports DOS style regular expressions
• No ability to search for files belonging to certain data range, but because script panelize command is available Unix find can be used to compensate for this shortcoming.

Command line execution compatibility

• Generally compatible

Sorting and filtering file and directories in panel

• Generally compatible

User Menu

• Best implementation in existing OFMs

Additional file commands compatibility

• You can change attributed but implementation is clumsy. Actually there are two incompatible implementations of the same function.

Association management compatibility (extensions menu)

•  Best implementation in existing OFMs

Compare directories

• Compare files / synchronize directories -- good, well thought out implementation

Built-in viewer:

• Good. Greatly improved in version 4.8. Still no folding is implemented.

Built-in Editor

• MC build-in editor is the only OFM built-in-in editor implementation with user menu and as such superior to alternatives despite several deficiencies.

Archive virtual file system 

• Archive VFS - excellent
• Archives are handled like subdirectories. You can easily copy files to and from archives. The appropriate archiving program is automatically called. pkzip, arj, lha, rar, ace and uc2 are all supported.

History and favorites compatibility

• History implementation is pretty uniform is excellent and [^] icon is present almost everywhere.   
• Directory favorites -- Good, but can be better. No ability to panelize it. 

MC advanced features and contributions to the field

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 ext2 file system.

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

• The best naming system for macrovariables  among all existing 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.
• Context-sensitive, dynamic user menu based on "visibility predicates". 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.  Visibility predicates need unfortunately written in "vendorspeak" as neither LUA not Slang are available as macro languages.
• Advanced implementation of extension menu. Concept of "actions" was introduced in extension menu. So pressing F3 is one action, while pressing F4 is another, and pressing Enter is yet another one. You can assign a program for each action (viewer fro F3, editor for F4 and so on for files with given extension (for example .pdf) via extension menu. Both can be assigned depending on the result of a predicate (or even script) evaluation. Script can filter the file before passing it to the viewer  (very useful for viewing log files)
• Built-in internal editor user menu. 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 exportable to the editor as macrovariables and can be inserted into the text via editor user menu
• "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.
• Columns in the panels can be sorted with a mouse click on the column title like in Midnight Commander (version 4.7 and later). 
• TCP based client-server mode of work. This is not very well documented and now probably abandoned capability, but really impressive feature that makes the usage of mc more flexible and permits cross platform usage. It also help to separate mc implementation into two layers. Although the serial and parallel line client-server capability were available in OFMs long ago mc was the first to implement master-slave connection over TCP/IP. 
• You can assign viewer and editor for files with given extension (for example .pdf) via extension menu. Both can be assigned depending on the result of a predicate (or even script) evaluation. Script can filter the file before passing it to the viewer  (very useful for viewing log files)
• "History of everything" and command completion in all dialogs. That's really highly helpful feature for advanced users.
• Since version 4.8.1 better, more consistent with need so system administrators implementation of command console interface. Probably the first "Ctrl-O" (shell output window view) support of  "usable" Unix console.
• You can add the 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 (which in version 4.8.1 can be used to rsync panel directory with shell terminal screen directory.
• The first correct implementation of command windows functionality in version 4.8.  Paradoxically before mc 4.8 using OFMs were extremely weak in this area as if programmers who wrote them were completely limited to Windows experience and did not understand of value of integration of shell and file manager the OFM support.
• Correct implementation of Ctrl-O functionality in viewer and editor -- after clocking this key combination, the editor or viewer became hidden and command like window is exposed where you can type commands. This functionality is available only if mc was invoked from first and then from it editor or viewer were invoked.
• Full power of regular expressions in selections and search. For example, in panel selections the list "*.txt; *.bat; *.inf; *.doc" can be specified as "*.(doc|bat|inf|doc)".
• RegEx-based search capabilities.
• XTree VFS (flat view on directory tree) can be emulated  in mc using panelize command (search for *), but without macros this emulation is pretty painful.
• One of the first implementations of FTP VFS.
• 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)
  • The circular ring of predefined display formats Switchable via Alt-T. This is great then you switched from vertical panel split to horizontal and want to see additional attributes. This way you can.
• Synchronizing the current 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.
• Ctrl-O in viewer and editor hide the window and exposes the panels.
• 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).
• Built-in Editor with some unique features:
  • Greatly improved in version 4.8.1.
  • Editor user menu -- unique and very productive enhancement of OFM editor functionality. 
  • Supports user menu and %b macro variable which allow redirecting output of the pipe into internal block or at cursor position if no block is selected and vise versa redirect selected block of text for processing by internal pipe. 
  • Macro capabilities.
  • Syntax highlighting in built-in editor
• Built-in Viewer
  • Viewer supports percentage based offsets. 
  • Viewer supports bookmarks.
  • In version 4.8 viewer is greatly improved and is faster.

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

Midnight Commander  interface is less flexible then in FAR (especially in implementation of command line window functionality). For example you can't hide one panel and can't shrink panels vertically 50% exposing shell terminal window.  Some of the problems stems from limitations of development environment (keyboard issues belong to this category), some from advanced age of the project (it is now close to being 20 years old). Among most visible problems are problem related to the architecture of mc as three non overlapping tiles windows manager (see ratpoison for correct implementation) and related deficiencies in implementation of command window.  In version up to 4.8 it was a hack and properties of command windows were completely different from a regular shell terminal. In version 4.8.1 implementation improved and command line windows now behaves like a regular shell terminal, but communication between command window and panels is broken and if you change directory in command line windows and press Ctrl-O you will see old directory in active panel. :

• Panels are "non-shrinkable" and non-resizable vertically (they can be made asymmetrical horizontally).  There is no ability to shrink panels to 50% of the size and still use command window. You can't hide left or right panel exposing part of command window like in NC and FAR.
• Lack of understanding that in many situations horizontal split is more natural panel arrangement in Unix, then vertical split and that switching should be supported via hotkey.  (GNU screen is classic example of correct implementation of horizontal panel splits). If you switch to horizontal panel arrangement the set of attributes displayed is not changed, despite the fact that horizontal arrangement allow display of ownership and file attributes information which is very important in Unix. Another deficiency is that there is no hotkey for switching panels from vertical split mode to horizontal split mode (with different set of columns in each configuration).  For example if one quickly needs to see ownership and file attribute information or have really long file names in the panel. 
• The built-in editor cannot be minimized to one panel and works only in full screen mode.  With 132 character width this is a useful mode of work for sysadmins. I think luck of this capability which is present in NC and FAR is a side effect of absence of windows manager layer in mc (inability to hide one panel and expose shell terminal window also stems from this architectural problem).

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. There are two fundamental architectural deficiencies of MC:

• Implementation of command window (terminal) functionality is extremely important for Unix OFM as main users are Unix/Linux sysadmins. It was never paid appropriate attention in mc development (implementation was and still is worse then in NC, and especially FAR). Strangely enough the capabilities of OFM as shell extension/helper somewhat similar to screen are poorly understood by most OFM developers, including, strongly enough, most Unix developers. As if people who wrote Unix OFMs use Windows as their development platform. Although mc went farther then most Unix OFM projects and provided (limited) support for the Ctrl-O operation (hide panels and expose shell screen) since version 2.1, only in version 4.8 developers managed to change it to the better, but because of swapping solution introduced another (althouth solvable) problem of synchronization of return directory with the active panel.

  Still there 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 somewhat limit the usefulness of mc in debugging shell and Perl scripts.

• Absence of built-in scripting language. The major architectural weakness of mc is the absence of a build-in scripting language. There are rudimentary attempts to invent some rudimentary ad-hoc 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 "vendor-speak" 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.

There are also multiple (and somewhat annoying for long time OFM users, and especially for users who use both Linux and Windows on dayly basis) idiosyncrasies and "misunderimplementations" of features:

• Capability to redefine key combinations is still very weak.  For example with good luck you might have  Ctrl-PgUp and Ctrl-PgDn working on your terminal. Those key are useful if you start typing something command on the command line but need to change directories.  But there is some suspense in this area too as I used to 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.
• Directory hotlist (Ctrl-\ in Mc) should be accessible via Alt-F1/Alt-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 due to built-in motor skills of users who use both platforms (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. 
• Built-in viewer:
  • In version 4.8 viewer is greatly improved and is faster.
  • Far inspiredIt also can go to given line given in % (100 is the end of file and use bookmarks).
  • While you can view the next and prev. file, you can not view the next selected file (or prev selected file) using recommended by the standard key combinations:
    • Ctrl-F Jump to the next file.
    • Ctrl-B Jump to the previous file.

    More correctly this feature is only partially implemented. Both versions 4.6.x and 4.8.x have a bug: instead of the next selected file in the panel, simply the next file is shown. The same error exists for Ctrl-B...
    

  • There is no way to invoke the editor from the viewer and vise versa.
    
• Built-in 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.  There is no ability to specify creation of symlink instead of copy in F5 and F6 menu.
  
• 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

• 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, excellent knowledge of Unix command utilities, shell and vi and corresponding motor skills. For them mc was not really attractive until version 4.8 as shell windows implementation not a real terminal window but a dirty and limited hack. Situation improved with the version 4.8, but there are still problems with passing the current directory back to mc on Ctrl-O.
  • 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 OFMs used in Dos/Windows environment such as FAR, Midnight Commander or WinSCP.

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

MC codebase

Despite some progress achieve in moving from 4.5.55 to 4.6.2, and then to 4.8.1 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 was a small note( Doc/DEVEL file) called "the developers' hint guide" that in 120 lines tries to communicate some requirements for the contributions.

It's interesting that Miguel actually is a very prolific writer that maintains his own blog. Also it looks like at least judging from 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 while being in some high position in Novell. Reimplmentation was called Mono. And up to this day Suse distribution contains Mono as a component

But that completely contradicts his own practice in mc . Here he looks like a primitive hacker, not like a real high-class developer. 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 attempts to use Javadoc-style documentation scheme whatsoever, other then in a couple of functions that use /* {{{ */  and  /* }}} */  metabrackets 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 :-).  His example suggest that there some truth in statement that open source strongly reminds a religious cult where high priest are systematically engaged in immoral behavior while bestowing moral advice for parishes ?

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.

I think that each open source developer should understand his own "mortality" and see as part of his mission to document, clean and otherwise prepare the codebase for the next maintainers as in two or three years he either will lose interest in the project or his circumstances will change and he will not have time to devote to the project.  This is actually the reason I created this electronic book and related set of pages.

We still understand very little how volunteer software development really works and in a sense mc development is "under open sky" laboratory that tells us a lot about a typical path of open source projects with their mini crisis due to disagreements about technical development path,  absence of succession of maintainers and periodic shrinking of developer community (with real possibility of a project to be mothballed for several years), betrayal by leaders and other nasty things you will never read about in Cathedral and Bazaar.  In any case, based on this 20 years history, Eric Raymond should shave his head and eat a copy of Cathedral and Bazaar shredded into borsch to show the community some level of repentance for the wrong ideas he promoted :-). The case of glib use is a good example of "conundrums" or dilemmas that developers must wrestle with. Along with proverbial issues such as delegating versus retaining control, balancing complexity and flexibility, and fighting featuritis aka "creeping featurism" (The term "creeping featurism" was used in a 1976 Programmer's Workbench paper  by John Mashey; he also used it in talks in 1977, and later gave (as an ACM National Lecture) about 50-70 times through 1982. The original foils were scanned in 2002, and the phrase is used on Slide 033 within the talk.). mc developers should probably print and put above their monitors Greenspun's tenth rule. Here I reformulated it in more modern form, more suitable for OFM developers ;-) :

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of a  half of scripting language interpreter. Probably more than half in case of Lua, and less then half for Perl, Python, or Ruby

Architectural stagnation -- inability of key MC developers to integrate LUA support developed by mooffie

Around 2016 the MC enthusiast known under nickname mooffie developed a fork of Midnight Commander that included LUA support and convincingly demonstrated how inclusion of LUA instantly elevates Midnight Commander to the next level in all key functional areas. But especially in the area of extensibility.

Here is one of the original emails that announced this project

[Oct 15, 2015] Lua-l - [ANN] mc^2 by mooffie

Links are now broken as the site was migrated to www.geek.co.il. Valid link is Getting started

Oct 15, 2015 | n2.nabble.com

[ANN] mc^2 11 posts

mc^2 is a fork of Midnight Commander with Lua support:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/

...but let's skip the verbiage and go directly to the screenshots:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/guide/SCREENSHOTS.md.html

Now, I assume most of you here aren't users of MC.

So I won't bore you with description of how Lua makes MC a better file-manager. Instead, I'll just list some details that may interest
any developer who works on extending some application.

And, as you'll shortly see, you may find mc^2 useful even if you aren't a user of MC!

So, some interesting details:

* Programmer Goodies

- You can restart the Lua system from within MC.

- Since MC has a built-in editor, you can edit Lua code right there and restart Lua. So it's somewhat like a live IDE:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/images/screenshots/game.png

- It comes with programmer utilities: regular expressions; global scope protected by default; good pretty printer for Lua tables; calculator where you can type Lua expressions; the editor can "lint" Lua code (and flag uses of global variables).

- It installs a /usr/bin/mcscript executable letting you use all the goodies from "outside" MC:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/guide/60-standalone.md.html

* User Interface programming (UI)

- You can program a UI (user interface) very easily. The API is fun yet powerful. It has some DOM/JavaScript borrowings in it: you can attach functions to events like on_click, on_change, etc. The API uses "properties", so your code tends to be short and readable:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/guide/40-user-interface.md.html

- The UI has a "canvas" object letting you draw your own stuff. The system is so fast you can program arcade games. Pacman, Tetris, Digger, whatever:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/classes/ui.Canvas.html

Need timers in your game? You've got them:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/modules/timer.html

- This UI API is an ideal replacement for utilities like dialog(1). You can write complex frontends to command-line tools with ease:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/images/screenshots/frontend-scanimage.png

- Thanks to the aforementioned /usr/bin/mcscript, you can run your games/frontends from "outside" MC:

http://www.typo.co.il/~mooffie/mc-lua/docs/html/images/screenshots/standalone-game.png

* Misc

• - You can compile it against Lua 5.1, 5.2, 5.3, or LuaJIT.
• - Extensive documentation.

There were some weak attempts to push this fork into mainstream but they failed due to lack of time from the maintainers of the mainstream version

[Dec 20, 2016] Ticket 3745 (Integration mc with mc2(Lua))

Dec 20,2016 | midnight-commander.org

Ticket #3745 (closed enhancement: invalid)

Opened 2 years ago

Last modified 2 years ago Integration mc with mc2(Lua)

Description I think that it is necessary that code base mc and mc2 correspond each other. mooffie? can you check that patches from andrew_b easy merged with mc2 and if some patch conflict with mc2 code hold this changes by writing about in corresponding ticket. zaytsev can you help automate this( continues integration, travis and so on). Sorry, but some words in Russian:

Ребята, я не пытаюсь давать ЦУ, Вы делаете классную работу. Просто я хотел обратить внимание, что Муфья пытается поддерживать свой код в актуальном состоянии, но видя как у него возникают проблемы на ровном месте боюсь энтузиазм у него может пропасть.

Change History comment:1 Changed 2 years ago by zaytsev-work

• Status changed from new to closed
• Resolution set to invalid

​ https://mail.gnome.org/archives/mc-devel/2016-February/msg00021.html

I have asked what plans does mooffie have for mc ² sometime ago and never got an answer. Note that I totally don't blame him for that. Everyone here is working at their own pace. Sometimes I disappear for weeks or months, because I can't get a spare 5 minutes not even speaking of several hours due to the non-mc related workload. I hope that one day we'll figure out the way towards merging it, and eventually get it done.

In the mean time, he's working together with us by offering extremely important and well-prepared contributions, which are a pleasure to deal with and we are integrating them as fast as we can, so it's not like we are at war and not talking to each other.

Anyways, creating random noise in the ticket tracking system will not help to advance your cause. The only way to influence the process is to invest serious amount of time in the development.

As of Jan 2, 2019 the mc2 fork is stagnant with last commits dated Sep 5, 201

If can be downloaded using GIT from  GitHub - mooffie-mc- Midnight Commander with Lua support

As three years lapsed without any action by the primary maintainers, we can definitely speak about architectural stagnation of MC: anything above minor enhancements and bug fixes is out of reach for the core developers simply because of lack of time (if not interest).  So much about fairy tails of Cathedral and Bazaar. 

Webliography

• Midnight Commander
• Mcedit -- Midnight Commander’s Editor
• MC User Menu
• External panelize
• Cheetsheet for Midnight Commander

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019