far2l
far2l copied to clipboard
elfmz
Scrolling in console, again
I think when Ctrl+O is pressed (in --tty mode at least), the terminal should turn into plain vanilla console. The same way as e.g. mc does it. With mouse scrolling working by default, with Cmd+F triggering built-in terminal app search etc.
Currently, when Ctrl+O is pressed and the panels are hidden, it's pretty hard to work with console (too many differences). Because that's the main purpose of Ctrl+O - to fallback to plain console.
(I know about Ctrl+Shift+F3, it is still not the best experience in comparison to the vanilla console. And Ctrl+Shift+MouseWheel doesn't work on MacOS at least, both in Terminal and in iTerm.)
Personally I like Ctrl+O the way it is. The only thing I hate is pressing F3 to scroll it. If there would be possible to use Up/Down/PgUp/PgDn to scroll the buffer without the need to invoke viewer it would be perfect. Ok, maybe not Up/Down because it scrolls history, but maybe Ctrl+Up/Ctrl+Down or something like that.
What you want is actually can be implemented via terminal emulator easily. For example, in Kitty you can make startup script which will open 2 tabs one with far, another with bash and bind tab switching hotkey in it to Ctrl+O. This way you would get the behavior like in MC (which I personally don't like, because it lacks context)
2 tabs won't be much useful, since the current directories will be independent there. The whole point of Ctrl+O is to keep the CWD the same as the active panel shows.
This ticket describes two different issues. The first is the behavior of the built-in console "like in mc." The second is adding a scrollbar to the console so that it can be scrolled with the mouse without needing to press any buttons.
Therefore, I am creating a separate ticket for scrollbar issue, here it is: #2644
As for the "vanilla" console in far2l, this behavior is intentional. I think @elfmz can provide more details about it.
I'd say scrolling the list of previously entered commands with the Mouse does not make much sense for me. I would rather stick to the vanilla behaviour (e.g. rather scrolling the screen)
Scrolling with the mouse click is also non-intuitive. When I click, I want to select the text. Instead the text scrolls somewhere away.
In case if Linux is your Desktop OS and you use SSH to the servers which do not have FAR installed, changes in behaviour kills. It even may cause the production issue if your action are hardcoded into the bones. It is hard to switch between the FAR and MC/Console.
When I click, I want to select the text. Instead the text scrolls somewhere away.
What you describes looks like behavior in Viewer. Its so from original FAR but for now in viewer you can do Shift + click to select and copy text. May be it makes sense to add option to reverse behavior - select by click and scroll by shift click..
