Discussion of limitations of CLIPBOARD

[rmkaplan]

I pushed a new version that uses the mac pbpaste and pbcopy only if (UNIX-GETENV "OSTYPE") includes "darwin", otherwise defaults to "xclip" for both streams.

I don't know if this is correct, please test on all of your favorite platforms.

[masinter]

on Linux/wsl there is no "xclip", and I don't understand how it would work.
You need the OS Type of the X-server, not the medley process.

[rmkaplan]

Can you copy-paste between linux applications? If not, then I would just change clipboard so that at least it works between different windows in the same medley, for internal consistency. Otherwise, we have to figure out what the tie-in should be.

…

On Feb 23, 2021, at 11:10 AM, Larry Masinter ***@***.***> wrote: on Linux/wsl there is no "xclip", and I don't understand how it would work. You need the OS Type of the X-server, not the medley process. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJJBUAECTZ44PP6ZULTAP4THANCNFSM4YBMYRPQ>.

[nbriggs]

... I don't understand how it would work.
You need the OS Type of the X-server, not the medley process.

That is not correct. The command is going to be executed on the system where the lde process is running. The OS type of the server where the display is being presented is irrelevant. The clip/copy/paste command communicates with the (potentially remote) X server to deal with the text. [wrong!] -- the text gets stuffed into the command through a stream, but it's still running on the lde host, not the display host.

[nbriggs]

On most Linux distributions you can install the xclip package. Check and see if that's available under WSL.

[nbriggs]

If WSL is running Ubuntu, try "sudo apt install xclip"

[nbriggs]

In CLIPBOARD.PASTE.STREAM the call to xclip needs to be xclip -o (the default is xclip -i)

[nbriggs]

In fact, the best results (on a non-macOS system) may come from using the two commands

xclip -i -selection clipboard
xclip -o -selection clipboard

because then, if you are running on a remote machine, with display on a Mac, with clipboard/pasteboard sync turned on, the copy selections you make will be available in the Mac paste buffer to paste into any window not just within Medley.

[rmkaplan]

So it is still CREATE-PROCESS-STREAM, just with those elaborated arguments? Is there a way of testing whether xclip has been enabled? If it isn’t enabled, then I think the clipboard should just simulate an internal Medley stream. And presumably not bother with Unicode conversion. I’m unclear about the remote-machine scenarios. If I’m on my Mac (my display) but Medley is running on a remote machine: If I copy a medley string to the clipboard, would it be available to paste in other apps on the remote machine, or paste in other apps on my Mac If I am pasting into Medley, should I get strings only that were copied by another app on the remote machine, or copied by another app on my Mac Also: is it a reasonable assumption that all other external apps would traffic in utf-8/unicode strings, or should the format of the clipboard be a parameter of this little interface?

…

On Feb 23, 2021, at 1:00 PM, Nick Briggs ***@***.***> wrote: In fact, the best results may come from using the two commands xclip -i -selection clipboard xclip -o -selection clipboard because then, if you are running on a remote machine, with display on a Mac, with clipboard/pasteboard sync turned on, the copy selections you make will be available in the Mac paste buffer to paste into any window not just within Medley. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJM4ZPM4FNAS6BIXRPTTAQJPHANCNFSM4YBMYRPQ>.

[nbriggs]

Yes, it's still a CREATE-PROCESS-STREAM, but instead of just plain "xclip", use the elaborated arguments. The "-i ..." case is when you're sending TO xclip (the "pbcopy" case), the "-o ..." when you're receiving from xclip (the "pbpaste" case).

There isn't a low-cost principled way of deciding whether xclip is available. I think perhaps that attempting to (CREATE-PROCESS-STREAM "nonexistant-executable") should return NIL rather than a useless stream object.

I’m unclear about the remote-machine scenarios.
	If I’m on my Mac (my display) but Medley is running on a remote machine:
		If I copy a medley string to the clipboard, would it be available to
			paste in other apps on the remote machine, or
			paste in other apps on my Mac
        -- it's available in the CMD-V paste buffer, so you can paste it into terminals
    connected to anywhere and to apps that are running with windows on your Mac.

		If I am pasting into Medley, should I get strings only that were
			copied by another app on the remote machine, or
			copied by another app on my Mac
        -- it will be anything that is in your paste buffer, so if you did a CMD-C in any
    window displaying on your Mac (that has selectable text in it) you will be able
    to META-V paste it into Medley.

The options in the XQuartz preferences say whether the X clipboard should be copied in and out of the macOS pasteboard (which is what pbcopy and pbpaste work on). pbcopy and pbpaste have arguments that can change their behavior too, documented in the man pages.

I would assume that all other applications are trafficking in UTF-8 strings.

[masinter]

the days of non-UTF8 are over (except for legacy cases like ours). The Unicode problem I'm worried about is the possibility of Lisp doing normalization when reading in character mode, but assigning "looks" by byte and not number of characters.. Also marking and marking tedit and lisp files with their charset
I went to try out the clipboard
hello.txt
but where is the version you want others to test

[waywardmonkeys]

In the long run, I think that this needs to be a subr so that maiko can provide the correct implementation per platform. Running natively on macOS or Windows would need different code from running within X, as would running via WebAssembly in the browser.

[nbriggs]

Running natively on macOS should still be fine with pbpaste and pbcopy, shouldn't it? Those know nothing about X. We're just executing them to stuff strings into or retrieve strings from the native system pasteboard. When lde isn't executing on a mac, and we're not running under X then we have a problem if we're trying to share strings with applications outside lde and there isn't a command line method to access the system pasteboard. If Medley were just trying to implement copy/paste within the Lisp world it wouldn't bother with external programs.

[rmkaplan]

Test CLIPBOARD.LCOM (but I just pushed a new version) The XCCS character sets that UNICODE loads by default are (LATIN SYMBOLS1 SYMBOLS2 EXTENDED-LATIN FORMS SYMBOLS3 SYMBOLS4 ACCENTED-LATIN) So test characters in some of those sets.

…

On Feb 23, 2021, at 9:06 PM, Larry Masinter ***@***.***> wrote: the days of non-UTF8 are over (except for legacy cases like ours). The Unicode problem I'm worried about is the possibility of Lisp doing normalization when reading in character mode, but assigning "looks" by byte and not number of characters.. Also marking and marking tedit and lisp files with their charset I went to try out the clipboard hello.txt <https://github.com/Interlisp/medley/files/6033490/hello.txt> but where is the version you want others to test — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJM6M2V37TULVV2W7TTTASCPHANCNFSM4YBMYRPQ>.

[rmkaplan]

Yes, the whole point is to let stanard copy/paste move strings to/from medley and other applications, in a lightweight way—without going through files. What is getting a little murky is understanding the geographic relationship between Medley and which other applications are in scope. Moving strings around inside Medley is a nice side-effect, for consistency, but it isn’t the motivation. (Inside Medley it does have a nice little extra feature: you can copy once and then paste in many locations, something you can’t do with the Medley copy-select convention.)

…

On Feb 23, 2021, at 9:42 PM, Nick Briggs ***@***.***> wrote: Running natively on macOS should still be fine with pbpaste and pbcopy, shouldn't it? Those know nothing about X. We're just executing them to stuff strings into or retrieve strings from the native system pasteboard. When lde isn't executing on a mac, and we're not running under X then we have a problem if we're trying to share strings with applications outside lde and there isn't a command line method to access the system pasteboard. If Medley were just trying to implement copy/paste within the Lisp world it wouldn't bother with external programs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJ43R2AWJH7WNZ5LPDTASGS3ANCNFSM4YBMYRPQ>.

[masinter]

I tested on Windows/WSL and it seemed to work to copy things from outside medley to inside.
No luck the other way (copy from inside Medley to another windows or wsl/X app)