Topic on Talk:Talk pages project/Updates

Reason: I am using Linux and there you can copy/paste with ^C/^V and you have a second copy/paste buffer with simple select and then insert with the middle mouse button. This second copy/paste is very useful when you want to copy two text parts from another browser tab.

Problem 1: Copy/Paste with the middle mouse buttons does not always work. Problem 2: When copy/paste with the middle mouse button at a certain position, the text gets inserted at the cursor position, the usual behavior is at the mouse position.

A seldom problem: When you write an answer and use some <pre> </pre> block, it seems to get garbled, at least the preview just below does not look as expected.

As a temporary workaround, you can turn off the source mode toolbar in your preferences. This switches to a basic <textarea>, which should support middle-click paste (and copy-by-select) without any issues. (If it doesn’t, it’s your browser’s fault.) However, this will be removed sooner or later. By the way, StructuredDiscussions (the discussion tool used on this very talk page) uses the same technology under the hood as DiscussionTools with toolbar, and I don’t remember having issues with middle-click paste (problem 1) here. (I turned off the source mode toolbar of DiscussionTools for another reason.) I can reproduce problem 2, although I don’t think I’ve ever run into this on my own.

Multi-line tags like <pre> are currently officially unsupported—right now, all lines are indented with colons, so the preview correctly shows how broken it would be after saving. I hope this will be fixed once, but it seems like it’s not the developers’ priority.

The middle mouse buttons actually inserts something, sometimes the selection just marked with the mouse but too often the selection in the CTRL-C/Ctrl-V buffer. Since I am more active in the tech area and not so much in the writing of articles, I use the <pre> often.

Structured discussions are not enabled on deWP, I have used them on wikidata, but very few.

However, thanks for the answer!

The workaround mentioned by @Tacsipacsi will not work forever though, as we plan to remove the <textarea> mode eventually (T276607)

Filed T311701, T311723 and T311733.