GNOME Bugzilla – Bug 78291
selection through keyboard not possible
Last modified: 2021-06-10 12:35:20 UTC
I found that libzvt implements all the Atk text interfaces, but still selection of text through keyboard is not possible. I feel this is a critical keynav bug.
I have added Marc Mulcahy to the Cc list for this bug asI believe that he has looked at this issue.
reluctantly marking 2.0.1; marc, bill, any idea where we stand here?
Bottom line is we're probably waiting for someone (possibly me) to work out a keynav proposal for selecting text in a terminal, but it's a hard problem because of all the weird neolithic apps you can run in a terminal that want to use pretty much every keycombo you can imagine for themselves. I haven't even seen a terminal that allows arbitrary text selection that we could just copy :/
*** Bug 66713 has been marked as a duplicate of this bug. ***
Calum/all: I am not sure this is 'major', since text can be programmatically selected via at-spi API. It would be good to offer text selection directly, but of course the logical keybindings all conflict with console apps. One solution might be to add a 'select' item to the terminal menu, which could modally attach to caret motion and the shift key, and terminate the selection when either "Enter" or "Esc" was pressed (after which Shift/Enter/Esc keys would be passed to the application as normal).
Given bill's assessment, I've marked this down and removed some keywords. Would still be good to do, of course.
FWIW Bill's idea is probably the most reasonable one I've heard so far... and come to think of it I have seen terminals on Windoze that work that way (albeit not very well, but I'm sure we could do a much better job!)
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
vte is being used by gnome-terminal so closing as WONTFIX.
reopening and moving to gnome-terminal, since this was not fixed in vte (and probably should be implemented by gnome-terminal in conjunction with vte, assuming we want something like the suggestion I made in comment #5 and endorsed by Calum in #7)
I guess another way to implement this would be to be consistent with the caret selection modes in Firefox etc... hit F7 to enter the mode, use the standard GNOME text navigation/selection/clipboard keyboard shortcuts as required, and hit F7 again when you're done.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
I like Calum's idea of a F7-mode. It could make Jeff's keyboard navigable dingus idea from bug 143796 workable, too. Vte people, this should start there, I guess?
I like the idea too. Let Chris go wild ;).
Any sign of any wildness yet...?
No.. Chris showed his wildness in cairo land instead...
Well that's a long running 'bug'! So, well, yeah I'm basically bumping this bug. No point beating around the bush really ;) Are there any plans to implement something along these lines? The irony of the terminal being one of the main places I need to use my mouse is killing me ;)
*** Bug 672264 has been marked as a duplicate of this bug. ***
*** Bug 777405 has been marked as a duplicate of this bug. ***
Termite, and tmux both also have a separate "selection" or "copy" mode for selecting with the keyboard that is initialized by a single hotkey (Ctrl+Shift+Space for termite and "Ctrl+B [" for tmux). Also, the implementation of this should be general enough that the user could use vim, emacs, or arrow-key style navigation (configurably), and of course the hotkey to enter the mode should probably be configurable as well. I actually use tmux partly so I can get keyboard selection with tmux's copy mode. p.s. If this was resolved, termite probably wouldn't need to use a forked version of libvte.
> If this was resolved, termite probably wouldn't need to use a forked version of libvte. Assuming the solution is general enough that it's also possible to open a URL using the keyboard.
(In reply to astrothayne@gmail.com from comment #22) > > If this was resolved, termite probably wouldn't need to use a forked version of libvte. > > Assuming the solution is general enough that it's also possible to open a > URL using the keyboard. Full disclosure: I don't know a whole lot about libvte and its structure and development, so this might not align with goals or be hard to do, but what if we were to have it both ways? We could have the hooks suggested in bug 679658 allowing terminal emulators flexibility in how they used this functionality, but also have default bindings (which could be disabled by the terminal emulator) assigned to those hooks so that all existing vte terminals could benifit.
Duplicate of this bug: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/79 (IMHO, I would rather want to track this on GitLab, but this is your decicion.)
https://gitlab.gnome.org/GNOME/gnome-terminal/issues/79 has been confirmed and then closed by @axdoomer? And even locked… So should it be tracked here or what? In any case, I can still reproduce this bug and yes, it prints AD etc.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/588.