[OS X] new variable for app bundle path

[OS X] new variable for app bundle path

[Seiji Zenitani]

Hi,

Is it possible to provide a new variable for Carbon port, which  
stands for the application bundle path?  The application bundle path  
is a path for the double-clickable application icon (e.g. / 
Applications/Emacs.app), while the other emacs directories such as  
data-dir depend on the configuration option: /usr/local/share/share/ 
emacs/22.1/etc/ (default) or ${app_path}/Contents/Resources/etc/ (-- 
self-contained).  Usually a platform-only variable may not be  
favorable, but I believe the application bundle path is fundamental  
enough.  A patch to the EMACS_22_BASE branch is attached.  It works  
fine for me since June.  Similar variable will be easily introduced  
to the future Cocoa port, too.

Seiji Zenitani
zenitani@mac.com


--- src/mac.c.orig  2007-04-20 09:26:45.000000000 -0400
+++ src/mac.c       2007-06-09 18:54:42.000000000 -0400
@@ -93,6 +93,8 @@
  static OSErr fsspec_to_posix_pathname P_ ((const FSSpec *, char *,  
int));
  #endif

+Lisp_Object Vmac_app_path;
+
  /* When converting from Mac to Unix pathnames, /'s in folder names are
     converted to :'s.  This function, used in copying folder names,
     performs a strncat and converts all character a to b in the copy of
@@ -5402,6 +5406,10 @@
        if (stat (p, &st) == 0 && (st.st_mode & S_IFMT) == S_IFDIR)
  	setenv ("INFOPATH", p, 1);
      }
+
+  strcpy (p, app_bundle_pathname);
+  Vmac_app_path = build_string(p);
+
  }
  #endif /* MAC_OSX */

@@ -5479,6 +5495,10 @@
  This is not a POSIX locale ID, but an ICU locale ID.  So encoding
  information is not included.  */);
    Vmac_system_locale = mac_get_system_locale ();
+
+  DEFVAR_LISP ("mac-app-path", &Vmac_app_path,
+    doc: /* Path to the Emacs application bundle.  */);
+
  }

  /* arch-tag: 29d30c1f-0c6b-4f88-8a6d-0558d7f9dbff

Re: [OS X] new variable for app bundle path

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 1 Sep 2007 21:37:35 -0400, Seiji Zenitani <zenitani@mac.com> said:

> Is it possible to provide a new variable for Carbon port, which
> stands for the application bundle path?

Can't it be deduced from invocation-directory?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [OS X] new variable for app bundle path

[Seiji Zenitani]

Yes,

(expand-file-name "../.." invocation-directory)

would be an alternative on Mac window environment.
By the way, when invoked from CLI, invocation-directory returns
"/usr/local/bin" or "/Application/Emacs.app/Contents/MacOS".
On the other hand, the new variable will be more logical:
0 (strictly speaking, it should be nil) or "/Application/Emacs.app".

Seiji Zenitani
zenitani@mac.com


On 2007/09/01, at 22:11, YAMAMOTO Mitsuharu wrote:

>>>>>> On Sat, 1 Sep 2007 21:37:35 -0400, Seiji Zenitani  
>>>>>> <zenitani@mac.com> said:
>
>> Is it possible to provide a new variable for Carbon port, which
>> stands for the application bundle path?
>
> Can't it be deduced from invocation-directory?
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

Re: [OS X] new variable for app bundle path

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 2 Sep 2007 22:54:04 -0400, Seiji Zenitani <zenitani@mac.com> said:

> (expand-file-name "../.." invocation-directory)

> would be an alternative on Mac window environment.  By the way, when
> invoked from CLI, invocation-directory returns "/usr/local/bin" or
> "/Application/Emacs.app/Contents/MacOS".  On the other hand, the new
> variable will be more logical: 0 (strictly speaking, it should be
> nil) or "/Application/Emacs.app".

Why don't you check window-system additionally?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [OS X] new variable for app bundle path

[Seiji Zenitani]

On 2007/09/02, at 23:16, YAMAMOTO Mitsuharu wrote:

>> By the way,
>> when invoked from CLI, invocation-directory returns "/usr/local/ 
>> bin" or
>> "/Application/Emacs.app/Contents/MacOS".  On the other hand, the new
>> variable will be more logical: 0 (strictly speaking, it should be
>> nil) or "/Application/Emacs.app".
>
> Why don't you check window-system additionally?
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

Checking window-system ('mac) cannot distinguish two CLI (command  
line interface) cases.  The mac-app-path should be available even  
when emacs is invoked from the CLI (/Application/Emacs.app/Contents/ 
MacOS/Emacs -nw) inside the app bundle folder.  On the other hand, it  
should not be available when invoked from /usr/local/bin/emacs.

Seiji Zenitani
zenitani@mac.com

Re: [OS X] new variable for app bundle path

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 2 Sep 2007 23:59:26 -0400, Seiji Zenitani <zenitani@mac.com> said:

> Checking window-system ('mac) cannot distinguish two CLI (command
> line interface) cases.

Sorry, in the previous mail, I misunderstood the cases you want to
distinguish.

> The mac-app-path should be available even when emacs is invoked
> from the CLI (/Application/Emacs.app/Contents/ MacOS/Emacs -nw)
> inside the app bundle folder.  On the other hand, it should not be
> available when invoked from /usr/local/bin/emacs.

Actually, I thought of this case when I replied first.  My idew was
not just a single expand-file-name call but with checking whether
invocation-directory ends with "/Contents/MacOS/".  That's why I used
the term "deduce".

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [OS X] new variable for app bundle path

[Seiji Zenitani]

On 2007/09/03, at 0:18, YAMAMOTO Mitsuharu wrote:

>> The mac-app-path should be available even when emacs is invoked
>> from the CLI (/Application/Emacs.app/Contents/MacOS/Emacs -nw)
>> inside the app bundle folder.  On the other hand, it should not be
>> available when invoked from /usr/local/bin/emacs.
>
> Actually, I thought of this case when I replied first.  My idea was
> not just a single expand-file-name call but with checking whether
> invocation-directory ends with "/Contents/MacOS/".  That's why I used
> the term "deduce".

Checking "(*.app)/Contents/MacOS" will work in many cases,
but it is also true that I don't want to rely on such string operations.

Seiji Zenitani
zenitani@mac.com

Re: [OS X] new variable for app bundle path

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 3 Sep 2007 16:32:04 -0400, Seiji Zenitani <zenitani@mac.com> said:

> Checking "(*.app)/Contents/MacOS" will work in many cases, but it is
> also true that I don't want to rely on such string operations.

I don't think it is worth introducing such a platform-specific new
Lisp variable just for getting the location of the application bundle.
And it can be obtained using a simple Lisp program except for very
pathological cases.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp