Re: command line synchronization
- From: "bulia byak" <bulia dr com>
- To: mc gnome org
- Subject: Re: command line synchronization
- Date: Tue, 16 Jul 2002 16:56:24 -0500
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
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
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
Read "info bash", in particular "Command Line Editing".
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
Save up to $160 by signing up for NetZero Platinum Internet service.
] [Thread Prev