Hacker News new | past | comments | ask | show | jobs | submit login
Bracketed paste mode (2013) (cirw.in)
41 points by pmoriarty on Oct 30, 2018 | hide | past | favorite | 22 comments



Beware that some terminals implements bracketed paste mode in a way that doesn't protect you from malicious pastes.

For example, urxvt is broken in this regard, and the maintainer doesn't seem to be interested in fixing it:

https://bugs.debian.org/787628


This is a fascinating discussion on the philosophical differences in approaches to how pasting is supposed to work, and from skimming through it, it doesn't seem obvious to me which way is best. Reasonable people can disagree.


Note: The link to the readline manual is broken. It should be https://tiswww.cwru.edu/php/chet/readline/rluserman.html ; The server name has apparently changed from cnswww to tiswww.



Thanks jwilk!

Indeed a lot of this information is now quite outdated - thankfully people (e.g. vim) are beginning to implement it natively, and so I have basically deleted all of my own code and can use existing plugins.


I wrote the original xterm patch for this mode, to help the mouse mode of Joe's Own Editor. There were related additional features that didn't catch on:

A mode where you could read or set the selection data with base64 quoted strings. This gives the application full control over its interaction with X's cut & paste buffers. For example, if you Shift-select some text, the application can tell X about it so that other applications can paste. I think there is still an xterm configure option for this one.

The ability for the mouse to send motion events (when a mouse button is pressed) to the application even if it has gone beyond the terminal emulator's window border. It needs to be able to report negative coordinates when you are above or to the left of the window. This is needed to allow you to select text where the scrolling speed is controlled by how far beyond the border the mouse has moved. I still think this is needed, but patch not taken.

Incidentally, JOE has a hack for terminal emulators that don't have bracketed paste. If a new input character is immediately available after the previous character, then assume we have pasted text instead of typed. This works surprisingly well since the communication links tends to keep contiguous writes together in a single buffer.


"A mode where you could read or set the selection data with base64 quoted strings. This gives the application full control over its interaction with X's cut & paste buffers. For example, if you Shift-select some text, the application can tell X about it so that other applications can paste. I think there is still an xterm configure option for this one."

base64-encoded selection data sounds intriguing, but I'm not sure I understand what base64 has to do with the application being able to tell X about some text being selected.

And doesn't X already know when some text has been selected, simply from the contents of the primary selection having changed?


Suppose you select text with the keyboard- in JOE you can do this by holding down Ctrl and repeatedly hit arrow keys (actually there are many ways to this- ^KB ^KK marking is another). In most editors for Windows you can do it by holding Shift and hit arrow keys.

How is X supposed to know that you just made this selection? Normally it can not, because it's a tty/console application not in direct communication with the X server.

The base64 selection feature allows a console application to do it: the program can send selection text to X any time it wants: it's some header, base64 text, and a trailer. When the terminal emulator receives this, it forwards it to the X server just as if you had done a mouse selection.

The base64 is useful in the other direction (pasting into the terminal emulator running an editor). One minor advantage is that base64 is binary clean. Another is that the text is not just sent to the application- instead you get a sequence indicating that middle mouse button was pressed. The application then sends a request to the terminal emulator to have it send the paste data to the application. This is better because it allows you to paste by (for example) using an application specific keyboard sequence, not just a mouse action.


Oh, I see. I was thinking of mouse selections, which (in Linux anyway) will instantly make whatever you selected with the mouse available to X.

As to selecting text with the keyboard, Emacs at least does some magic to make copied text appear in the X primary selection. I personally find this more annoying than useful, as it clutters up my primary selection with random junk I've beeing editing in Emacs. So I personally prefer to only send the text to X when I deliberately call for it, by sending the text to the "xclip" utility as needed. It's possible to use the "xsel" utility as well.

I'm not sure what is the advantage of putting the terminal in to the middle of this process. Why can't applications just send whatever text they want to X by using xclip or xsel?

Pasting in to the terminal is another matter, of course, and I can understand the usefulness of being 8-bit clean and using base64.


You might be ssh'd to another system, so xsel / xclip will not work.


I wish I had seen this five years ago!

I'm always doing

    :set paste
and

    :set nopaste
whenever I need to paste text from other sources into vim. Or, rather, I would paste, see the crazy indents and comment characters auto-repeating, and have to decide if I should revert, issue the :set paste, and try again; or if it would be quicker to manually clean up what I just did.

I just added the code to my .vimrc. Works like a charm.


I’ve been using tpope’s excellent unimpaired.vim¹ to handle toggling paste for me², but will probably switch as vim-bracketed-paste is automatic.

I only bring up unimpaired.vim as it provides a whole heap of neat mappings for other toggles you might be manually performing. Most of which follow a simple pattern that makes them easy to remember.

I don’t believe any other plugin has increased my productivity as much as unimpaired.vim. Popping up the doc to link to the YOPO note I’ve realised just how many of those next/previous bindings I use as muscle memory.

¹. https://github.com/tpope/vim-unimpaired.git

². https://github.com/tpope/vim-unimpaired/blob/master/doc/unim...


Fantastic. This makes the following (very common) commands so much easier for me:

    :diffthis 
    :set [no]list
    :set [no]wrap
I know how to map shortcuts, but I never could bring myself to make them, because I've done that too many times in the past and end up with a mish-mash of private mappings that atrophy my vim skills in a way. Hope that makes sense.

But this plugin is super consistent internally. Great mnemonics. I don't mind coming to rely on it.

Thanks.


My solution to the atrophy thing is to keep my vim settings (and bash scripts aliases etc) on gitlab where they're always only one git clone away.


We are glad to hear that using GitLab helps you with your scripts and settings for vim. That's a really great approach.


In practice terminals have to behave in a slightly more complex fashion.

* https://news.ycombinator.com/item?id=16895939


It is important to spell the name of the readline setting correctly. The readline configuration parser is very bad at dealing with errors in its configuration file.

* https://unix.stackexchange.com/questions/356457/

* https://unix.stackexchange.com/questions/383670/


It's all fine and dandy until your ssh session dies and then pasting does weird things you don't understand.

iTerm2 can detect this if you install shell integration. I wish there were a more standard way to deal with this scenario, which affects everything in a terminal that has a mode (focus reporting, mouse reporting, application keypad mode, etc.).


Just use a shell alias for ssh that does a reset if the ssh command exits with an error code.


One of the best implementations of adaptive webpages for reading-oriented sites.


Yes, I like it too. I tried to resize the browser window horizontally and the page neatly splits the content in multiple columns. Very nice.


It’s pure CSS columns, and not updated since 2012 or so.. yay for the web.

I’m surprised they’ve not caught on more, but it is quite hard to control where column breaks end up in a way that lends itself nicely to evenly lengthed columns and to keeping headings near the paragraphs they’re describing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: