Finder selected files, or a scratchpad, in Emacs

AppleScript
#1

For some reason, the script I was using for all this time failed today because Finder did not return a selection. I wonder why I had not noticed that before.

After a lot of testing, it appears that assigning Finder’s selection to a variable does not generate an error when there is no selection, so even a “try” was not enough to catch that issue.

I reworked the whole thing and ended up with this script (including info on dealing with “frontmost” that I found here earlier today):

Let me know if there are obviously weird things…

#2

Hey Jean Christophe,

I’ve used this construct for decades:

tell application "Finder"
   set finderSelectionList to selection as alias list
   if finderSelectionList ≠ {} then
      # Continue
   end if
end tell

This is a trifle slow:

tell application "System Events"
   set frontAppName to name of first application process whose frontmost is true
end tell

This is about 100 times faster:

tell application (path to frontmost application as text)
   set frontAppName to name
end tell

-Chris

2 Likes
#3

I also love Applescript for the wonderful people on the fora :slight_smile: Thank you Chris :slight_smile:

1 Like
#4

Adding to @ccstone’s excellent tips:

The frontmost property

If you want to know whether Finder is frontmost:

if application id "com.apple.finder" is frontmost then

or:

tell app id "com.apple.finder" to if it is frontmost then

path to 

# Obviously, your Emacs.app file is located in a different place:
set myEmacsAppPath to "/Users/******/Documents/Repositories/emacs/nextstep/"
# This is the name of the empty default Emacs buffer you want to open:
set myScratchBufferName to "turlututu"

# This part is unlikely to change, it assumes that you use the emacsclient
# that corresponds to the selected Emacs.app. And that you run Emacs as a server.
set myEmacsclient to myEmacsAppPath & "Emacs.app/Contents/MacOS/bin/emacsclient"
set myEmacsApp to myEmacsAppPath & "Emacs.app"

Assuming you’ve launched Emacs.app at least once in the past, then it will have been registered with Launch Services, which keeps track of all applications on your system. Therefore, you can declare myEmacsApp and myEmacsClient like so:

set myEmacsApp to the POSIX path of (path to application "Emacs")
set myEmacsClient to myEmacsApp & "/Contents/MacOS/bin/emacsclient"

It saves you having to hard-code the path into your script, and aids portability. If you end up moving the Emacs.app application file to a different location, you won’t need to make any adjustments to your script.

activate 

try
    tell application "System Events" to tell process "Emacs" to set frontmost to true
on error
    tell application myEmacsApp
        activate
        delay 1
    end tell
end try

System Events shouldn’t have to be involved here. This entire block could likely be replaced with:

tell application "Emacs" to activate
2 Likes
#5

Thank you CJK for the hints. Very interesting.

I’m currently working through my old scripts to remove the useless tell blocks and try to streamline the things a bit.

I am light-years behind most of the people here, but I find that the old me who coded all that understood much less than what I do now (which does say how much I did not know rather than make a statement on what I know now :wink: )

1 Like
#6

Hey Jean Christophe,

That’s how it works for everyone…  :sunglasses:

-Chris

2 Likes
#7

Totally, I look at some of my old scripts and I’m embarrassed for myself.

3 Likes
#8

This is why I’m continually fiddling with :slight_smile: , ahem, refactoring my code.

1 Like
#9

As long as they work, they’re nothing to be embarrassed about.

#10

That’s not true. There’s this notion that the first and foremost attribute of a script is that it works, but it’s a fallacy. It depends how one defines something to be “working”, because a script may appear to do what the author intended, but later turns out that it only succeeds under specific conditions that were present at the time of testing, but not subsequently. Also, a script may appear to be doing what it”s designed to do from what one can see, yet behind the scenes, it may inadvertently be doing harm to the system in the background. Then you get scripts that, again, achieve the ultimate objective, but are implemented in an especially bad way, which might not lead to any harm of significance, yet still end up causing a nuisance, or maybe simply produce really jarring side-effects that aren’t necessarily a fault of the script, but an inherent downside of a particular backhanded method of achieving the goal.

But, in my case, I have a computer science degree, so when looking at some older scripts of mine, I judge my choices as I feel I really ought to have known better. Having a degree, however, doesn’t give one immunity to making stupid decisions or thinking something is cool at the time when it’s really not.

2 Likes
#11

Sure, but I write that in the context of you can’t know how bad you are in foresight. And hindsight is never very useful.

A given state is the result of circumstances that could not be otherwise when they were, by definition. You can complain about your current state of mind and be embarrassed about that knowing all the things you know now. But weird things you did in the past should be considered interesting because they give you hints on why you made the decisions you made then, and that is the learning process.

1 Like
#12

Wise words.
  

1 Like
#13

Excellent – and that’s why you’re mistaken to say:

Judging oneself in hindsight is a fallacious exercise.

Learning through hindsight is often very productive provided one doesn’t grow roots and dwell there.

:sunglasses:

-Chris

2 Likes
#14

I’ve not yet taken the time to fix the script, but it at acts a bit funny. I think that there is a delay that doesn’t work as it should and I often end up with the “scratch” buffer instead of the selected file… Weird. Anyway, I should be in bed now… Thank you all for the remarks comments and discussions!