Bracketed Paste

JorwLNKwpH commented

2021-01-20 15:31:02 +00:00

Can foot support bracketed paste? Or did I miss this option somewhere?

dnkl commented

2021-01-20 16:45:07 +00:00

Owner

Foot does support it. There are no options related to it (like disabling it permanently).

How/where is it not working?

Foot does support it. There are no options related to it (like disabling it permanently). How/where is it not working?

JorwLNKwpH commented

2021-01-20 16:51:18 +00:00

Poster

Multi-line paste is broken on an irc client, while libvte and kitty work correctly.

Foot automatically pastes each line individually, while the other terminals do not automatically paste anything.

Multi-line paste is broken on an irc client, while libvte and kitty work correctly. Foot automatically pastes each line individually, while the other terminals do not automatically paste anything.

dnkl commented

2021-01-20 16:54:18 +00:00

Owner

Not working at all, or messing up the multi-line part?

JorwLNKwpH commented

2021-01-20 17:16:21 +00:00

Poster

http://thejh.net/misc/website-terminal-copy-paste

Not sure if this is related, but foot fails the second test.

http://thejh.net/misc/website-terminal-copy-paste Not sure if this is related, but foot fails the second test.

dnkl commented

2021-01-20 17:19:34 +00:00

Owner

That doesn't sound like the same issue. Foot fails to filter out the "bracketed paste" end sequence. I.e. the second test explicitly disables bracketed paste before doing its evil stuff.

Your issue probably has to do with line endings.

That doesn't sound like the same issue. Foot fails to filter out the "bracketed paste" **end** sequence. I.e. the second test explicitly disables bracketed paste before doing its evil stuff. _Your_ issue probably has to do with line endings.

dnkl added the

bug

label 2021-01-20 17:24:26 +00:00

dnkl referenced this issue from a commit

2021-01-20 18:21:00 +00:00

selection: replace \r\n and \n with \r, and strip \e from pasted text

dnkl referenced a pull request that will close this issue

2021-01-20 18:23:53 +00:00

Strip control characters from pasted text #307

dnkl commented

2021-01-20 18:24:37 +00:00

Owner

@JorwLNKwpH can you test #307?

I think it fixes your issue, but I'm not sure, since I haven't been able to reproduce it in any application.

@JorwLNKwpH can you test https://codeberg.org/dnkl/foot/pulls/307? I _think_ it fixes your issue, but I'm not sure, since I haven't been able to reproduce it in any application.

JorwLNKwpH commented

2021-01-21 06:52:40 +00:00

Poster

The issue here is caused by foot not sending BRACKETED_PASTE terminal mode to notify the application.

dnkl commented

2021-01-21 10:10:34 +00:00

Owner

Foot automatically pastes each line individually, while the other terminals do not automatically paste anything.

I didn't see this until now. I think there's some confusion about what bracketed paste really is.

It is not about the terminal preventing, or requiring confirmation before pasting multiline text. Nor is it required to filter out any characters.

