New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring tty version to functional parity with wx version as close as possible #1101
Comments
It will never be just like, and these small lacks there and here will kill all taste of FAR:) FAR is good not cuz to its FAR, but cuz has many little things that makes life easier - spirit of (old good) Windows apps that was lost sometime/sometime :( Just few examples: BTW far2l is TUI application regardless if it uses GUI(WX) or TTY backend. |
Of course, it's best to keep maximum of the UX of Windows Far, and it makes sense to offer wx version by default in all cases then X is available. At the same time, we already offer a tty mode, and if this mode spoils the impression of far2l, it will hardly spoil it more with xclip support for example :) |
I'm used FAR in drop-down, quake-style terminals - both on Windows and on Linux. The WX version cannot be integrated into such terminals in any way. Therefore, I fully support the author of the topic - it would be very good if the headlights for the terminal were as close as possible to the supported functions with the WX version. |
X interactions in TTY mode (clipboard, keyboard modifiers probing) are complete! |
…rotocol improvements; classic TTY - shape of cursor (touch #1101)
window management (maximization, etc): |
Ctrl[+Shift]+digits now working in terminals in new ttyxi mode, great! NB, for slow/unstalbe connections it's better to run remote far2l inside local far2l to use far2l terminal extensions for smoother input. |
Now possible at least for: Details here: #1575 |
Some users do not want to leave their preferred terminal apps. Making tty version better will bring greater experience for such users, spreading far2l usage wider. Most of this work is already done, but there are still some minor issues left.
✓ Complex hotkeys, like Ctrl+Shift+arrows. Already supported in terminal. Single ESC press — also supported (an option in settings to enable it by default is appreciated).
✓ Mouse. Also already works in terminal.
Some terminal apps intercept some hotkeys used by far2l. It may be disabled in their settings (instructions on doing this may be added to far2l help optionally).
✓ X clipboard access
fallback to xclip as clipboard access method in TTY backend if far2l extensions are not available #810
Fallback clipboard set method is
OSC 52
support OSC 52 clipboard access escape sequences #641
Desktop notifications. We may fall back to
notify-send
if far2l extensions are not available✓ Cursor shape. There are escape seqs for modifying it:
https://www.freebsd.org/cgi/man.cgi?query=screen&apropos=0&sektion=4&manpath=FreeBSD+5.4-RELEASE&format=html
E[=s;eC
Set custom cursor shape, where s is the starting and e is the ending scanlines of the cursor.
Other options:
Escape sequence to change cursor shape kovidgoyal/kitty#715
https://unix.stackexchange.com/questions/49485/escape-code-to-change-cursor-shape
https://iterm2.com/documentation/2.1/documentation-escape-codes.html
Maybe we should make default cursor size 2px or 3px as in wx version, not 1px
BeginConsoleAdhocQuickEdit, GetLargestWindowSize, SetConsoleWindowMaximized — can be done by terminal emulators theirselves; also see https://invisible-island.net/xterm/ctlseqs/ctlseqs.html (look for "Window manipulation" string)
keydown/keyup events — no alfernative for terminal, I afraid. Isn't this functionality used in far2l for F* key suggestions only? UPD: can be solved by capturing X input, see better keyboard support in ttyx mode #1126
UPD2: now possible in some terminals, see support "rich keyboard" protocols by iTerm2/kovidgoyal's kitty/Windows Terminal #1575
SetFKeyTitles — no alfernative for terminal, I afraid
The text was updated successfully, but these errors were encountered: