Emacs formula: Emacs.app can't be found via Spotlight

[yacoob]

After building Emacs via 'brew install emacs --cocoa', the resulting Emacs.app is in /usr/local. This makes it unfindable via Spotlight, as Spotlight (supposedly) deliberately skips /usr/local during indexing. Linking to the built Emacs.app from /Applications also doesn't work for some reason. Given homebrew doesn't like .apps anyway, would it be possible to have brew install the resulting .app into /Applications?

[adamv]

There is an external command "brew linkapps" that might help:
mkdir ~/Applications
brew linkapps

[yacoob]

This isn't exactly helping for Spotlight - looks like it doesn't want to follow symbolic links :|

[adamv]

The answer might be "I don't know"; I don't personally use Spotlight. "Path Finder"'s app launch will work through symlinks, though (I filed a bug report and the author fixed it.)

[adamv]

Maybe try asking the Spotlight question at the Apple stackoverflow: http://apple.stackexchange.com/

[jacknagel]

You can use 'mdimport /usr/local' to have Spotlight index /usr/local. Might be worth it to put this in the caveats for the emacs formula

Here's a link to to the Apple developer page for mdimport
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/mdimport.1.html

[kulakowski]

Maybe consider brew linkapps? Noticed it in the Contributions folder the other day.

[kelsin]

This is also the case for launchbar. Launchbar doesn't see the symlinks so I end up copying the full apps.

[yacoob]

No, mdimporting /usr/local doesn't work - I'm guessing /usr/local is explicitly filtered out, either from import or from serving. Perhaps we just need --move option for linkapps?

[flips]

Hm, maybe it's possible to make a Finder alias? That seems to work here, even if Spotlight shows the match as a Document and not an Application ... I don't know how to make a Finder alias in CLI/from bash, though ...

[deasmi]

Having spent a time looking for a solution to this the best quick fix is to make a shell script that invokes emacs, something as simple as

#!/bin/bash

open /usr/local/cellar/emacs/24.1/Emacs.app

then use appify

http://git.abackstrom.com/appify.git

to make an app out of the script. Place this in /Applications and it will appear in Spotlight.

[rlridenour]

So far, the best solution that has worked for me is to copy the app into the applications directory:

cp -r /usr/local/Cellar/emacs/24.2/Emacs.app /Applications/

Spotlight then finds it with no trouble.

[pmetzner]

I created an application via Automator which runs this shell script:

/usr/local/Cellar/emacs/24.2/Emacs.app/Contents/MacOS/Emacs &

I put that application in ~/Applications/ and added an icon.

[harrylove]

1. $ open /usr/local/Cellar/emacs/[version]/
2. Right-click Emacs.app and choose Make Alias.
3. Drag or move or copy the alias to Applications.
4. Rename the alias in your Applications folder to your desired name.
5. Done

[carlgieringer]

Another possibility is to add an option to linkapps that creates hard links instead of soft. EDIT: apparently hard links to directories are verboten as being logically inconsistent - as far as the file system is concerned.

[zzamboni]

I have the same problem both a symlink and a Finder alias don't work, Spotlight still doesn't see the app. Only copying the app from the Cellar directory to /Applications works.

The funny thing is that applications installed using Cask, which are symlinked from /opt/homebrew-cask/Caskroom into /Applications, appear fine in Spotlight. Any ideas why?

[MikeMcQuaid]

Folks: we're aware this is an issue lots of people have and are annoyed about. Saying it affects you too won't really get it fixed quicker as it's not a pain point for the maintainers who are working on other things. People need to submit PRs instead.

[DomT4]

If the Cask are handling this fine, perhaps someone interested in this issue could take a look at that code and port it for Homebrew's usage too. Ultimately, It's easier to say 'Yes' to a working PR than it is to open-ended pondering, as much as I personally adore the latter 😉

[elyscape]

The funny thing is that applications installed using Cask, which are symlinked from /opt/homebrew-cask/Caskroom into /Applications, appear fine in Spotlight. Any ideas why?

/usr is flagged as hidden, but /opt is not. Spotlight refuses to index hidden folders or symlinks to hidden folders. A potential workaround would be to have Homebrew's Cellar be in /opt/homebrew/Cellar or something.

[zzamboni]

@elyscape thanks! Your comment gave me the clue I needed for how to solve this problem:

sudo chflags nohidden /usr

After running this command, the Emacs symlink gets properly indexed by Spotlight.

[jasonm23]

@zzamboni just mv the built Emacs.app into /Applications/

Don't be afraid nothing averse will happen, and you won't need to play with anything to make spotlight happen, it will just work.

[deepak]

TL:DR not sure how spotlight makes the sausage :-)

symlinking Emacs.app under /Applications, was not showing under spotlight

so i copied Emacs.app to ~/Applications
at which time, as expected, spotlight search started working.

but then - when i deleted the app
and symlinked the app from /usr/local
even then spotlight works, but partially

when we have a symlink, spotlight will give a "Top Hit" as Emacs
for the search terms Ema, but not Emacs and Emacs.app

but copying over the Emacs.app gives consistent results

running mdimport ~/Applications does not change this

for ~/Applications/Emacs.app being a symlink.
running mdls ~/Applications/Emacs.app returns something
same with mdfind Emacs.app which returns /usr/local/Cellar/emacs/24.5-dev/Emacs.app
as the first result

not sure what magic this is :-)
am on Yosemite (10.10.3)

did not try marking /usr as nohidden.

[zzamboni]

@deepak: see my comment above. Marking /usr as "nohidden" using the chflags command fixes the problem. Apparently Spotlight refuses to index hidden directories (which makes sense for the most part).

[lukehoersten]

On 10.11 El Capitan, the nohidden change is not possible (maybe due to rootless?):

$ sudo chflags nohidden /usr
chflags: /usr: Operation not permitted

[DomT4]

Yes, rootless blocks it. You'd have to temporarily drop out of rootless to set the flag at this point.

[btzo]

@DomT4 you have an idea of how I can do it?

[allezxandre]

Hey, I found a way to link emacs app. When you use OS X' own alias system (right click > make alias), spotlight can find your file. So the issue was how can I do this kind of alias from terminal. I fond an answer here: http://apple.stackexchange.com/a/51712/38165 and I adapted the script as follows:

#!/bin/bash

if [[ "$(uname)" != "Darwin" ]]
then
    echo "This script is intended for use on Darwin (Mac OS)"
    ln -s "$1" "$2"
    exit 0
fi

if [[ -f "$1" ]]; then
    type="file"
else
    if [[ -d "$1" ]]; then
        if [[ "${1##*.}" = "app" ]]
        then
            file
        else
            type="folder"
        fi
    else
        echo "Invalid path or unsupported type"
        exit 1
    fi
fi

osascript <<END_SCRIPT
tell application "Finder"
   make new alias to $type (posix file "$1") at (posix file "$2")
end tell
END_SCRIPT

I named this script osx-alias.sh, and to link the latest emacs version, I use:

