Hi, [ please do not cc:, i'm subscribed on mc-devel ]
> > > I'm glad to welcome you in our team. The existence of AMC was an > > > important argument for removing the GNOME frontend. Your expertize will > > > > Eh. I'm really surprised :) > > It was a clear indicator that something wrong was going on with the > project. Another reason was the appearance of gmc alternatives, such as > Nautilus and Gentoo. I've never understood why was it good to hack mc to hell to get the gmc thing, especially after trying gmc. Writing such thing from scratch must have been simpler... > As for the text edition, I wanted to release 4.6.0 much earlier, but it > was a heavy race against bugs. As soon as somebody was fixed, another > critical bug was reported. Sometimes it seemed that I'm losing the race, > but finally I could concentrate and deal with the remaining issues. :) I've done exactly the same with mplayer 0.90. We're delaying teh release since 2002 april because of serious bugs keep appearing, and now after few months of heavy bug-hunting and feature-freezee it's finally stable. We'll release 0.90 final in a few days. I've decided that before I start mplayer generation 2 (new core etc, instead of hacking 0.90 more) I will "tidy my desktop", ie fix the bugs and add missing features i'm fighting every day in development tools, especially in mc and mailer3. So I'm here :) > Of course, a lot of stuff was moved to the TODO file. We also have a bug I've read it. I'll come up soon with my own TODO, probably a stripped down version of yours, with things i'm interested to work on. > tracking system and a patch manager on savannah.gnu.org. There are still > serious problems in the code, such as an unsafe rewriting of the config > files without locking and doing backups. ah, the config system... i usually run several instances of mcedit on tty1..tty9, editing various source files (yes i know i should use some multifile-capable IDE but i like mcedit) and if i change something (indenting, tab size etc) in one mcedit then it will be saved and new mcedit instances will have that values set as default. It's really annoying... Imho there should be something like 'Ok for this instance' and 'Save as default setting' choices at the preferences/settings panels. > There is a lot of work to be done. 4.6.0 is just the beginning. Sure. I've find this in TODO: * Internal terminal - no more console saving. Imho it's one of the most important issues/problems of mc. I'm use dto norton/volkov comamnder under dos, and far under win32, they behave the same way when panels are visible and when they are hidden. In opposite, mc is tricky: if panels are enabled, then you're in mc's line editor, with mc hotkeys working. When panels disabled: you're in raw shell, no mc keys or things available. Even the command history in panels on/off mode is independent... The question is that how to solve this duality. Or is it planend at all? The first thing came in to my mind is the approach used by Volkov commander: You're always in the commandline editor, even if panels disabled. If you enter sth and press enter, it execute sthat command in a new shell ("command.com /c yourcommand"). If you press alt+enter, it executes it in parent shell by calling the int 4Bh syscall (something like the exec*() posix calls, running the commands in the current shell). This is very important if you want to execute shell setting commands, like setting environment variables, set up alias-es etc. Anyway i'm not sure it's doable, but i think it is. Also, I like your idea of builtin terminal emulation. Btw, it would be nice if it could run commands in new tty. Some utils, for example fte, ht or biew supports raw keys (to utilize shift+control+Fx etc combinations) but they don't work when executed from mc. It's boring to exit mc whenever i want to run biew on a file... It should be optional, and is useful only for local console use. (i opposite, i like that dosemu doesn't get raw access when run in mc, so i can copypaste with gpm from/to dos apps :)) > > It is the reason why i planned to fork or start a new project from > > scratch. > > Please avoid forking by all means. If you have problems with the current > code, I'd like to hear from you. Ok i'll try to avoid forking :) But I will (have to do) if we can't agree on some important change later, since getting the issues solved is more important for me than waiting years for some api change or end of code freezee :) (I just don't want to fight against others too much to get my patches accepted. When i did AMC, i knew that those changes are not clean and will never be accepted to the official code, or if they will be it's even worse because it means that clean code is not a goal... but the more important reason was that gmc mess all around in 4.5.x...) > > It's amazing to see that it's still under development and the goal is > > again making a stable bugfree console tool instead of yet another > > winblows-exploder or win-commander clone for gnome/X. > > It's quite natural, actually. GNU Midnight Commander doesn't have major > competitors in the free software world. yes. many of my friends said "mc is buggy, mc sucks, but no alternatives so i'm using it". I hope i can help changing this opinion. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu _______________________________________________ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel