[ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Richard Stallman]

Would someone please DTRT, then ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer;
	b=kU2F8BG+JXLdwFum4x3UH5HPzeVdiFYCs4Y/ctk/WUub4cn/bDtJhNJI4cT6ZRgtyIrSUQg6WWegDftxZovJS/hsN659Fq14PY5lJ/BLnX1VkFF+NMnrXuT1rKp+cJ6hxeNVw3EkAZ7BORDvx8GX4wtSNc1NQSZE+GAI53wcVUE=
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: bug-gnu-emacs@gnu.org
From: Vagn Johansen <ozymandias.dk@gmail.com>
Date: Fri, 3 Aug 2007 14:13:21 +0200
Subject: compile/grep: When directory tracking is used then next-error fails
	to go to the correct file when the basename was seen before.


The problem occurs occurs when compiling or grepping. After running
the compile command that gave the output seen below then running
next-error four times only visits dir1/file.cpp. The third next-error
should have opened dir2/file.cpp. The problem occurs because the same
filename (basename) file.cpp is used in the two directories.

make -w -C dir1; make -w -C dir2
make: Entering directory `/Users/vagn/tmp/dir1'
g++ -Wall file.cpp
file.cpp: In function 'int main(int, char**)':
file.cpp:5: warning: unused variable 'xx1'
file.cpp:6: warning: unused variable 'xx2'
make: Leaving directory `/Users/vagn/tmp/dir1'
make: Entering directory `/Users/vagn/tmp/dir2'
g++ -Wall file.cpp
file.cpp: In function 'int main(int, char**)':
file.cpp:5: warning: unused variable 'yy'
file.cpp:6: warning: unused variable 'yy2'
make: Leaving directory `/Users/vagn/tmp/dir2'


In GNU Emacs 22.1.1 (i386-apple-darwin8.9.1, Carbon Version 1.6.0)
  of 2007-06-15 on vj-mac.local
Windowing system distributor `Apple Inc.', version 10.4.10
configured using `configure  '--enable-carbon-app''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: iso-latin-1
   default-enable-multibyte-characters: t

Major mode: C++/l

Minor modes in effect:
   shell-dirtrack-mode: t
   encoded-kbd-mode: t
   show-paren-mode: t
   minibuffer-electric-default-mode: t
   iswitchb-mode: t
   dir-locals-mode: t
   display-time-mode: t
   which-function-mode: t
   recentf-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t
   abbrev-mode: t
   hs-minor-mode: t

Recent messages:
compilation-next-error: Moved back before first error
compilation-next-error: Moved past last error
Mark set [2 times]
Wrote /Users/vagn/tmp/dir1/file.cpp
Mark set [3 times]
Auto-saving...done
Wrote /Users/vagn/tmp/dir2/file.cpp
(No files need saving)
Making completion list...
Loading emacsbug...done


- -- 
Vagn Johansen


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

[ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Richard Stallman]

[I sent this message a week ago but did not get a response.]

Would someone please DTRT, then ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer;
	b=kU2F8BG+JXLdwFum4x3UH5HPzeVdiFYCs4Y/ctk/WUub4cn/bDtJhNJI4cT6ZRgtyIrSUQg6WWegDftxZovJS/hsN659Fq14PY5lJ/BLnX1VkFF+NMnrXuT1rKp+cJ6hxeNVw3EkAZ7BORDvx8GX4wtSNc1NQSZE+GAI53wcVUE=
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: bug-gnu-emacs@gnu.org
From: Vagn Johansen <ozymandias.dk@gmail.com>
Date: Fri, 3 Aug 2007 14:13:21 +0200
Subject: compile/grep: When directory tracking is used then next-error fails
	to go to the correct file when the basename was seen before.


The problem occurs occurs when compiling or grepping. After running
the compile command that gave the output seen below then running
next-error four times only visits dir1/file.cpp. The third next-error
should have opened dir2/file.cpp. The problem occurs because the same
filename (basename) file.cpp is used in the two directories.

make -w -C dir1; make -w -C dir2
make: Entering directory `/Users/vagn/tmp/dir1'
g++ -Wall file.cpp
file.cpp: In function 'int main(int, char**)':
file.cpp:5: warning: unused variable 'xx1'
file.cpp:6: warning: unused variable 'xx2'
make: Leaving directory `/Users/vagn/tmp/dir1'
make: Entering directory `/Users/vagn/tmp/dir2'
g++ -Wall file.cpp
file.cpp: In function 'int main(int, char**)':
file.cpp:5: warning: unused variable 'yy'
file.cpp:6: warning: unused variable 'yy2'
make: Leaving directory `/Users/vagn/tmp/dir2'


In GNU Emacs 22.1.1 (i386-apple-darwin8.9.1, Carbon Version 1.6.0)
  of 2007-06-15 on vj-mac.local
Windowing system distributor `Apple Inc.', version 10.4.10
configured using `configure  '--enable-carbon-app''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: iso-latin-1
   default-enable-multibyte-characters: t

