But that's in a "Display Text", not going to a named clipboard where it can be restyled.
I think I can see where you're coming from, though. Much easier to do the combination in a "Display" that @August can copy'n'paste from than to bounce through TextEdit or similar.
[EDIT] Apparently @Nige_S and @ComplexPoint had I conversation while I was writing up the following note. I had only seen up to this comment of @Nige_S's. I've done some more experiments that point to the Apply Style action, but I'll read the rest of the above conversation before I comment further. Out of sequence comment follows:
Thanks @Nige_S,
I thought of that too, after I made the above post. And I haven;t figured out a way to make it work. There seems to be a bit of a Catch-22 that I haven't unravelled.
I can create a temporary or named clipboard for the sytled text that I want to prepend, but when I paste it in place, the act of pasting appears to overwrite what I have in the System Clipboard, so when I then paste that in, I just get a second copy of the previous paste.
If I attempt to copy the System Clipboard somewhere else, to a variable or to another clipboard, using the Copy Clipboard to Clipboard action:
... I still get the text version. I would suggest this is a bug. Copy Clipboard to Clipboard "should" preserve the entirety of the clipboard contents and not lose the "RTF linky goodness". @peternlewis, what do you think? Is this a bug? Maybe there should be a toggle option in the Action to choose text copy or full linky goodness copy.
It appears that the only way I can preserve the copied links, as links, is to keep them in the System Clipboard, do no other Paste actions while holding onto that clipboard, and make no modifications to the System Clipboard other than the Apply Style to Clipboard action.
So one way that I might be able to work around this would be to insert the prepend text first and then load the System Clipboard with my links. But that means switching apps, maybe even switching Desktops if the archive file is already open somewhere else, and I don't know how to restore the context of the original window to be able to grab the links.
IF the archive file is currently closed, I could open it, paste in the date info, close it again, which would hopefully restore the context of the original app, grab the links, then reopen the archive file and paste in the links after the prepend date that I just pasted.
Opening that archive file twice, before and after grabbing the links, is just about as awkward as opening a temporary TextEdit file in which to do the assembly of the link info block to paste into the archive file. I would prefer to not see extraneous windows popping up and closing again, just to be able to grab a complete copy of what I am looking at.
At the moment, I'm still stuck. The Catch-22 described above does not seem to have a simple workaround and yet it seems on the surface to be a simple task.
Don't forget that you can copy directly to your named clipboard, avoiding that problematic bounce.
But you should try:
It'll help if we knew the app(s) you are copying from and pasting to, and ideally some sample text, so we can reproduce the problem. Apps have control over the formats they put onto, and take from, the System Clipboard so the closer we can get to what you're doing the better.
Thanks @ComplexPoint, your demo seems to verify that this should work, and also gets to the heart of the problem. Thanks for that macro. I definitely want to give that a try. Your second demo, with the date added, is very encouraging.
Forget? I don't think I ever knew. But I'm not sure that it will work. I'm not highlighting the entire set of links and then copying, I'm copying links out of Tabs Outliner which treats ⌘C a little differently. If I have a "Window" line selected, typing ⌘C will copy the entire entry for that windows with all of its tabs as links. I just have to click at the "Window" line, not figure out which lines are in and not. I don't think I would be able to copy directly to a named clipboard with that.
Your other suggestion,
I also had no idea that that was possible. Combined with @Nige_S's suggestion about deleting clipboard flavors, that may do the trick.
This may be one source of the problem and what requires the workarounds above, when the concept works in general for other people.
As I mentioned above, the source of the links is the Tabs Outliner Chrome Extension. The target is my own app, DeskSpaceNotes, which is a renaming of TextEdit using an older version of TE, v1.8, the latest that I could find source for so that I could rename it. Having a dedicated version of TE allows me to have separate list of Open Windows and Recent Files from the un-dedicated, up-to-date version of TE, v1.15, as shipped with Catalina, that I use for general composition when I'm not using Markdown or Open Office Write. The older TE may indeed handle different flavors of clipboard contents differently than newer ones, and @ComplexPoint's suggestion may help work around that.
I have also found that I can toggle the problem on and off, using only the System Clipboard and not attempting to insert anything else, when I enable and disable the Apple Style to System Clipboard action. Again, this appears to work for other people so the glitch may be due to one or the other of my oddball apps.
I'll be able to try this later tonight, I hope. Thanks to you both!
Still works with a named clipboard, I think.
I am getting a re-styled named clipboard, after copying formatted material from TextEdit, for example, with this:
Remove Clipboard Flavors.kmmacros (3.7 KB)
Where can I find a list of the "flavors" to choose among?
If public.rtf is the best clipboard flavor to use in preserving links, why remove the two text flavors instead of removing everything except public.rtf?
I tried removing those two text flavors, and I still got plain text in the clipboard.
Never mind. I found %SystemClipboardFlavors%. When I display that, for the clipboard content that I'm capturing from Tabs Outliner, I get:
com.apple.traditional-mac-plain-text
org.chromium.source-url
org.chromium.web-custom-data
public.html
public.utf16-plain-text
public.utf8-plain-text
So I don't want to force public.rtf because it isn't there.
I'll try removing all three of the *.plain-txt flavors and see what happens.
For pasteboards which contain no public.rtf,
the best approach is to keep public.html, and delete all others.
macOS is good at:
public.html, andpublic.html ⇄ public.rtf conversions.I found
%SystemClipboardFlavors%.
See also:
Here is a general approach to purging all flavors other than public.rtf and public.html from the system clipboard:
Keep Rich text System Clipboard flavors only.kmmacros (5.3 KB)
Oooh -- that's sweet!
Otherwise the macro seems to leave me with a "Non-Text Clipboard" when run on even a single unstyled word copied from this thread -- flavor is still reported as public.html, but adding a "Display Text %SystemClipoard%" action to the end of the macro gives me
I've a feeling that's a problem at on my side, though.
Yes, any Paste must be done from the system clipboard, of which there is only one. So any time you paste from any source, that source must be copied in to the system clipboard and then Command-V is used to cause the Paste to happen.
Copy Clipboard to Clipboard copies all flavours (unless explicitly marked as transient).
So either there is some confusion on your part of what is happening, or the app is not actually putting the flavours on the clipboard, or the app is marking the flavours as transient or otherwise using private flavours.
I, too get that same "No Text in Clipboard" message, when I strip all the "plain-text" flavors out of the clipboard. And I, too, think it's likely that I have a problem on my end.
I have more things to try...
Thanks for the confirmation, Peter. That's what I figured. I sill haven't tried Nige's suggestion:
which again, in theory, ought to work.
Peter(@peternlewis), do you have any idea why a straight paste of URL links in the clipboard works, pasting in formatted text with hidden hyperlinks, but doing Apply Style to Clipboard and then pasting gets the text version instead?
That seems to be the core of the matter, it's mostly KBM actions, and none of the fiddling with the flavors seems to work.
The specific purpose of my original problem has been to paste a list of captured hyperlinks into the top of a file, immediately following the title line, without affecting the formatting of the title line, while also restyling the pasted text, because the default font and size is unacceptable.
My original attempt, and all of the previous discussion, has been focused on what it takes to use the Apply Style to Clipboard action. And that has not been working.
Rather then the debug the elegant solution, I have discovered that for this specific purpose, I can:
It solves my problem for this specific case, but does not provide an elegant, widely applicable solution. Still, I have a way forward to go on my specific workflow issue, which allows me to get this particular troublesome issue off of the front burner, while allowing me to continue experimenting with a more elegant solution at my leisure.
The specific purpose of my original problem has been to paste a list of captured hyperlinks into the top of a file, immediately following the title line, without affecting the formatting of the title line, while also restyling the pasted text, because the default font and size is unacceptable.
My original attempt, and all of the previous discussion, has been focused on what it takes to use the Apply Style to Clipboard action. And that has not been working. It persisently does apply the style while also reformatting the hyperlinks as text. @ComplexPoint has gotten it to work, but I haven't, and I haven't yet "tried everything".
Rather then the debug the elegant solution, I have discovered that for this specific purpose, I can do a case-specific workaround with this sequence:
It solves my problem for this specific case, but does not provide an elegant, widely applicable solution. Still, I have a way forward to go on my specific workflow issue, which allows me to get this particular troublesome issue off of the front burner, while allowing me to continue experimenting with a more elegant solution at my leisure.
Sure - the initial copy has some random set of flavors that include the stuff you want, where as the Apply Style to Clipboard action reads the styled text, applies the styles, and then writes just the styled text back to the clipboard, resulting in styled text.
So the former has some different flavour that it being used.
Styled Text on the Mac is a very complicated subject, and it is just one possible complicated thing of the set of flavours in the clipboard.
Is there some way of discovering which flavors have "the stuff I want", in particular, hyperlinks as links rather than simply a text name and a URL, and somehow forcing the clipboard to contain only that? Does the Apply Style to Clipboard action only grab a "styled text" flavor, if there is one?
I've been presuming that a flavor named with "text" would have a hyperlink's text and URL separated and would paste them in separately. But if some "styled text" flavors support hyperlinks and some don't, how can I tell?
Is there a standards group for clipboard flavors? Is there a master list at developer.apple.com?
Is there some way of examining the actual contents of the clipboard, all the different flavors and what info they contain?
There are hyperlinks in there, they show up as links, not separated text and URL, when I paste the clipboard without any Apply Style, and they have a font and size, different from the default where they are being pasted. All I want to do is change that font and size, without losing the hyperlink formatting.
@ComplexPoint seems to be able to do it while @Nige_S and I seem to be unable to duplicate that, so obviously there are weird idiosyncrasies that are not helped by my using oddball apps. How can I tease out the differences?
To see the set of macOC UTIs (Uniform Type Identifiers) for the pasteboard flavours in your clipboard at any given moment, you can use a macro like:
Many applications define their own UTI strings, for specific data types, but the key system-defined types for general interchange include:
public.utf8-plain-textpublic.htmlpublic.rtfKeyboard Maestro can list out the clipboard flavors with the SystemClipboardFlavors token, but that is about it.
There are tools that will show information about the clipboard flavors.
Apple lists some of the flavors but there is no one list of all possible clipboard flavors.
and for a line-by-line listing of just the UTIs in the system clipboard at the moment, you could write something like this:
UTI flavors in clipboard (listed one per line).kmmacros (1.9 KB)
UTIs are just standardized names for particular data formats, so your question is effectively about how each named format encodes a combination of label and url.
In turn, all of this goes back to the origin of "hyperlinks" in HTML, where the url is stored as an attribute value, and the label as the content of the element.
Plain text is a flat, single-layered data model (no layering into tag contents vs tag attribute values) so the solution which has stuck is the Markdown pattern of a sequence of two bracket types in [label](url)
The least tractable of the 3 usual suspects is the RTF encoding, which is described here: What is the RTF syntax for a hyperlink? - Stack Overflow
Apple does define a dedicated public.url, and you can see a smallish number of applications including a pasteboard of that type in the clipboard, but generally the most tractable, and best supported with tooling, is the original source of the notion of a "link": public.html, from which, in an <a> tag, you can either take:
href attribute, (the url) orI'll leave the clever stuff to the two smarter-than-me people who've already posted...
But to start working towards a solution I'd begin with a single known app -- Notes or TextEdit look like a good choice -- and get the macro working there. Then switch the destination to your app, to make sure that whatever you did in the rebuild didn't break clipboard handling for incoming data. Then switch the source to the Chrome extension to see if you can munge one of the data types it provides into something that works as input.
Given that the only "useful" format in your list appears to be HTML, you may be looking at an additional HTML->RTF step, perhaps using textutil.