Befuddling behavior with Visual Studio Code

Questions & Suggestions
1

I was working on another macro, and having really weird issues with the clipboard and VS Code. So I built a very simple test macro:

image
image1040×1412 115 KB

If I run that using BBEdit, with this in the editor and selected:

This is BBEdit

Then here's what the clipboard looks like afterwards:

image
image1224×1056 102 KB

Which is exactly what I would expect. If I change the macro to run VS Code, though, with This is VS Code selected, here's what I get on the clipboard:

image
image1224×764 88.6 KB

Duplicate entries is definitely not what I expected.

VS Code is cross platform, and it does have other oddities in the copy/paste realm—the Edit > Copy command is always enabled, even with nothing selected, for instance.

Another even worse oddity: The KM Copy action will simply time out, so you have to use the Copy item in the Edit menu (which you have to KM-Action click first, then action-click again to get Copy). But using that menu item action gets you this on the clipboard if there's no selection:

image
image970×126 15.4 KB

You don't get this if you use Command-C directly in VS Code with nothing selected—it just copies nothing, as you'd expect. Weird. (Well, you might expect Copy to not be enabled without a selection, but that's not the case.)

Back to the main issue: I have no idea why a Cut+Filter in VS Code causes two clipboard entires (one from the cut, and one from KM's filter). I tested on two different Macs (both running Sonoma, both on KM 11.0.2 and whatever the latest VS Code release is), and they both exhibit this issue.

Does anyone know why I'm getting double clipboard entries from VS Code? @peternlewis, this one's got me stumped. I can work around it, but would love to know why it's happening.

-rob.

2

Most applications populate the clipboard with multiple formats.

Visual Studio Code creates:

  • a public.html NSPasteBoardItem (preserving the foreground and background colour, particular fonts, etc)
  • a public.utf8-plain-text NSPasteBoardItem
  • a org.chromium.web-custom-data NSPasteBoardItem (which Keyboard Maestro has no use for, and ignores)

BBEdit's clipboard is unusually bare, it just creates:

  • a public.utf8-plain-text NSPasteBoardItem (so no rich text access to colours etc)

In Keyboard Maestro, you are seeing a rich text clipboard and a plain text clipboard.

Many applications populate the clipboard with more than 3 different NSPasteBoardItems.

In the case of text copied from Bike, for example, the pasting application can choose between:

  • com.hogbaysoftware.bike.xml
  • org.opml.opml
  • public.rtf
  • public.utf16-external-plain-text
  • public.utf8-plain-text
  • public.html
  • public.data
  • com.hogbaysoftware.bike.references

Keyboard Maestro offers:

  1. rich text clipboards (typically drawn from any public.html or public.rtf NSPasteBoardItems that it finds in the clipboard), and
  2. plain text clipboards (typically drawn from any available public.utf8-plain-text pasteboard item)

In the Clipboard History, you will generally be able to distinguish them by their icons.

See also, for example:

1 Like
3

Wow, and dang ... thanks for the thorough explanation of the intricacies of the clipboard. I guess I'll have to add a loop and just keep deleting past clipboards until I get the point where n-1 differs from n, so I know when I get back to the starting point.

-rob.

4

But wait ... when I view the clipboard after the Copy command, I see only one entry. But after applying the filter in KM, I see two. How does that correlate with the multiple cllipboard types?

-rob.

5

There's a difference between the NSPasteBoardItems that are available at any one moment, and what an application (like KM) does with them.

In the KM case in particular, there is a difference between system NSPasteBoardItems, and the Keyboard Maestro "Clipboards" packaged in UI and offered to the user.

KM is presumably creating a rich text Clipboard, when it can, as part of (or recorded in Clipboard History after use of) the Filter action.

That's not possible after a BBEdit copy (public.utf8-plain-text only available), but is possible after a VSC copy - the KM rich text clipboard can be derived from the public.html NSPasteboard item which VSC creates.

2 Likes
6

An experiment, which may build intuition, is to paste the same code from

  • VSC
  • and then from BBEdit

into TextEdit.

You will see that TextEdit has richer options after a copy from VSC than it does after a copy from BBEdit.

Now start a fresh TextEdit document, and reverse the order of pasting. Start with BBEdit.

1 Like
7

I've tested a bunch of my apps now, and I've only ever seen at most two entries, so I think I can get away with this check:

image

Of course, as soon as I commit to that and release this macro, I'm sure someone will find an app that creates 14 separate Clipboard entries :).

Thanks again for the explanations.

-rob.

1 Like
8

Remember Keyboard Maestro can only create two types of KM Clipboard (Plain and Rich) no matter how many different NSPasteboard items the copying application has created.

Like any application, it looks at what is available, and makes a choice about which NSPasteboard item(s) to use, and how to make use of them.

9

Now do it again in BBEdit, but this time make sure you have white space at the beginning or end of your selection -- you'll see two entries. So, riffing off @ComplexPoint's excellent explanation, you'll get two entries if the "Filter" action either spits out different formats to what was there before or makes any changes. Which makes sense because, in both cases, the clipboard has changed.

While text of %PastClipboard%1% is %SystemClipboard% delete Past Clipboard 1, perhaps?

10

Ah ha! That's exactly what's going on, I believe.

Brilliant; didn't even think of a While action for this case.

Thanks;
-rob.