Major mode: C++/l

Minor modes in effect:
   shell-dirtrack-mode: t
   encoded-kbd-mode: t
   show-paren-mode: t
   minibuffer-electric-default-mode: t
   iswitchb-mode: t
   dir-locals-mode: t
   display-time-mode: t
   which-function-mode: t
   recentf-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t
   abbrev-mode: t
   hs-minor-mode: t

Recent messages:
compilation-next-error: Moved back before first error
compilation-next-error: Moved past last error
Mark set [2 times]
Wrote /Users/vagn/tmp/dir1/file.cpp
Mark set [3 times]
Auto-saving...done
Wrote /Users/vagn/tmp/dir2/file.cpp
(No files need saving)
Making completion list...
Loading emacsbug...done


- -- 
Vagn Johansen


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: [ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Glenn Morris]

> The problem occurs occurs when compiling or grepping. After running
> the compile command that gave the output seen below then running
> next-error four times only visits dir1/file.cpp. The third
> next-error should have opened dir2/file.cpp. The problem occurs
> because the same filename (basename) file.cpp is used in the two
> directories.
>
> make -w -C dir1; make -w -C dir2
> make: Entering directory `/Users/vagn/tmp/dir1'
> g++ -Wall file.cpp
> file.cpp: In function 'int main(int, char**)':
> file.cpp:5: warning: unused variable 'xx1'
> file.cpp:6: warning: unused variable 'xx2'
> make: Leaving directory `/Users/vagn/tmp/dir1'
> make: Entering directory `/Users/vagn/tmp/dir2'
> g++ -Wall file.cpp
> file.cpp: In function 'int main(int, char**)':
> file.cpp:5: warning: unused variable 'yy'
> file.cpp:6: warning: unused variable 'yy2'
> make: Leaving directory `/Users/vagn/tmp/dir2'


The fix below seems to work (very lightly tested), but please could
someone familiar with compile.el comment. As I see it, the problem is:

In compilation-get-file-structure `file' is (filename . spec-directory),
where filename is a relative file name.

When there is no entry for filename in compilation-locs, the second
puthash below creates a hash entry for just filename, ie "file.cpp".

On each subsequent call to this function, (gethash filename) is going
to return this value. It may not be appropriate if the file is in a
different directory, so if one has directory information one should
use it.


*** compile.el	13 Aug 2007 13:40:55 -0000	1.441
--- compile.el	16 Aug 2007 01:51:34 -0000
***************
*** 1972,1978 ****
  	;; Store it for the possibly unnormalized name
  	(puthash file
  		 ;; Retrieve or create file-structure for normalized name
! 		 (or (gethash (list filename) compilation-locs)
  		     (puthash (list filename)
  			      (list (list filename spec-directory) fmt)
  			      compilation-locs))
--- 1972,1981 ----
  	;; Store it for the possibly unnormalized name
  	(puthash file
  		 ;; Retrieve or create file-structure for normalized name
! 		 (or (gethash (if spec-directory
!                                   (cons filename spec-directory)
!                                 (list filename))
!                                 compilation-locs)
  		     (puthash (list filename)
  			      (list (list filename spec-directory) fmt)
  			      compilation-locs))

Re: [ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Stefan Monnier]

> ! 		 (or (gethash (if spec-directory
> !                                   (cons filename spec-directory)
> !                                 (list filename))
> !                                 compilation-locs)

The indentation on the last line is a bit odd, and

   (if A (cons B A) (list B))  ==  (cons B A)


-- Stefan

Re: [ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Glenn Morris]

Stefan Monnier wrote:

> The indentation on the last line is a bit odd

tabs v spaces

>    (if A (cons B A) (list B))  ==  (cons B A)

Thanks, I missed that.

Re: [ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Richard Stallman]

    On each subsequent call to this function, (gethash filename) is going
    to return this value. It may not be appropriate if the file is in a
    different directory, so if one has directory information one should
    use it.

If we think it is incorrect to retrieve an entry that is filed
under just the filename, should we also delete the code that makes
such an entry?  Under what circumstances would we want such an
entry to exist and be retrieved?

Re: [ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Glenn Morris]

Richard Stallman wrote:

> If we think it is incorrect to retrieve an entry that is filed
> under just the filename, should we also delete the code that makes
> such an entry?  Under what circumstances would we want such an
> entry to exist and be retrieved?

I'm afraid I don't know. I've installed the minimum change I believe
fixes the bug.

Re: [ozymandias.dk@gmail.com: compile/grep: When directory tracking is used then next-error fails to go to the correct file when the basename was seen before.]

[Stefan Monnier]

>> If we think it is incorrect to retrieve an entry that is filed
>> under just the filename, should we also delete the code that makes
>> such an entry?  Under what circumstances would we want such an
>> entry to exist and be retrieved?

>     I'm afraid I don't know. I've installed the minimum change I believe
>     fixes the bug.

> Stefan, can you study that issue?
> It looks like you originally wrote this.

Doesn't ring a bell, but I'll take a look,


        Stefan