GNU bug report logs - #6179
OSX: Emacs.app is loading files specified by relative pathname twice

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6179 in the body.
You can then email your comments to 6179 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Roy Liu <royliu <at> cs.ucsd.edu>
To: submit <at> debbugs.gnu.org
Subject: OSX: Emacs.app is loading files specified by relative pathname twice
Date: Wed, 12 May 2010 19:46:29 -0700

[Message part 1 (text/plain, inline)]

Package: emacs
Version: 23.2

I've noticed strange loading behavior for Emacs.app when I wrap it with a
script:


#!/bin/bash

/Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs "$@"


Here are my observations:
1) For files specified with --find-file and --find and --visit, loading goes
fine.
2) For files specified with absolute paths, loading is also fine.
3) For files specified with relative pathnames, things start getting weird.
 For example, loading "a/b/c/d.txt" will load the desired file, but it will
then try to load "a/b/c/a/b/c/d.txt", which clearly doesn't exist.  It's as
if directory "a/b/c" has been added to some sort of search path (in addition
to $PWD) in which emacs then relatively searches for "a/b/c/d.txt", thus
resulting in the joined result "a/b/c/a/b/c/d.txt".

I don't know if this should be a bug, since the desired usage of Emacs.app
is to run through the window manager (some form of "open"), which is a
sheltered environment.
I've built Emacs.app from MacPorts, which, from what I can tell, introduces
no special modifications or patches, and so I believe that this defect is
repeatable.

-Roy

[Message part 2 (text/html, inline)]

Message #8 received at 6179 <at> debbugs.gnu.org (full text, mbox):

From: Roy Liu <royliu <at> cs.ucsd.edu>
To: 6179 <at> debbugs.gnu.org
Subject: Addendum
Date: Sun, 16 May 2010 01:37:55 -0700

[Message part 1 (text/plain, inline)]

I dug into the problem further, and this patch seems to be dealing with the
problem:


--- lisp/term/ns-win.el.orig    2010-05-15 17:14:55.000000000 -0700
+++ lisp/term/ns-win.el 2010-05-15 17:15:00.000000000 -0700
@@ -785,7 +785,7 @@
   "Do a `find-file' with the `ns-input-file' as argument."
   (interactive)
   (let ((f) (file) (bufwin1) (bufwin2))
-    (setq f (file-truename (car ns-input-file)))
+    (setq f (car ns-input-file))
     (setq ns-input-file (cdr ns-input-file))
     (setq file (find-file-noselect f))
     (setq bufwin1 (get-buffer-window file 'visible))
@@ -802,8 +802,7 @@
       (select-window bufwin2)
       (find-file f))
      (ns-pop-up-frames
-      (ns-hide-emacs 'activate)
-      (let ((pop-up-frames t)) (pop-to-buffer file nil)))
+      (ns-hide-emacs 'activate))
      (t
       (ns-hide-emacs 'activate)
       (find-file f)))))
Documents/build/macports/a


Unfortunately, since I am no Emacs-app expert, I can't tell you in clear
terms what it does exactly.  Perhaps a guru can elucidate.

-Roy

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.