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, panic, and disorder - my work here is done. _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