When bracketed paste is enabled, the terminal will wrap all pasted text in \E[200~ TEXT TEXT \E[201~. This allows the application to differentiate between typed text, and pasted text.

This means there's actually no reason to ask for confirmation before pasting multiline text when bracketed paste mode has been enabled, since the application is expected to be able to deal with it by itself. That's the whole point with bracketed paste mode.

Zsh, for example, supports and enables bracketed paste. This is why, when I paste

echo hello world
ls /usr/bin
cat /etc/passwd

it doesn't execute the above, as can be seen in the screenshot.

To enable bracketed paste mode, the application must send \E[?2004h to the terminal.

> Foot automatically pastes each line individually, while the other terminals do not automatically paste anything. I didn't see this until now. I think there's some confusion about _what_ bracketed paste really is. It is **not** about the terminal preventing, or requiring confirmation before pasting multiline text. Nor is it required to filter out any characters. When bracketed paste is enabled, the terminal will wrap all pasted text in `\E[200~ TEXT TEXT \E[201~`. This allows the application to differentiate between typed text, and pasted text. This means there's actually **no reason** to ask for confirmation before pasting multiline text when bracketed paste mode has been enabled, since the application is expected to be able to deal with it by itself. That's the whole point with bracketed paste mode. Zsh, for example, supports and enables bracketed paste. This is why, when I paste ```sh echo hello world ls /usr/bin cat /etc/passwd ``` it doesn't execute the above, as can be seen in the screenshot. To enable bracketed paste mode, the application **must** send `\E[?2004h` to the terminal.

zsh-bracketed-paste.png

1.7 KiB

dnkl referenced this issue

2021-01-21 10:20:16 +00:00

Strip control characters from pasted text #307

JorwLNKwpH commented

2021-01-21 21:34:49 +00:00

Poster

To enable bracketed paste mode, the application must send \E[?2004h to the terminal.

Is this missing from the foot terminfo by any chance? Because launching the application with TERM=xterm-256color on foot doesn't seem to run into this issue (also alacritty seems broken as well in case that's relevant).

>To enable bracketed paste mode, the application must send \E[?2004h to the terminal. Is this missing from the foot terminfo by any chance? Because launching the application with `TERM=xterm-256color` on foot doesn't seem to run into this issue (also alacritty seems broken as well in case that's relevant).

craigbarnes commented

2021-01-22 04:08:30 +00:00

Collaborator

Is this missing from the foot terminfo by any chance? Because launching the application with TERM=xterm-256color on foot doesn't seem to run into this issue

There's no terminfo capability for enabling bracketed paste, although it's possible that your shell only sends \E[?2004h when $TERM matches some known value.

What shell are you using?

> Is this missing from the foot terminfo by any chance? Because launching the application with `TERM=xterm-256color` on foot doesn't seem to run into this issue There's no terminfo capability for enabling bracketed paste, although it's possible that your shell only sends `\E[?2004h` when `$TERM` matches some known value. What shell are you using?

JorwLNKwpH commented

2021-01-22 07:10:19 +00:00

Poster

I'm using fish; I'll try some other shells and report back.

Update: Using foot with foot terminfo on dash or bash does not change anything.

Note that kitty works with kitty terminfo on fish. It could be that the application only detects bracketed paste for certain TERMs.

I'm using fish; I'll try some other shells and report back. Update: Using foot with foot terminfo on dash or bash does not change anything. Note that kitty works with kitty terminfo on fish. It could be that the application only detects bracketed paste for certain `TERM`s.

dnkl commented

2021-01-22 08:33:00 +00:00

Owner

@JorwLNKwpH remember that the shell will turn off bracketed paste before starting an application. Applications need to enable bracketed paste themselves.

And yes, some applications have the bad habit of checking the name of the terminfo (typically looking for the substring xterm, which is why kitty's terminfo is named xterm-kitty).

Is the sources of this IRC client available for browsing somewhere? Should be pretty easy to see if/how/when it enables bracketed paste.

@JorwLNKwpH remember that the shell will turn **off** bracketed paste before starting an application. Applications need to enable bracketed paste **themselves**. And yes, some applications have the bad habit of checking the _name_ of the terminfo (typically looking for the substring `xterm`, which is why kitty's terminfo is named `xterm-kitty`). Is the sources of this IRC client available for browsing somewhere? Should be pretty easy to see if/how/when it enables bracketed paste.

dnkl commented

2021-01-22 08:36:48 +00:00

Owner

Note: I don't see why one would bother checking terminfo at all before enabling bracketed paste.

All terminals should ignore the \E[?2004h sequence if they don't support it.

And to the application there's no difference between having tried to enabled bracketed paste, and not enabling it at all. Hence it's better to just try to enable it on all terminals. If it works it works.

Note: I don't see why one would bother checking terminfo **at all** before enabling bracketed paste. All terminals should ignore the `\E[?2004h` sequence if they don't support it. And to the application there's no difference between having **tried** to enabled bracketed paste, and not enabling it at all. Hence it's better to just try to enable it on all terminals. If it works it works.

dnkl commented

2021-01-22 08:42:38 +00:00

Owner

FWIW, fish does enable bracketed paste in foot with TERM=foot.

FWIW, fish **does** enable bracketed paste in foot with `TERM=foot`.

dnkl added

not-a-bug

and removed

bug

labels 2021-01-22 09:18:32 +00:00

JorwLNKwpH commented

2021-01-22 11:09:53 +00:00

Poster

Thanks for the insight. I checked the source code, and it does appear (afaict) to be using terminfo-based checking with xterm as a special case :(

Closing this since the other bracketed/non-bracketed paste issues can be tracked elsewhere.

Thanks for the insight. I checked the source code, and [it](https://github.com/jtdaugherty/vty) does appear (afaict) to be using terminfo-based checking with xterm as a special case :( Closing this since the other bracketed/non-bracketed paste issues can be tracked elsewhere.

JorwLNKwpH closed this issue

2021-01-22 11:09:53 +00:00

dnkl commented

2021-01-22 12:19:51 +00:00

Owner

vty bundles "bracketed paste mode" with other XTerm extensions that aren't available as terminfo capabilities:

Another note is that this will only allow these modes to be enabled in xterm-like terminals (TERM looks like xterm or screen); terminals that use the TerminfoBased driver don't support these modes yet. That's because terminfo doesn't expose capabilities for these modes so I can't safely enable them.

https://github.com/jtdaugherty/vty/issues/100#issuecomment-228617507

vty bundles "bracketed paste mode" with other XTerm extensions that aren't available as terminfo capabilities: > Another note is that this will only allow these modes to be enabled in xterm-like terminals (TERM looks like xterm or screen); terminals that use the TerminfoBased driver don't support these modes yet. That's because terminfo doesn't expose capabilities for these modes so I can't safely enable them. https://github.com/jtdaugherty/vty/issues/100#issuecomment-228617507

dnkl referenced this issue from a commit

2021-01-23 09:46:03 +00:00

selection: replace \r\n and \n with \r, and strip \e from pasted text

dnkl referenced this issue from a commit

2021-01-26 18:31:27 +00:00

selection: replace \r\n and \n with \r, and strip \e from pasted text

dnkl referenced this issue from a commit

2021-01-26 19:51:02 +00:00

selection: replace \r\n and \n with \r, and strip \e from pasted text

craigbarnes referenced this issue

2021-01-31 12:33:01 +00:00

Confirm before pasting multi-line text in non-bracketed paste mode #308

~~craigbarnes referenced this issue 2021-01-31 12:33:23 +00:00~~

Confirm before pasting multi-line text in non-bracketed paste mode #308

Bracketed Paste #305