./osx-alias.sh $(ls -1d /usr/local/Cellar/emacs/* | sort | tail -1)/Emacs.app /Applications

I think brew linkapps should use that kind of linking instead of ln -s.

[jasonm23]

PSA : Bundles are not intended compilation targets of brew. In fact the core Brew team very much prefer them not to be included in the formula list.

There is also no reason to keep your Bundle in the Cellar. Dependencies are all met regardless of where you place the bundle.

There are a number of files required that are not in the Bundle, but that is an issue with the formula which should be addressed elsewhere.

Just as you would any other .app bundle you build, simply move Emacs.app into /Applications/ and don't waste your time fumbling around with symlinks, aliases or any other shenanigans.

Better still use the downloadable build (as per brew cask) and move that bundle to /Applications/.

This is yak shaving you can simply avoid, and Emacs will be indexed as a first class App.

On 29 Dec 2015, at 10:39 PM, Alexandre notifications@github.com wrote:

Hey, I found a way to link emacs app. When you use OS X' own alias system (right click > make alias), spotlight can find your file. So the issue was how can I do this kind of alias from terminal. I fond an answer here: http://apple.stackexchange.com/a/51712/38165 and I adapted the script as follows:

#!/bin/bash

if [[ "$(uname)" != "Darwin" ]]
then
echo "This script is intended for use on Darwin (Mac OS)"
ln -s "$1" "$2"
exit 0
fi

if [[ -f "$1" ]]; then
type="file"
else
if [[ -d "$1" ]]; then
if [[ "${1##*.}" = "app" ]]
then
file
else
type="folder"
fi
else
echo "Invalid path or unsupported type"
exit 1
fi
fi

osascript <<END_SCRIPT
tell application "Finder"
make new alias to $type (posix file "$1") at (posix file "$2")
end tell
END_SCRIPT
I named this script osx-alias.sh, and to link the latest emacs version, I use:

./osx-alias.sh "$(ls -1d /usr/local/Cellar/emacs/* | sort | tail -1)/Emacs.app" /Applications
I think brew linkapps should use that kind of linking instead of ln -s.

—
Reply to this email directly or view it on GitHub.

[dunn]

There is also no reason to keep your Bundle in the Cellar. Dependencies are all met regardless of where you place the bundle.

I'm not sure if that's true, since we pass --disable-ns-self-contained to the configure script.

If you want a really portable Emacs bundle built from the core formula (since I don't think the Cask version has options like gnutls and imagemagick), this should work (keep in mind it's completely unsupported by us):

diff --git a/Library/Formula/emacs.rb b/Library/Formula/emacs.rb
index 71f272e..ca2e0c3 100644
--- a/Library/Formula/emacs.rb
+++ b/Library/Formula/emacs.rb
@@ -87,14 +87,12 @@ class Emacs < Formula
     system "./autogen.sh" if build.head? || build.devel?

     if build.with? "cocoa"
-      args << "--with-ns" << "--disable-ns-self-contained"
+      args << "--with-ns"
       system "./configure", *args
       system "make"
       system "make", "install"
       prefix.install "nextstep/Emacs.app"

-      # Replace the symlink with one that avoids starting Cocoa.
-      (bin/"emacs").unlink # Kill the existing symlink
       (bin/"emacs").write <<-EOS.undent
         #!/bin/bash
         exec #{prefix}/Emacs.app/Contents/MacOS/Emacs "$@"
@@ -116,13 +114,6 @@ class Emacs < Formula
       system "make"
       system "make", "install"
     end
-
-    # Follow MacPorts and don't install ctags from Emacs. This allows Vim
-    # and Emacs and ctags to play together without violence.
-    if build.without? "ctags"
-      (bin/"ctags").unlink
-      (man1/"ctags.1.gz").unlink
-    end
   end

   def caveats

[allezxandre]

Oh... I didn't know bundles weren't necessary in the Cellar. I thought some dependencies used the App.app/Contents directory so I was afraid to move it.

[jasonm23]

This is what I was referring to re: address in another issue.

Regardless, it makes no difference to where the .app bundle lives.

The canonical location is /Applications/ and so that will get you best results re:OS X

but as I said, a self contained bundle, as per Brew cask, and properly located is your best bet.

Note that bundle can just be downloaded from S3, I recommend it over any other method, unless you're hacking the C source. Which would legitimise building from scratch.

On 29 Dec 2015, at 11:30 PM, Alex Dunn notifications@github.com wrote:

There is also no reason to keep your Bundle in the Cellar. Dependencies are all met regardless of where you place the bundle.

I'm not sure if that's true, since we pass --disable-ns-self-contained to the configure script.

If you want a really portable Emacs bundle built from the core formula (since I don't think the Cask version has options like gnutls and imagemagick), this should work (keep in mind it's completely unsupported by us):

diff --git a/Library/Formula/emacs.rb b/Library/Formula/emacs.rb
index 71f272e..ca2e0c3 100644
--- a/Library/Formula/emacs.rb
+++ b/Library/Formula/emacs.rb
@@ -87,14 +87,12 @@ class Emacs < Formula
system "./autogen.sh" if build.head? || build.devel?

 if build.with? "cocoa"

•  args << "--with-ns" << "--disable-ns-self-contained"
  

•  args << "--with-ns"
  

  system "./configure", *args
  system "make"
  system "make", "install"
  prefix.install "nextstep/Emacs.app"

•  # Replace the symlink with one that avoids starting Cocoa.
  

•  (bin/"emacs").unlink # Kill the existing symlink
  

  (bin/"emacs").write <<-EOS.undent
  #!/bin/bash
  exec #{prefix}/Emacs.app/Contents/MacOS/Emacs "$@"
  @@ -116,13 +114,6 @@ class Emacs < Formula
  system "make"
  system "make", "install"
  end

• Follow MacPorts and don't install ctags from Emacs. This allows Vim

• and Emacs and ctags to play together without violence.

• if build.without? "ctags"

•  (bin/"ctags").unlink
  

•  (man1/"ctags.1.gz").unlink
  

• end
  end

def caveats
—
Reply to this email directly or view it on GitHub.

[elyscape]

I wonder if maybe it would be worth changing linkapps to moveapps or copyapps?

[jasonm23]

Copy apps would be ok, but move apps would be better.

The problem then is dealing with the headache of shifting the entire homebrew user base.

Ugh! ;)

On 30 Dec 2015, at 1:00 AM, Eli Young notifications@github.com wrote:

I wonder if maybe it would be worth changing linkapps to moveapps or copyapps?

—
Reply to this email directly or view it on GitHub.

[lukehoersten]

PSA : Bundles are not intended compilation targets of brew. In fact the core Brew team very much prefer them not to be included in the formula list.

Then remove the app bundle from the formula. Either it's in there and should be supported and work correctly or it's not.

There is also no reason to keep your Bundle in the Cellar. Dependencies are all met regardless of where you place the bundle.

There is a reason, however, to not want to manually copy or link the app bundle in order to automatically keep it up-to-date when brew updates it. Having to watch for emacs to get updated among all installed packages and then manually moving it into place is tedious.

Just as you would any other .app bundle you build, simply move Emacs.app into /Applications/ and don't waste your time fumbling around with symlinks, aliases or any other shenanigans.

Again, if this is the case, the emacs formula should be fixed to move the bundle or, if this is not possible, the app bundle target should be removed.

It seems people forget that Homebrew is not only for building packages and resolving deps, but also to install those packages (hence brew install). Users are not wrong for wanting features of the formula to "just work".

[lukehoersten]

@jasonm23 looks like you've also deleted a similar message from Sep 15. It's still in everyone's inbox:

Homebrew team are on record many times saying they would rather users did not even use it for building .app bundles.

(Motivated by a deluge of misdirected support requests.)

Please people, just move your compiled app bundles into /Applications or ~/Applications where they are supposed to be.

Any idea that Homebrew needs the app bundle in /usr/local/Cellar is erroneous.

It's effectively cargo culting, so please just stop it.

If you wrote your own OSX app, would you feel some invisible constraints that meant you run your bundle from the build/Release folder? (Oh my I hope not)

So please, stop it.

Relying on social contract so users don't use certain features of the formula doesn't scale. As I said previously, either remove the app bundling or fix the installation to work properly. All these users are not incorrect for expecting brew install emacs --with-cocoa to actually install the cocoa app bundle.

[jasonm23]

It seems people forget that Homebrew is not only for building packages and resolving deps, but also to install those packages (hence brew install). Users are not wrong for wanting features of the formula to "just work".

The problem is that bundles were not really an intended target.

The automatic installation to /Applications/ violates Homebrew's aim/philosophy to avoid touching the standard OS X software locations.

You can find this mentioned in many threads.

Brew cask is the net result of this problem, however it doesn't fix this issue properly and uses symlinks. Which isn't a good solution for Spotlight.

Simply following the correct convention in the first place would have avoided a lot of noise and issues. Unfortunately a U turn is as messy and unpleasant as the problem we want to fix, now that the culture of Brew Cask has taken root.

The way to properly deal with your spotlight issues are to make /usr/local/Cellar or whatever indexed as a first class location for Spotlight, however as Yosemite and El Capitan illustrate, Apple will often take security measures at odds with this sort of customisation.

Alternatively, as is my original suggestion, whichever app bundles you wish to install via brew/brew cask, move them to /Applications

The "automatic upgrade" via Brew was never particularly satisfactory and a good sized group of Apps use Sparkle to upgrade themselves anyway.

Of course this does not apply to Emacs Mac, but using the Brew Cask, app bundle move method is not beyond anyone capable of actually working with Emacs.

[jasonm23]

Since touching the core filesystem breaks the homebrew philosophy this becomes a difficult issue.

My feeling is the same as yours. It should be automated out of the users hands.

App bundles are a case where the homebrew philosophy is broken (better to say incomplete!)

On 30 Dec 2015, at 7:32 AM, Luke Hoersten notifications@github.com wrote:

@jasonm23 looks like you've also deleted a similar message from Sep 15. It's still in everyone's inbox:

Homebrew team are on record many times saying they would rather users did not even use it for building .app bundles.

(Motivated by a deluge of misdirected support requests.)

Please people, just move your compiled app bundles into /Applications or ~/Applications where they are supposed to be.

Any idea that Homebrew needs the app bundle in /usr/local/Cellar is erroneous.

It's effectively cargo culting, so please just stop it.

If you wrote your own OSX app, would you feel some invisible constraints that meant you run your bundle from the build/Release folder? (Oh my I hope not)

So please, stop it.

Relying on social contract so users don't use certain features of the formula doesn't scale. As I said previously, either remove the app bundling or fix the installation to work properly. All these users are not incorrect for expecting brew install emacs --with-cocoa to actually install the cocoa app bundle.

—
Reply to this email directly or view it on GitHub.

[MikeMcQuaid]

I'm closing this conversation as it's not really closing anywhere.

To summarise:

• Homebrew initially accepted more .app bundles than we should have done and some of them work sub-optimally as a result
• Longer-term we're going to try and stop accepting new .app bundles and move them to Homebrew Cask instead (as the two projects grow closer)
• Most Homebrew bundles cannot be simply copied to /Applications as they are not relocatable
• Symlinks, copying and aliases all have advantages and disadvantages. We've changed so many times at this point we are unlikely to do so again.
• Cask bundles generally can be simply copied to /Applications and are relocatable and the Homebrew Cask team is planning on replacing their symlinking with copying at some point in the future.
• We welcome pull requests to improve the situation but not really discussion on the issue tracker. Please take it to the mailing list or, preferably, mail between individuals.

Thanks!