You’re right it’s not an easy one, though may be possible with some research.
One thing you could do is use the Dropshelf — PopClip Extensions extension with Dropshelf to one-click the selection to a shelf and the drag to desktop. It’s a two-step process but not as awkward as dragging text.
uggh… nothing against Dropshelf… I just have enough ““stuff”” running at any one time and was hoping Popclip, could, umm, clip text but I’m a big fan so I’ll just holdout to see if maybe you’ll come up with some magical code to make it happen.
The reason I suggest an intermediate shelf app is that the .textClipping format is a weird one only created by the Finder itself when you drag the text to the desktop. I don’t know another mechanism to create one. I imagine it’s possible to construct one manually though, with some study and dedication.
Nick, you may remember an app called “ClipEdit” that edited .textClipping files. It was a rare gem by an indie developer who released it back in 2006 and it was still available on his site until 2018. Funny thing is that it’s still functional today if your machine can run 32bit apps (Mojave and under).
I mention it just to say that as unusual as the Finder driven .textClipping format might be? It wasn’t impossible to develop around it, as you most probably know.
But let me try a different approach, what if there was some way to send the selected text to a new .txt file in the finder BUT with the ability to name the doc in the same way that a .textClipping employs? Essentially that it pre-names the file with the first half dozen words that were clipped. There already is a PopClip extension that can already create a TextEdit file, no? So what if two new features were added. The first being the naming routine I mentioned above and the other feature would be, a user selectable option, to either create a new document or append an existing one.
I’m sure it’s possible to code an extension to make a textClipping — probably using an external scripting language since special file system flags need to be set on the file IIRC. But it is a “job of work”, which I can’t do in a javascript snippet in 2 minutes like I can with some requests.
Whilst I’d love to say “yes sure, I’ll spend a couple of hours on that”, I have literally hundreds of other requests for extensions stacked up too. And I need to work on the app, and other stuff, and … you get the picture. I can’t just say yes to everything.
I’ve realised more and more, my focus has to be on building better tools to allow people to make their own extensions, rather then personally creating extension after extension (and maintaining them when they break).
Anyway – right now as it is, anyone with sufficient programming skill and the will to research the problem and apply themselves to it could make this extension. It doesn’t have to be me.
Why don’t you just use plain text which is widely supported, cross-platform, very searchable, and also allows for tons of other automation opportunities?