Re: command line synchronization

["bulia byak" <bulia dr com>]

> To synchronize the command line after editing it in the subshell, mc
> should be able to know what is currently in the command line buffer of the
> subshell.  There is no generic way to request it from the shell.  
> Interpreting the keystrokes would not help.  What if the user did history
> search?  There is no way to know what the shell has found in its history.
>
> The only clean solution would be to integrate the shell into MC.  But this
> would be another project - it's a lot of changes.  Right now, mc supports
> bash, zsh and tcsh as subshells.  It would be hard to satistfy users of
> all three shells.

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.

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.

> Not for me.  I use the subshell to use its command completion and the
> shell history.

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. 

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.

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.

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

> > After all I do have a shell already with panels, why do I need another
> > one?
>
> Read "info bash", in particular "Command Line Editing".

See above.

> > And the menu command says nothing about any subshell - it promises to
> > "switch panels on/off". If it does anything else, this is just wrong.
>
> I think this item was written before it was implemented.  It would be nice
> to change this text if it wasn't translated into 30 languages and we were
> not approaching the next stable release.

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

> Yes, you can if mc can read data back from the screen.  For that to be
> possible, run mc either on Linux console (you should have access to
> /dev/vcsa* or have setuid cons.saver) or on rxvt with rxvt extensions
> (search the web for the rxvt patch, I don't have it).

Could you please detail what I need to do with cons.saver to make it work?

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?
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8