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)

[rmkaplan]

OK, thanks. Half way. There may be something else to do to arm it the other direction, although I think I followed Nick’s instructions. He may see the problem when he gets back.

…

On Mar 2, 2021, at 12:26 PM, Larry Masinter ***@***.***> wrote: 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) — 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/AQSTUJMPKHD6XOWTG4NAIXLTBVCY5ANCNFSM4YBMYRPQ>.

[rmkaplan]

In terms of deciding whether/how the clipboard is reference (xclip, pbpaste), the suggestion was made to invoke uname, but then not to do that every time (although this would only be invoked when meta-C/V are pushed, so in the noise).

A simple alternative would be for the run-medley to set a variable to the value of uname, and then clipboard could look at that variable.

[masinter]

uname has lots of options

   -s, --kernel-name
          print the kernel name

   -n, --nodename
          print the network node hostname

   -r, --kernel-release
          print the kernel release

   -v, --kernel-version
          print the kernel version

   -m, --machine
          print the machine hardware name

   -p, --processor
          print the processor type (non-portable)

   -i, --hardware-platform
          print the hardware platform (non-portable)

   -o, --operating-system
          print the operating system

I think fixing UNIX-GETPARM would be more straightforward.

[nbriggs]

See the uname table at Interlisp/maiko#129

[masinter]

after all of this discussion, copy/paste to/from Medley on a mac gives an error not finding xclip etc. becaus GETENV("OSTYPE") is NIL with the latest medley startup scripts.

[rmkaplan]

Works for me, on a mac. My .zshrc has a line at the top export OSTYPE=$OSTYPE Maybe that’s necessary?

…

On Jun 14, 2024, at 12:19 PM, Larry Masinter ***@***.***> wrote: after all of this discussion, copy/paste to/from Medley on a mac gives an error not finding xclip etc. becaus GETENV("OSTYPE") is NIL with the latest medley startup scripts. — Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJODFUZKV4FJHU62ILZHM635AVCNFSM6AAAAABJK4GHZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYGYYTSMRUHA>. You are receiving this because you authored the thread.

[masinter]

@rmkaplan you may have missed Interlisp/maiko#495

Calls to UNIX-GETPARM with argument "OSNAME" or "ARCH" now return values derived from the compile-time settings in inc/maiko/platform.h. Relates to Interlisp/medley#1596

The current return values are OSNAME:

• "macOS"
• "Cygwin"
• "DragonFly BSD"
• "FreeBSD"
• "Linux"
• "NetBSD"
• "OpenBSD"
• "AmigaOS 3"
• "Solaris"
• "Windows"
• "Emscripten"

ARCH:

• "WebAssembly"
• "x86_64"
• "arm"
• "arm64"
• "x86"
• "PowerPC"
• "RISC-V"
• "SPARC"
• "Motorola68K"

[rmkaplan]

Are you saying that CLIPBOARD now should be calling (UNIX-GETPARM "OSNAME") instead of (UNIX-GETENV "OSTYPE") ?

Still doesn't explain why it works for me the way it is.

[nbriggs]

If the test is purely "are we running on macOS, or not" then (UNIX-GETPARM "OSNAME") would be the right thing. If it's more complicated than that then we need to fill out the matrix of possibilities for what you need to call in which circumstance.

[masinter]

It's not clear what the "issue" is from this discussion.
There are some limitations of CLIPBOARD in some OSes, or some things need to be documented. But I can't see a solvable problem here without more analysis, so I'm converting this into a discussion