Feature Request: Ability to select text with the keyboard (vim-like)

[pjrt]

urxvt has the ability to select text using just the keyboard. By hitting a key you enter into something akin to Vim's normal mode (where you can move the cursor with your keyboard and select text using v). I found this to be a great productivity boost and would be great if kitty supported it as well.

[kovidgoyal]

You can open the contents of the kitty screen/scrollback buffer in any arbitrary program
you like, including vimpager. https://sw.kovidgoyal.net/kitty/conf.html#shortcut-kitty.Browse scrollback buffer in less

[pjrt]

vimpager doesn't really allow for vim-like selection (or at the very least I can't figure out if it does).

But I was able to do so with neovim and its pager mode. For future reference:

scrollback_pager nvim -c 'set ft=man' -

It isn't as fast as urxvt (since it needs to launch a program), nor are pretty (urxvt just "uncages" the cursor), but it will will do for now.

Still think it would be a great feature to support natively.

[kovidgoyal]

To me the ability to use dedicated programs is far superior to using some kind of builtin mode. In your own example, you can take advantage of all the power of vim, which no dedicated mode is ever going to match.

I haven't used urxvt but I highly doubt it supports the level of sophistication in searching/cursor movement/etc. that vim does.

[pjrt]

It does not, of course. But that wouldn't be the point, the point would be speed. Opening anything (except for many less) is gonna take several hundreds of millis.

[kovidgoyal]

really? vim opens on my system in 27 milliseconds

time vim -u NONE -c exit 
0.02s user 0.01s system 96% cpu 0.027 total

[pjrt]

yeah I just figured out that I was missing -u NONE. Which makes sense, my plugins are gonna slow things down. Ok, this should be enough. Thanks!

[RosalesJ]

Unfortunately with -u NONE you get ANSI color codes breaking everything up. I can't find a way to get rid of those without loading packages and slowing down startup. Any suggestions on how to proceed?

This has my vote for a feature request: AFAIK there aren't any good options when it comes to pagers that allow native selection and are fast enough on startup.

[kovidgoyal]

I seriously doubt that loading the package to parse ansi color codes could materially affect startup times. But even if it did, use the pipe function in kitty to pipe plain text without ansi codes instead. Then you can use -u NONE

[RosalesJ]

I've been using scrollback_pager vim -u NONE so far and it works fine except for the ANSI codes mentioned earlier, but I don't think you can enable raw text with this option. So I tried using map f1 pipe @ansi overlay less +G -R as in the docs but it does nothing without any errors. I've tried adding @screen and @text as well with no luck.

Additionally, using this method the cursor always starts on the beginning of scroll-back instead of at the last prompt, you have to type three keys to get out :q!, and using text editors as pagers generally doesn't work very well.

[kovidgoyal]

that stack exchange post is just a bunch of hand waving about how vim wont work well in some terminals as a pager. It works fine in kitty. And the example command using pipe works fine for me. You are probably confused by the fact that on running it the screen does not change, since it basically shows you the screne contents but inside less.

and it is trivial to pass commands to vim on startup if you need the cursor to go to the bottom. One of the many advantages of using something as powerful as vim as apager.

[yurikhan]

I can understand your position on not including a copy mode implementation in kitty. Different people would want different things and it would either evolve into creeping featurism or leave some people dissatisfied.

However, in order to say that it’s trivial to implement using an external program in a scrollback_pager or pipe command, kitty should pass to that program at least the following:

• Scrollback buffer text (optionally with formatting) — via stdin
• Scroll position — INPUT_LINE_NUMBER in scrollback_pager
• Cursor position, so that the external program would be able to start out with the screen laid out exactly the same way as it was

The external program can then implement its own ideas of cursor motion, selection, and confirmation or cancellation. It will also have to solve the problem of copying the selection to the clipboard and having it persist beyond its own termination — possibly by spawning nohup xclip.

I think it would be pretty easy to extend Window.show_scrollback to pass cursor position analogously to INPUT_LINE_NUMBER. I must ask, however, why is that implemented as text substitution? I’d probably choose carefully named environment variables.

Also, scrollback_pager looks very similar to pipe @ansi overlay; would it be a good idea to extend pipe so that it would be able to replace scrollback_pager completely?

[kovidgoyal]

