Hello! > OK, I agree that copying between shells is ugly. And I take yor point > that integrating shell into mc is "a lot of changes". However I do think > that to be able to call mc a well designed program, such shell > integration MUST be done sooner or later. Not only the current command > line handling is counterintuitive, but an integrated shell will have > other advantages such as using command completion right inside mc.
To call mc a well designed program, it should be a well designed program. All functions should be commented. Security should be implemented from the beginning. The design should encourage code reuse. There should be a test suite. Midnight Commander is not a well designed program. I don't have time to make it a well designed program in a reasonable time. I'm not getting enough help from other developers, although I could be to blame for not encouraging them enough to do the right thing. There is still a lot of code written in 1994-1995, undocumented and essentially unmaintained. It's very fragile. Testing any changes almost always uncovers unrelated bugs, that were sitting there for years. Things are getting better, but not as fast as we would like. If somebody wants to integrate the subshell and clean up all the surrounding code, I'll be ready to help. I personally have other priorities. I'm more concerned about security and code reuse. > Isn't there some standard interface layer that would allow to integrate > any shell that conforms to this layer? I don't think it's really that > hard to implement (but I'm not a programmer so I may be wrong). Or we > could start with bash integration and then move to other shells. I don't know about such standard. > Sure, but if you integrate the shell, you can use all of this and more > right under your blue panels! That would be the best of both worlds. I, > for one, would be perfectly happy to learn a different key for panel > switching if only I could use Tab in mc (not in a subshell!) as I use it > in bash. It's a problem of trust. If we integrate the subshell and release mc with known buffer overflows in VFS, most distributions will drop mc, and most users will never see the new nice mc (or even old mc for that matter). I don't have time to do both security and radical redesign, and you are not offering any help. Another problem is that integrating of anything will add a huge chunk if the code that MC developers are not familiar with. Who is going to maintain and resync it with the project it came from? We already have stripped down samba in the mc distribution, and it's still an old version, possibly with known security holes. Good desing would be if we design an interface and then help bash developers implement it. Or we could write a new shell, integated with mc from the beginning. > I would even go as far as to say that on Unix, a Norton-like file > manager that does not improve and build upun the shell command line > experience (but instead obscures it and makes it clumsy to access) just > makes little sense. It's not MSDOS where command line has so little to > offer and therefore a visual file manager is a neccessity, not a luxury. > Under Unix, we really don't want to lose what we already have; a visual > shell must enhance the command line, not replace it. This doesn't mean it has to be Midnight Commander. There are other projects with better codebase and without history of hacks (like rxvt extensions). > By the way, I think that the continued popularity of mc compared to > other Norton-like managers for Linux is exactly due to the fact that, > although clumsy, command line access is still much easier in mc than > elsewhere. I think this advantage must be realized and improved - by > integrating a full-blown shell into mc. Please understand that my resources are limited. Ok, I once applied a patch from one of the developers that implemented Ctrl-O in the viewer and the editor. It turned out that "exit" in the command like would cause a hang with 100% CPU utilization. I wrote that guy about this problem, and he answered that it's not his problem. One year (!!!) later I could finally find time to fix this problem. Nobody helped me in the meantime. Until you can find somebody who implement shell integration correctly and won't tell me that it's not his bug if the shell doesn't exit, I don't see any reason to continue this discussion. Don't expect me to answer you until you have a patch or a developer who can make it. > > To see the output, there is an option "pause after run" in the > > Options->Configuration menu. > > This is ugly. The "press any key"-based interface is dead for at least a > decade and nobody wants to revive it. I want to be able to switch _back > and forth_ between panels and command output at any time, without losing > one or the other, and I want to use the same tools and keys (with the > obvious exception of panel navigation keys disabled when panels are off) > in both "views". I think this is the most sensible approach. It's your choice. > I think the menu item is OK. Whoever wrote it did understand what the > user wants. So the fault is with the programmers who didn't implement > this correctly :) I guess it was just an attempt to imitate NC menu. > Could you please detail what I need to do with cons.saver to make it work? It's run by mc, just make sure it's installed. You may need to make it suid root if screen is only saved when you are logged in as root. > On another subject, the --help-colors text has these problems: > > - it does not state that I can put more than one keyword in the option > and does not mention that : must be used as a separator. It's not that > easy to guess. > > - the keyword "execute" must be "executable" > > - there are more keywords in text.c than listed in --help-colors - why? Most likely whoever added new keywords was too lazy to fix fix the help output, and the maintainer either didn't have time to review the patch or didn't catch this problem or desided to fix it later. -- Regards, Pavel Roskin _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
