BUG: emacs-app can't see code installed by other elisp packages

[cmconnelly (Claire Connelly)]

The new emacs-app package installs itself in /Applications/MacPorts/Emacs.app, whereas previous Carbon Emacs installs (such as emacs-devel +carbon) split the Mac OS X application piece off from various support files. Emacs-app doesn't look at the /opt/local/share/emacs directory for other elisp code, so packages such as auctex do not work with emacs-app.

The simple fix appears to be to modify epaths.h at build time to include the /opt/local paths. Alternatively, I would be fine with going back to the way the Carbon Emacs.app was installed in previous Emacs packages.

(Note that it is also possible to modify your load-path in your .emacs file or your EMACSLOADPATH environment variable, either of which works as a temporary workaround. But packaged software should work with other packaged software, so one of the other solutions is needed for a real fix.)

[cssdev]

The current build simply wraps the upstream author's custom script. Ideally that script shouldn't be needed, but that's not the case right now. Given those circumstances, anything that modifies the build might be problematic. The packaged application should perhaps default to load other lisp packages from ${prefix}. I'll check into appending it to the autoload path.

[cssdev]

The latest emacs-app supports a shared-lisp directory. Once I get it built and submitted (see #12718), check if that solves the issue.

[cssdev]

The 0.9rc2 shared-lisp support makes quite a mess, as it scatters files outside the destroot during the build phase.

[cssdev]

The emacs-app sitelisp could just contain:

(setq load-path (cons "/opt/local/share/emacs/site-lisp" load-path))

[cssdev]

site startup will append the prefix to the load path

[cssdev]

Copy the site-start into the application bundle, then patch it to point toward the ${prefix}

[cssdev]

Committed to r34411

[(none)]

Milestone Port Bugs deleted