[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7872: Possible fix for relative pathnames given through the command
bug#7872: Possible fix for relative pathnames given through the command line
Wed, 26 Jan 2011 19:06:34 +0100
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:126.96.36.199) Gecko/20101207 Thunderbird/3.1.7
It seems the right thing to do. Checked in. In the future, please use M-x
report-emacs-bug so we can see the version you are reporting against. The
trunk version looks quite different. It is likely there will be a merge
Roy Liu skrev 2011-01-20 03.48:
I've noticed that Emacs.app opens up relative pathnames twice -- once for the
actual file, and once for the relative pathname appended to the directory of
the current buffer.
For example, trying to open by "a/b/text.txt" opens "a/b/text.txt" and
attempts to open "a/b/a/b/text.txt".
I wonder if the following patch corrects the problem:
--- lisp/term/ns-win.el.orig 2010-12-12 23:31:04.000000000 -0500
+++ lisp/term/ns-win.el 2010-12-12 23:32:00.000000000 -0500
@@ -785,7 +785,7 @@
"Do a `find-file' with the `ns-input-file' as argument."
(let ((f) (file) (bufwin1) (bufwin2))
- (setq f (file-truename (car ns-input-file)))
+ (setq f (file-truename (expand-file-name (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))
Here, the input filename is expanded according to the current working
directory when Emacs was invoked. Since I'm no expert, I don't know if this
breaks something else.
Thanks for your time!