On Sat, Nov 24, 2018 at 12:19:56PM -0800, Yuri Khan wrote: I can understand your position on not including a copy mode implementation in kitty. Different people would want different things and it would either evolve into creeping featurism or leave some people dissatisfied. However, in order to say that it’s trivial to implement using an external program in a `scrollback_pager` or `pipe` command, kitty should pass to that program at least the following: * [x] Scrollback buffer text (optionally with formatting) — via stdin * [x] Scroll position — `INPUT_LINE_NUMBER` in `scrollback_pager` * [ ] Cursor position, so that the external program would be able to start out with the screen laid out exactly the same way as it was

Cursor position can be queried via escape codes, but sure, it is trivial to add as an env var along with the scroll position for pipe

The external program can then implement its own ideas of cursor motion, selection, and confirmation or cancellation. It will also have to solve the problem of copying the selection to the clipboard and having it persist beyond its own termination — possibly by spawning `nohup xclip`.

There is no such problem, it can use the OSC 52 escape code to have kitty do the copying for it.

I think it would be pretty easy to extend `Window.show_scrollback` to pass cursor position analogously to `INPUT_LINE_NUMBER`. I must ask, however, why is that implemented as text substitution? I’d probably choose carefully named environment variables.

Because scrollback_pager is meant to work with external programs not designed for it, like less. less needs it as a command line argument, not an env var.

Also, `scrollback_pager` looks very similar to `pipe @Ansi overlay`; would it be a good idea to extend `pipe` so that it would be able to replace `scrollback_pager` completely?

No scrollback_pager will remain for legacy compat and to make the simple use case of browsing history in a pager straightforward.

[yurikhan]

Cursor position can be queried via escape codes

Hm, is that right? I assumed the commands run by scrollback_pager and pipe start out in a new window, with its own cursor position (initially at 0, 0).

The external program […] will also have to solve the problem of copying the selection to the clipboard and having it persist beyond its own termination — possibly by spawning nohup xclip.

There is no such problem, it can use the OSC 52 escape code to have kitty do the copying for it.

Assuming the clipboard_control setting allows it. And there are reasons to block both reading and writing the clipboard. While allowing reading exposes the user to information disclosure, allowing writing sets up denial of service: a malicious program can repeatedly set the clipboard to a random value, thereby preventing its normal use.

Or are these windows exempt from clipboard_control protection?

why is that implemented as text substitution? I’d probably choose carefully named environment variables.

Because scrollback_pager is meant to work with external programs not designed for it, like less. less needs it as a command line argument, not an env var.

Environment variables would work if scrollback_pager and pipe started their external programs via shell, or by using shell explicitly:

scrollback_pager $SHELL -c "less -RS +$KITTY_TOP_LINE"

[kovidgoyal]

On Sun, Nov 25, 2018 at 12:42:13AM -0800, Yuri Khan wrote: > Cursor position can be queried via escape codes Hm, is that right? I assumed the commands run by `scrollback_pager` and `pipe` start out in a new window, with its own cursor position (initially at 0, 0).

The cursor is the overlay window can simply be psitioned atthe same position as the origin window to start with.

>> The external program […] will also have to solve the problem of copying the selection to the clipboard and having it persist beyond its own termination — possibly by spawning `nohup xclip`. > > There is no such problem, it can use the OSC 52 escape code to have kitty do the copying for it. Assuming the `clipboard_control` setting allows it. And there are reasons to block both reading and writing the clipboard. While allowing reading exposes the user to information disclosure, allowing writing sets up denial of service: a malicious program can repeatedly set the clipboard to a random value, thereby preventing its normal use. Or are these windows exempt from `clipboard_control` protection?

No they are not, I really dont see what on earth a DoS attack against a local clipboard would achieve. And any program can write to the clipboard, at any time, so if you dont trust the programs running on your machine, turning off write in clipboard-control is meaningless.

>> why is that implemented as text substitution? I’d probably choose carefully named environment variables. > > Because scrollback_pager is meant to work with external programs not designed for it, like less. less needs it as a command line argument, not an env var. Environment variables would work if `scrollback_pager` and `pipe` started their external programs via shell, or by using shell explicitly: ``` scrollback_pager $SHELL -c "less -RS +$KITTY_TOP_LINE" ```

Sure, but the point is to make them simple to use. You are essentially proposing wrapping the external program in a mini shell program. Why bother?