Skip to content
This repository has been archived by the owner. It is now read-only.

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

Closed
yacoob opened this issue Mar 12, 2011 · 37 comments

Comments

@yacoob
Copy link
Contributor

@yacoob yacoob commented Mar 12, 2011

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

This comment has been minimized.

Copy link
Contributor

@adamv adamv commented Mar 12, 2011

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

@yacoob

This comment has been minimized.

Copy link
Contributor Author

@yacoob yacoob commented Mar 12, 2011

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

@adamv

This comment has been minimized.

Copy link
Contributor

@adamv adamv commented Mar 12, 2011

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

This comment has been minimized.

Copy link
Contributor

@adamv adamv commented Mar 23, 2011

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

@adamv adamv closed this Mar 23, 2011
@jacknagel

This comment has been minimized.

Copy link
Contributor

@jacknagel jacknagel commented Mar 23, 2011

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

This comment has been minimized.

Copy link
Contributor

@kulakowski kulakowski commented Mar 23, 2011

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

@kelsin

This comment has been minimized.

Copy link

@kelsin kelsin commented Apr 3, 2011

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

@yacoob

This comment has been minimized.

Copy link
Contributor Author

@yacoob yacoob commented Apr 5, 2011

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

This comment has been minimized.

Copy link

@flips flips commented Apr 30, 2011

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

This comment has been minimized.

Copy link
Contributor

@deasmi deasmi commented Jun 16, 2012

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

This comment has been minimized.

Copy link

@rlridenour rlridenour commented Jan 14, 2013

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

This comment has been minimized.

Copy link

@pmetzner pmetzner commented Mar 26, 2013

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

This comment has been minimized.

Copy link

@harrylove harrylove commented Oct 26, 2013

  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

This comment has been minimized.

Copy link

@carlgieringer carlgieringer commented Apr 18, 2014

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

This comment has been minimized.

Copy link
Contributor

@zzamboni zzamboni commented Dec 8, 2014

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

This comment has been minimized.

Copy link
Member

@MikeMcQuaid MikeMcQuaid commented Dec 8, 2014

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

This comment has been minimized.

Copy link
Contributor

@DomT4 DomT4 commented Dec 9, 2014

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

This comment has been minimized.

Copy link
Contributor

@elyscape elyscape commented Feb 19, 2015

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

This comment has been minimized.

Copy link
Contributor

@zzamboni zzamboni commented Feb 19, 2015

@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

This comment has been minimized.

Copy link

@jasonm23 jasonm23 commented Mar 28, 2015

@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

This comment has been minimized.

Copy link

@deepak deepak commented Jun 30, 2015

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

This comment has been minimized.

Copy link
Contributor

@zzamboni zzamboni commented Jun 30, 2015

@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

This comment has been minimized.

Copy link

@lukehoersten lukehoersten commented Sep 15, 2015

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

This comment has been minimized.

Copy link
Contributor

@DomT4 DomT4 commented Sep 15, 2015

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

@btzo

This comment has been minimized.

Copy link

@btzo btzo commented Oct 24, 2015

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

@Allezxandre

This comment has been minimized.

Copy link

@Allezxandre Allezxandre commented Dec 29, 2015

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

This comment has been minimized.

Copy link

@jasonm23 jasonm23 commented Dec 29, 2015

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

This comment has been minimized.

Copy link
Contributor

@dunn dunn commented Dec 29, 2015

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

This comment has been minimized.

Copy link

@Allezxandre Allezxandre commented Dec 29, 2015

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 comment has been minimized.

Copy link

@jasonm23 jasonm23 commented Dec 29, 2015

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

This comment has been minimized.

Copy link
Contributor

@elyscape elyscape commented Dec 29, 2015

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

@jasonm23

This comment has been minimized.

Copy link

@jasonm23 jasonm23 commented Dec 29, 2015

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

This comment has been minimized.

Copy link

@lukehoersten lukehoersten commented Dec 30, 2015

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

This comment has been minimized.

Copy link

@lukehoersten lukehoersten commented Dec 30, 2015

@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

This comment has been minimized.

Copy link

@jasonm23 jasonm23 commented Dec 30, 2015

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

This comment has been minimized.

Copy link

@jasonm23 jasonm23 commented Dec 30, 2015

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

This comment has been minimized.

Copy link
Member

@MikeMcQuaid MikeMcQuaid commented Dec 30, 2015

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!

@Homebrew Homebrew locked and limited conversation to collaborators Dec 30, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.