Emacs 29.1 released

Posted Aug 1, 2023 1:12 UTC (Tue) by flussence (guest, #85566)
In reply to: Emacs 29.1 released by NYKevin
Parent article: Emacs 29.1 released

My experience with the vim-ssh-X11 software tower is that copy and paste has only ever worked accidentally, and I've gotten used to the habit of doing a raw terminal text-select gesture and fixing it up by hand (or dropping to `less`).

If it's not *supposed* to suck then that's news to me…

Emacs 29.1 released

Posted Aug 1, 2023 1:20 UTC (Tue) by willy (subscriber, #9762) [Link] (2 responses)

I'm certain that sucking is by design. At some point recently Debian made it so I had to hold down shift while selecting to get the behaviour I'd become used to over the past twenty years of using vim. Just one more turd on the pile of shit.

Emacs 29.1 released

Posted Aug 1, 2023 9:31 UTC (Tue) by Sesse (subscriber, #53779) [Link] (1 responses)

To be fair, that was upstream, not Debian. But I still have “set mouse=” in my .vimrc, indeed.

Emacs 29.1 released

Posted Aug 2, 2023 1:15 UTC (Wed) by salewski (subscriber, #121521) [Link]

> To be fair, that was upstream, not Debian.

The upstream issue with a long discussion:

"Defaulting mouse=a in a terminal is incorrect (new as of 7.4.2111)"
https://github.com/vim/vim/issues/2841

> But I still have “set mouse=” in my .vimrc, indeed.

Same here.

Emacs 29.1 released

Posted Aug 1, 2023 1:50 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (3 responses)

It seems to work reliably for me as long as I do not exit vim before pasting (and as long as I'm content to wait a couple of seconds after pasting).

This is because of a rather unfortunate design decision on the part of X (basically, your clipboard is not a buffer, it is merely a reference to the X client that initiated the copy, so if that X client exits, then the clipboard is a dangling reference to nothing), which can cause problems even for local X clients (unless your DE takes responsibility for the clipboard data, which I know some DEs do). It would be fixed if vim used OSC-52, because then the X client responsible for the copy would be the terminal emulator, and not vim. It would also be fixed if we could somehow establish a protocol for vim to tell ssh to do the copy locally, but that would be rather silly since OSC-52 is a more general solution anyway.

X selection

Posted Aug 2, 2023 12:47 UTC (Wed) by jch (guest, #51929) [Link] (1 responses)

> This is because of a rather unfortunate design decision on the part of X (basically, your clipboard is not a buffer, it is merely a reference to the X client that initiated the copy,

There's a good reason for that: the X11 selection mechanism allows negotiating the format of a selection transfer: for example, a word processor can offer the selection as RTF, HTML and plain text, and the requestor can choose the format that it prefers. This allows evolving the protocol without breaking compatibility with existing applications, for example when we implemented Unicode copy-paste back in the late 20th century:

https://www.irif.fr/~jch/software/UTF8_STRING/UTF8_STRING...

If the selection were stored in the server, the application would need to transfer it in all supported formats every time the user selects something, possibly over a slow network connection.

> so if that X client exits, then the clipboard is a dangling reference to nothing)

No, if the selection owner closes the connection to the X server, the selection owner is set to NULL.

X selection

Posted Aug 3, 2023 19:04 UTC (Thu) by farnz (subscriber, #17727) [Link]

It's interesting to compare the (older) X11 mechanism to the Win32 clipboard mechanism in this regard.

In the X11 mechanism, the server provides the ability to own one or more selections; both cut and copy are "just" claiming ownership of a selection. Paste requires you to use the TARGETS atom to list possible formats, then choose one, then request a conversion to your preferred format; as an optimization, if you only support one possible format, you can ask for data in that format, and simply fail if the owner can't supply it. Once the data is converted to the right format by the owner, you can transfer it through the server.

Win32 is different in some significant ways:

Only one clipboard, rather than multiple selections.
Clipboard data formats are either "standard clipboard formats" (defined by the API), or "registered clipboard formats" (registered by name, multiple applications can register the same format.
There are built-in conversions between certain standard clipboard formats.
The default behaviour is to eagerly transmit the data to the server on cut/copy (via OpenClipboard/SetClipboardData/CloseClipboard), but an application can choose to merely indicate that it can supply the data in this format, and delay supplying it until it's requested.
You can send data to the server in multiple formats, which are expected to be different representations of the same data. Some of these can be delayed, others eager - for example, a word processor could eagerly supply the data as RTF (since that's what it has to hand), and offer delayed conversions to HTML and plain text. Or LibreOffice could eagerly supply in OpenDocument, with delayed conversions to RTF, HTML and plain text, but only where the data is small.
When the client requests the data, it asks the server to enumerate formats in preference order for the source. When it finds a format it's happy with, it asks for the data in that format. If it's a delayed offering, the server does IPC with the owner to get the conversion done, and then returns the data to the client as-if it were an eager offering.

It's worth noting that both mechanisms allow negotiating the format of a transfer; the primary difference is that the Win32 mechanism puts the data ownership in the server, and gives the owner no knowledge of when a paste happens (since it's implementation-defined when a delayed representation is requested by the server).

Emacs 29.1 released

Posted Aug 8, 2023 1:45 UTC (Tue) by repetitivestrain (guest, #165872) [Link]

(Speaking with my Emacs-on-X11-and-Wayland maintainer hat on.)

Revolving around selection ``ownership'' is not a bad design decision, it's a feature of the X inter-client communications convention. There are many different selections, most of which do not justify uploading the selection data to an X server or another form of specialized selection data storage.

For the selections that do warrant being saved after their owner windows are destroyed (CLIPBOARD is the only selection that comes to mind), users have the option of running a CLIPBOARD-managing client, which proactively monitors for changes in selection ownership, converts them to a number of specific targets and subsequently obtains ownership over them, or employing a clipboard manager, a client selection ownership and data will be transferred to when the original owner of the CLIPBOARD selection terminates.

The disadvantage of running a CLIPBOARD managing client is that you limit the flexibility of the protocol itself: for example, if your CLIPBOARD managing client only requests the STRING and COMPOUND_TEXT targets from your selection, then future attempts by other clients to insert the contents of CLIPBOARD won't be capable of receiving UTF-8 or file names from that selection; this is also compounded by how relegating the task of replying to selection requests to a separate client diminishes the ability of selection owners to provide feedback in response to selection requests (for example, there are several Emacs packages that provide visual feedback ranging from deactivating the region to beeping whenever another client attempts to insert the contents of the clipboard.)

Whereas with a clipboard manager, that flexibility is only lost once your client terminates. Lamentably, support for the clipboard manager protocol is rather lackluster, which is its sole disadvantage. I presume Vim doesn't support it; why not use Emacs instead?

Many lessons learnt during the long development of the X Window System appear to have been lost on the Wayland developers, but the selection transfer mechanism is not one of them. Wayland defines a single clipboard selection, but as with X, selection data is not uploaded to the display server. Instead, a token dubbed a data source is provided, and subsequent requests for selection data by other clients supply a FIFO which the creator of the data source is expected to write the requested data to.

In their inexorable quest to pastiche Microsoft Windows, GNOME's display server requests and saves the selection data itself every time a new data source is set, thereby serving as the Wayland analogy of a CLIPBOARD-managing client, making life difficult for the aforementioned Emacs packages. But I have to concede that the lack of a clipboard manager-esque protocol is a glaring omission in Wayland, and GNOME's manifesting the only means to provide users with behavior that they are already accustomed to.