On Fri, Jul 14, 2006 at 11:27:27AM +0300, Pavel Tsekov wrote:
On Fri, 14 Jul 2006, Oswald Buddenhagen wrote:
without the subshell i can't operate mc while the command is executed, i
Ok. But it can be as simple as Ctrl-O, execute command, Ctrl-O. There is
only an extra Ctrl-O.
yes, and i can't use alt-a, alt-enter and ctlr-shift-j.
can't use the shell's much better completion, history and line editing,
The subshell prompt widget doesn't perform these via the subshell.
oh, really? ;)
aliases shell functions and whatever cool features a modern unix shell
Well yes - but see above. Again Ctrl-O followed by a command should do
just fine.
and again i can't mix it with functionality provided by the panels.
offers, and i can't execute a series of commands without switching off
I dont understand this.
forget it, it was based on the observation of no subshell at all (mc -u).
I am not advertising the removal of the subshell . I just want to remove
the ability to execute commands typed at MC's prompt widget trough the
subshell (if it isn't clear yet).
good. but exactly this integration makes it so valuable for me.
otherwise i could just use another xterm/vt/screen.
However, if this functionality is to remain we have to define exactly
how it is supposed to work and the subshell prompt should definitely
go. My opinion is that if we start to impose restrictions on that
feature there would alway be a group of confused users since it want
behave exactly as they would expect to. But I am open to suggestions.
the current implementation is a mc command prompt and a real shell
prompt. the mc prompt can inject commands into the shell. disadvantages
are that it is strictly one-way and it seems to be somewhat whacky (but
i must say, i'm obviously trained enough not to do the stupid things - i
didn't have problems with it for ages).
the second variant would be embedding the real shell prompt into the
panels. this could work by presenting the shell a really tiny pty. to
reduce clashes with the emacs keybindings (which are typically used by
shells, due to readline usage), mc would have to switch the meanings of
ctrl-p/-n with alt-p/-n and probably some more, also to maintain
consistency. command injection would happen in pieces, like when
pressing alt-a, making a completion, etc. the advantage would be the full
bidirectionality of the two views. disadvantages would be the loss of
mc's command history window (but honestly, i could not care less, as i'm
way faster with ctrl-r in the shell prompt anyway) and the potentially
very hard implementation - way more then the current one.
the third variant is the nc-like one where there is no real shell
prompt at all and the commander pretends to be the interactive shell in
both views. again, we would gain equivalence of the two views, would
keep mc's history (even with disabled panels), and we would not have to
detect whether the shell is idle, as there would be none. however,
implementing a feature set comparable with a modern unix shell (think
zsh) is an *imense* workload. given features like programmable
completion, i think it is actually impossible without completely merging
a real shell into mc, or, seen the other way round, making mc that
shell's shiny front-end. however, that would easily triple mc's size and
annoy all the people who are using one of the roughly three million
other shells we did not choose.
variant three is technically cleanest, but given the effort and the
incredible flaming potential i think it is outright unrealistic. and
extending mc's prompt just slightly and offering a castrated pseudo
shell prompt doesn't sound exactly desirable to me.
personally i'd go with variant two (unless somebody points out a
fundamental flaw in the idea (no, i'm not talking about implementation
problems)). to even think about that, we need to get the current code
working reliably. i'll investigate this myself - however, i won't make
*any* promises about the time frame.
btw, in any case, i think the mc command prompt should be able to grow
to a configurable number of lines (3 by default, maybe). currently
working with long paths (which i typically have in my multimedia
collection) is outright painful.
btw2, we need an alternative to alt-tab for completion, as alt-tab is
the sort-of-standard keybinding for switching windows in x and some
other well known OSs. i think it would make sense to have it on alt-c
(and have changeDir on alt-d - that's way more intuitive anyway. oh,
btw, i never used this quick cd - if the prompt is busy, i can either
navigate with ctrl-pgup/-pgdn or i simply ctrl-o into the shell).
btw3, i just found that we need a function follow symlink (presumably
mapped to alt-f) that would, well, guess what, set the current panel on
the target of the symlink the panel was on.
btw4, i should write fewer btws and file wishes instead. :)
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos,
