GNU bug report logs - #5316
make[1]: Leaving directory vs. RET

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 5316 in the body.
You can then email your comments to 5316 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: jidanni <at> jidanni.org
To: bug-gnu-emacs <at> gnu.org
Subject: make[1]: Leaving directory vs. RET
Date: Tue, 05 Jan 2010 03:43:11 +0800

Regarding these two lines,
make[1]: Entering directory `/home/jidanni/pda/webtree/addresses'
make[1]: Leaving directory `/home/jidanni/pda/webtree/addresses'
If the user places the cursor upon the directory in the latter and hits
RET, emacs should visit there, just like when he does it on the former.
Instead, it goes to default-directory.

emacs-version "23.1.90.1"

-*- mode: compilation; default-directory: "/home/jidanni/pda/palm/" -*-
Compilation started at Tue Jan  5 03:34:48

make pluckBBDB
cd ../webtree/addresses && make /tmp/BBDB
make[1]: Entering directory `/home/jidanni/pda/webtree/addresses'
emacs -batch -eval \
	'(progn(bbdb "." t)(other-window 1)(bbdb-display-all-records-completely nil)(set-buffer-file-coding-system (quote utf-8-unix) nil)(write-file "abb.txt"))'
Loading 00debian-vars...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50bbdb.el (source)...
Loading /etc/emacs/site-start.d/50css-mode.el (source)...
Loading /etc/emacs/site-start.d/50dictem.el (source)...
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Skipping dictionaries-common setup for emacs-snapshot
Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)...
Loading /etc/emacs/site-start.d/50html-helper-mode.el (source)...
Loading /etc/emacs/site-start.d/50php-elisp.el (source)...
Loading /etc/emacs/site-start.d/50psvn.el (source)...
Loading /etc/emacs/site-start.d/50riece.el (source)...
Loading /etc/emacs/site-start.d/50w3m-el-snapshot.el (source)...
Loading /etc/emacs/site-start.d/51debian-el.el (source)...
Loading /etc/emacs/site-start.d/70x-face-el.el (source)...
Parsing BBDB...
Parsing BBDB... (reading...)
Parsing BBDB... (frobnicating...)
Parsing BBDB... (frobnicating...done)
Window height 3 too small (after splitting)
make[1]: *** [abb.txt] Error 255
make[1]: Leaving directory `/home/jidanni/pda/webtree/addresses'
make: *** [pluckBBDB] Error 2

Compilation exited abnormally with code 2 at Tue Jan  5 03:34:53

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: jidanni <at> jidanni.org
Cc: 5316 <at> debbugs.gnu.org
Subject: Re: bug#5316: make[1]: Leaving directory vs. RET
Date: Wed, 21 Aug 2019 17:19:18 -0700

jidanni <at> jidanni.org writes:

> Regarding these two lines,
> make[1]: Entering directory `/home/jidanni/pda/webtree/addresses'
> make[1]: Leaving directory `/home/jidanni/pda/webtree/addresses'
> If the user places the cursor upon the directory in the latter and hits
> RET, emacs should visit there, just like when he does it on the former.
> Instead, it goes to default-directory.

I tried reproducing this in Emacs 27 when compiling:

make[2]: Entering directory '/home/larsi/src/emacs/trunk/doc/lispref'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/home/larsi/src/emacs/trunk/doc/lispref'
make -C doc/lispintro info
make[2]: Entering directory '/home/larsi/src/emacs/trunk/doc/lispintro'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/home/larsi/src/emacs/trunk/doc/lispintro'

And putting point in the string portion of Entering/Leaving takes me to
the directory in question, so that's been fixed, apparently?  Are you
still able to see this bug in modern Emacs versions?

But if I put point on "make[1]:", then I get this backtrace:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-name-absolute-p(nil)
  compilation-find-file(#<marker at 7825 in *compilation*> nil nil)
  apply(compilation-find-file #<marker at 7825 in *compilation*> nil nil nil)
  compilation-next-error-function(0 nil)
  next-error-internal()
  compile-goto-error(return)
  funcall-interactively(compile-goto-error return)
  call-interactively(compile-goto-error nil nil)
  command-execute(compile-goto-error)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 5316 <at> debbugs.gnu.org
Subject: Re: bug#5316: make[1]: Leaving directory vs. RET
Date: Fri, 23 Aug 2019 05:24:59 +0800

>>>>> "LI" == Lars Ingebrigtsen <larsi <at> gnus.org> writes:
LI> And putting point in the string portion of Entering/Leaving takes me to
LI> the directory in question, so that's been fixed, apparently?  Are you
LI> still able to see this bug in modern Emacs versions?
I just use Debian's emacs-version "26.1", so I'll trust you.

LI> But if I put point on "make[1]:", then I get this backtrace:

OK please fix that then.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 5316 <at> debbugs.gnu.org
Subject: Re: bug#5316: make[1]: Leaving directory vs. RET
Date: Sun, 13 Oct 2019 22:22:42 +0200

積丹尼 Dan Jacobson <jidanni <at> jidanni.org> writes:

>>>>>> "LI" == Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> LI> And putting point in the string portion of Entering/Leaving takes me to
> LI> the directory in question, so that's been fixed, apparently?  Are you
> LI> still able to see this bug in modern Emacs versions?
> I just use Debian's emacs-version "26.1", so I'll trust you.
>
> LI> But if I put point on "make[1]:", then I get this backtrace:
>
> OK please fix that then.

OK; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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