Drop into shell about lf HOT 10 CLOSED

@for-coursera You're right, I don't think there is a real solution to that when using external programs since they all want to handle the terminal in their own way and we have no choice but to pause and then resume the terminal afterwards.

from lf.

You can drop to the shell in the current directory using something like !bash which can be mapped to a key with map S !bash. $bash used to work as well but at some point I changed $ commands to use stdout without closing termbox so the screen wouldn't flicker for short commands. Some applications get buggy with it though so we may revert back the changes at some point if we decide this is a worse tradeoff.

from lf.

Ah, nice. I see that it is even possible to do !$SHELL to drop to my shell (I use zsh).
One thing I don't like is that when I close that shell (CTRL-D), it tells me to "Press any key to continue". I'd like to go back to lf directly.

from lf.

Yes, that's what I meant when I said $bash used to work. Instead of the change I mentioned above, I guess we can also introduce a different type of command that will close termbox during the process without the waiting afterwards but too many different command types could be icky.

from lf.

Right on, I should have re-read the docs beforehand, sorry. Well, I'm not sure how to handle that either, will have to think about it.
But I've noticed that the $ still tends to flicker, e.g. on commands that fork into GUI app, such as

cmd open-file $open $fx

The open cmd is a default opener on macOS. I've tried opening some text files in the TextEdit app and saw lf flickering below it.

from lf.

For now termbox is still restarted for $ commands (see 66ce56e) but this happens after the command is executed not during the execution. So there might still be flickering as you mention depending on the terminal. These flickers are much brief though. Imagine if you were to run a command such as $sleep 1 you would easily notice the difference between two approaches. I would like to solve this problem and then remove termbox restart instead of reverting the change but I still need to understand how exactly this happens.

from lf.

I have reverted the change I mentioned since it was doing much harm than good, at least until I can find a clean solution. Also added the shell example to lfrc.example. Closing this issue now.

from lf.

Fine by me. I see now that there's much more noticeable gap using my example above, but that doesn't really bother me. It seems that ranger has that too, anyway, and I've never really noticed.

from lf.

Maybe you can use an async command (&) to launch your editor. Since it doesn't close termbox it shouldn't flicker at all. I understand this is not always possible though.

from lf.

(Sorry for a very late comment :))

While using an async command (&) to launch an app indeed solves "the flickering problem" for GUI apps, it still would be great to avoid those, well, moments of blackness for applications that launch in the same terminal (for mappings like this map i $$PAGER $f etc -- and you can't use & for those, right? )

But I'm afraid there's no real solution for that? The only example coming to my head that seems to avoid that flickering is Midnight Commander when using internal viewer and editor, and as soon as you switch to external programs, the flickering re-appears :)

from lf.