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
