"Reveal in Finder" extension - where to find it?

PopClip Extensions
1

Hi,

I have an extension installed called “Im Finder anzeigen” which should be “Reveal in Finder” in English. But for the life of me, I can’t find it AKA its source code anywhere. Is this built in somehow?

I’d like replace it to handle multiple text lines containing Posix paths in one go and reveal them in the Finder, while ignoring lines that do not contain any paths.

(It seems to me that this may be only possible using Apple Script targeting the Finder. I use it all the time in my Apple Scripts, but I have seen developers being unable to reveal ≥ 2 files in the Finder simultaneously.)

Thanks for any pointers!

2

All extensions are installed into:

~/Library/Application/Support/PopClip/Extensions

Try to find it here.

See: Is there a way to backup my extensions?

3

Not there, of course, otherwise I wouldn’t have raised the issue.

4

The “Reveal in Finder” action is built-in to PopClip, so there is no extension source code to view.

Shall I take this as a feature request to add access to “reveal in finder” functionality for extensions?

5

Yes, should be worthwhile :grinning_face_with_smiling_eyes:.

But my real intention was to get a reveal in Finder command handling multiple lines of Posix paths (as a minimum request). I’d expect it to work like this piece of AS code:

´´´

tell application "Finder"
	reveal itemList
	activate
	reveal itemList -- double reveal to really reveal
end tell

´´´

where itemList is an AS list of alias or Posix paths.

Note the dual call of reveal, which makes sure that if the containing folders house a huge number of items, that the Finder is really being able to not only show the windows for the containers and select the items (at least one if several in the same folder) but also make them visible.

This code, for me, on an oldish Intel machine works with three digit numbers of itemList items, across dozens of container folders. Might take a couple of seconds for the Finder to do the heavy lifting.

Of course, I’d be able to create my own. Just would have liked to check if the existing code can be extended to do that before.

Thanks!

6

BTW, here

is a command line tool seeming to work as required, in Swift.

Essentially, it uses the following simple code
´´´

if !urls.isEmpty {
NSWorkspace.shared.activateFileViewerSelecting(urls)
}

´´´

This api should be available in Objective-C just the same.

Just found the post below exposing your code, which seems to be different:

My bottom line is: the swift example does a better job than the built in extension. IMHO. :grinning_face_with_smiling_eyes:
Thanks!

7

It was because of the difficulty of parsing multiple paths from an input so I restricted it to one input. The actual opening paths part is straightforward. (Bear in mind I wrote this feature in 2011.. and nobody has asked about having multiple paths since, until this week! Squeaky wheel gets the grease…)

8

Admitted. But restricting it to lines containing full paths only should be manageable.

Currently, you also seem to check the existence of the respective file to decide if or if not to show the extension.

Since this is blindingly fast even for lots of files you could even show it for arbitrary text but of course reveal only paths on lines of their own. Even if you’d limit yourself to lines starting with

/Volumes/

IMHO would probably cover 99% of the usage cases.

I guess this should be feasible.

Sucking out paths from strings is quite a different story, since there won’t be precise criteria for the end of the paths, at least as long the paths are not escaped somehow.

My interest, however, is simply full-line-paths. To get a similar functionality to URL lists (which are different and a lot more easy of course, since white-space is encoded).