Bracketed paste mode (2013)
cirw.in
cirw.in
For example, urxvt is broken in this regard, and the maintainer doesn't seem to be interested in fixing it:
https://github.com/ConradIrwin/conradirwin.github.com/pull/3
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.
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.
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?
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.
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.
I'm always doing
:set paste
:set nopaste
I just added the code to my .vimrc. Works like a charm.
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...
:diffthis
:set [no]list
:set [no]wrap
But this plugin is super consistent internally. Great mnemonics. I don't mind coming to rely on it.
Thanks.
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.).
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.