Re: command line synchronization

[Pavel Roskin <proski gnu org>]

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