GNOME Bugzilla – Bug 679658
Expose functions for setting text selection [PATCH]
Last modified: 2018-04-30 07:41:52 UTC
Exposing functions for setting the selection allows applications to implement bindings for keyboard selection, which can be quite useful. The API provided by AtkText is not enough because it doesn't deal with rows and columns. This patch adds 3 new functions to the API (I've just copied the documentation here): * vte_terminal_get_selection_block_mode: * @terminal: a #VteTerminal * * Checks whether or not block selection is enabled. * * Returns: %TRUE if block selection is enabled, %FALSE if not * vte_terminal_set_selection_block_mode: * @terminal: a #VteTerminal * @block_mode: whether block selection is enabled * * Sets whether or not block selection is enabled. * vte_terminal_select_text: * @terminal: a #VteTerminal * @start_col: the starting column for the selection * @start_row: the starting row for the selection * @end_col: the end column for the selection * @end_row: the end row for the selection * * Sets the current selection region. I have a terminal at https://github.com/thestinger/termite which uses this to implement visual mode, visual line mode and visual block mode like vim.
Created attachment 218375 [details] [review] expand text selection API
I'm not sure this is the right way to support 'visual selection mode'. If we do want to support that (which I guess we do, since it makes selection keyboard-accessible), that support should be inside vte, not external like this... Behdad, what's your opinion on this?
I don't really know. First step would be to list requirements. What's desired that vte should do by default, and what's desired in the API?
It would be really nice to have internal support for keyboard selection, but I'm not sure how it could be done with a flexible interface. It can be done in a modal way like my implementation, or just with modifier keys. The API could definitely be more convenient and do more internally - vte_terminal_select_text requires figuring out different begin/end columns and rows depending on whether you want normal, line or block selection. Exposing 3 different functions for the types of selection (something like vte_terminal_select, vte_terminal_select_rows and vte_terminal_select_block) and hiding the fact that there's a block mode might be better and would make it a lot easier to implement for other terminals. At the moment the only thing that's really missing due to it being an external implementation is the ability to have a real cursor for the selection mode, but I'm planning on using an overlay for that.
*** Bug 721831 has been marked as a duplicate of this bug. ***
> IMHO keyboard selection should be done inside vte, not driven from outside like > this. So, I think there should be at least two public functions: one enable/disable selection mode and another for getting current mode. What if I'll try to migrate my patch for xfce4-terminal inside vte? It's really small.
Created attachment 284455 [details] [review] expand text selection API v2 I've attached the current patch I'm using, although I don't have much hope of this going anywhere. It exposes the ability to toggle block selection mode, toggle terminal output, set the cursor position and set the text selection. (I also exposed vte_terminal_get_user_shell_with_fallback simply because I was already requiring a patched VTE and it avoided a rewrite of the logic. That part is unimportant and can be ignored.) I don't think allowing this level of control over the cursor, output and selection is a bad idea. It does make the API surface larger, but not in a way that exposes a backwards compatibility risk. It makes VTE much more useful as a building block in applications, rather than just GNOME Terminal's backend. I plan on including Termite in the Arch Linux repositories, and since we have a policy against patching that means I'm going to be forced to fork VTE and then rebase a set of commits on top of GNOME's vte over and over. I would obviously prefer it if the public API could just be expanded a bit. Keeping the API minimal is a good ideal to strive for, but not when it means cutting off functionality that many people want.
Can this patch be reviewed? Would be nice to have.
Comment on attachment 284455 [details] [review] expand text selection API v2 Patch is against very old version (0.32), not applicable to master. Anyway, I still don´t think we should expose selection at this level; instead selection by keyboard should be handled inside vte. Also, exposing the internal PTY stuff is a no-go, and the shell fallback function doesn´t even exist anymore.
There's an up-to-date version of the patch, since it's being used by a maintained project: https://github.com/thestinger/termite/blob/master/expose_select_text.patch It exposes functions for pausing and resuming output, toggling block selection, setting the cursor position and setting the text selection. It needs to be modal in order to pause the output and provide sane bindings. One appropriate binding scheme is a Vim-like setup (which is used by many console programs like `less` already) but there are other options. Implementing this in VTE would mean ruling out having any flexibility in the terminal using the library. I haven't responded any more here because an implementation inside VTE won't satisfy the use case.
As for me, it sounds more reasonable to have this API exposed. At least, because different applications should be able to define different keybindings. Also, the desired behavior of visual selection may vary. So, I think that it's reasonable to allow application developers to use this feature in a way that is more natural for the final application.
(In reply to Daniel Micay from comment #10) > Implementing this in VTE would mean ruling out having any flexibility in the > terminal using the library. I haven't responded any more here because an > implementation inside VTE won't satisfy the use case. Implementing keyboard selection inside vte means that *every* terminal based on vte benefits; adding only hooks for you means that all the other terminals get *no* benefit. If there is an actual need for configurability, then *that* should be exposed as API.
Created attachment 303632 [details] URL hints mode via pausing / unpausing output An implementation within VTE is not going to be enough if it's not providing a solid Vim mode with dozens of movement bindings and Vimperator-like URL selection via hints. The latter depends on the ability to pause the output too in order to draw URL hints layered on top of the terminal widget in the correct location. The bindings would also need to be composable with counts and more to really be as usable as Vim too. It's not simply a matter of offering a configurable list of keybindings. I'm sure other people have similar use cases to the URL hints mode one, but aren't able to use VTE for it because the API doesn't offer what they need. I don't think there's any backwards-compatibility hazard from exposing the ability to set the selection and cursor position since the indexing system is *already* exposed in the API. Pausing and unpausing the output is even more benign. I don't understand why making this into a more useful library with seemingly no drawbacks wouldn't be a good thing.
Having the ability to pause the output is quite useful even in isolation from the rest. That would be enough for the URL hints mode, at least. Of course, those functions can be given better names than the current internal ones. Making these functions public doesn't make the project harder to maintain seeing as the coordinates are already exposed through APIs for getting the text selection and cursor position. The logic seems to be that if GNOME Terminal doesn't directly benefit, then it's not going to be exposed. That's not a good way to manage a library that's supposed to be useful to other people. I can't see features like a URL hints mode and Vim selection mode ever being implemented in VTE itself, and there's no way I'm going to spend time developing features for a GNOME project when I'm well aware that it's just going to be rejected off-hand even when it's being asked for. I've waited a really long time (almost 3 years) with no viable path forwards, so the only choice is to fork the project to expose a few simple functions.
Any future changes will be done here: https://github.com/thestinger/vte-ng
I'm a termite user and I'd really like to see VTE extended to handle other use cases other than just GNOME Terminal. I'd also like to see VTE extended so that I don't need to have multiples copies of VTE installed on my system. e.g. when using termite and having other terminals installed.
WONTFIX then.
This is disappointing, I thought VTE3 was supposed to be useful to other terminals other than GNOME Terminal.
Why is this a WONTFIX? Users would like to have termite, and now we have to package to vte versions, very annoying. Also I think Diego Viola tried to explain why it's needed and provided patches. The functionallity is good. If you think it should be implemented in another way it would be nice if this would happen.
(In reply to jubalh from comment #19) > Why is this a WONTFIX? > > Users would like to have termite, and now we have to package to vte > versions, very annoying. > > Also I think Diego Viola tried to explain why it's needed and provided > patches. The functionallity is good. If you think it should be implemented > in another way it would be nice if this would happen. I didn't write those patches, Daniel Micay (reporter) wrote them. But yes, I find the attitude of GNOME developers rather disappointing.
Hi Christian I found Termite application useful and I think that patch provided by Daniel is reasonable. Could you please share more information why don't you want to accept the patch? I guess there is one of two reasons: - There is better way to implement the same thing. Could you please tell us what that way is. - You are trying to create a walled garden [1] where only Gnome terminal can be useful with Gnome libraries. It it is true then it's highly disappointing to see such attitude in an open-source project. [1] https://en.wikipedia.org/wiki/Closed_platform
Hello, I too would like to see this functionality be exposed for other terminals to use. I am willing to contribute in case there is a problem with the patch, if there is no problem with it, why wouldn't you merge it? Regards
I am working on a separate terminal project, and I found the same limitation of VTE, these patches would be useful. Not sure I understand why this is marked as not fixed, perhaps VTE will provide the same functionality in a different way?
As someone who would like to try termite on Void Linux, I find it very frustrating, and rather disappointing, that I need to compile vte-ng rather than simply being able to use the vte3 package that Void supplies, which would be possible if this patch was applied. If this functionality is going to be implemented in another way, please let us know, if not, please use this patch, as it would be a great help to termite users and developers who want to create their own terminals alike.
Please merge this patch with VTE for allowing VTE to be better used by other users than Gnome-Terminal.
Stop polluting this bug with advocacy comments; see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html for bugzilla etiquette. This bug is closed and this patch rejected; the developer's response is in comment 9 and comment 12. Adding keyboard selection to vte will be done inside vte, see bug 78291 (don't add irrelevant comments there, either).
Keyboard text selection functions from VTE are also needed to implement this feature in Tilix https://github.com/gnunn1/tilix/issues/848
https://github.com/gnunn1/tilix/issues/1305
Again, please stop adding comments to this closed bug. See comment 26 and the info therein.