Timeline for Cannot paste text copied from Emacs to synchronous subprocess
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 13, 2020 at 7:29 | comment | added | kdb |
... though I lack a way to achieve the last idea, since async-shell-command with a process-live-p/sleep-for loop still blocks pasting :/
|
|
| Aug 13, 2020 at 7:21 | comment | added | kdb |
With the information gained from db48x's replay and NickD's comment, it looks like the solution on Linux is to ensure that xclipboard is running, but it isn't clear how to change the behavior on Windows without having the extraneous clipbrd.exe window open at all times. Probably the best solution will be to overwrite the M-! keybinding with something that behaves like shell-command from a user-perspective but keeps Emacs responsive. (It is a bit funny, that only Emacs brings up this issue; I know no other GUI program, where synchronous subprocess calls are common.)
|
|
| Aug 13, 2020 at 7:11 | comment | added | kdb |
Or maybe I am misunderstanding; Having clipbrd.exe open in the background prevents the synchronous subprocess from hanging on paste, so it probably kind of behaves like a graphical xclipboard. But when closing Emacs, the clipboard contents are retained which, as I understand, shouldn't be the case by default on Linux.
|
|
| Aug 13, 2020 at 7:10 | comment | added | kdb |
I just tested at home (Windows 10), and using kill-ring-save makes no difference. The options described in Chapter 12.3 are already enabled in the way that uses the clipboard. Regardless, running M-x shell-command notepad and pasting there causes Notepad to crash. Under windows, running xclipboard is no option either -- but the behavior is all the more unexpected, since in Windows having a program-independent clipboard buffer is the default behavior (viewable with clipbrd.exe).
|
|
| Aug 12, 2020 at 13:41 | comment | added | NickD |
AFAIK (and I may not know far enough), your paragraph about the clipboard is not quite right: there is a CLIPBOARD selection in X (in addition to primary and secondary selections) which acts as the destination of the usual Copy/Cut menu items of various applications but it behaves the same way as any other selection. What you are describing with the "clipboard manage" is what happens when somebody is running xclipboard - which is not always the case.
|
|
| Aug 12, 2020 at 10:20 | history | answered | db48x | CC BY-SA 4.0 |