GNU bug report logs - #5751
Let ff-find-other-file search other directories (in "project"?)

Previous Next

To reply to this bug, email your comments to 5751 AT debbugs.gnu.org.

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

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

From: Arne Schmitz <arne.schmitz <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Strange behaviour of ff-find-other-file
Date: Sun, 21 Mar 2010 20:21:21 +0100

Hi everyone!

I have found a behaviour in ff-find-other-file that I would consider a
bug. However, I am not sure if this is definitely the case, but at
least I would say that the function's behaviour does not correspond to
it's implementation. The documentation says:

"Find the header or source file corresponding to this file."

Consider the following: the header and source for a certain case are
already being visited. Let's say the source is in
$CWD/project-src/foo.c, and the header in $CWD/include/foo.h. If
either ../project-src or ../include is not in the
ff-search-directories, the appropriate switch to the source or header
file will fail. Consider that this will also fail, if the
corresponding file is already being visited! This is not explicitly
demanded by the documentation, but would be useful behaviour in my
opinion. Looking at the source for ff-find-other-file leads to these
lines in the function ff-get-file-name:

  (if (bufferp (get-file-buffer filename))
      (setq found (buffer-file-name (get-file-buffer filename))))

To my understanding this is supposed to search through the current
buffers for the corresponding file. However, this seems to always
fail, since the variable filename is not expanded, as get-file-buffer
demands, and neither do I see how this is supposed to happen
anyway. So in the least, this code is useless, or worst, broken. Since
I like to have Emacs find the file, if there is a buffer visiting a
file with the correct name (although it might not be unique), I
changed the above lines to the following:

  (let ((b (find-if (lambda(x) (string= (buffer-name x) filename)) (buffer-list))))
    (if b
        (setq found (buffer-file-name b))))

Not sure, if this is the best code to achieve this, since I don't know
Emacs-Lisp very well, and a friend helped me figure this out.

Hope this helps and best regards,

Arne

In GNU Emacs 22.3.1 (i386-apple-darwin9.8.0, Carbon Version 1.6.0)
of 2010-01-10 on gs674-seijiz.local
Windowing system distributor `Apple Inc.', version 10.6.2
configured using `configure  '--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CC=gcc-4.2' 'CFLAGS=-O2 -arch i386 -arch ppc7400 -DUSE_ATSUI -DUSE_MAC_TSM''

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: Help

Minor modes in effect:
 show-paren-mode: t
 server-mode: t
 desktop-save-mode: t
 ecb-minor-mode: t
 tabbar-mwheel-mode: t
 tabbar-mode: t
 which-function-mode: t
 mac-print-mode: t
 tooltip-mode: t
 tool-bar-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
 temp-buffer-resize-mode: t
 column-number-mode: t
 line-number-mode: t
 transient-mark-mode: t
 view-mode: t

Recent input:
<help-echo> <help-echo> <down-mouse-1> <drag-mouse-1> 
<down-mouse-1> <mouse-1> C-x C-f C-a C-k / . e m <tab> 
. d <tab> i n i <tab> <return> <wheel-down> <double-wheel-down> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <wheel-down> <double-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <wheel-down> <double-wheel-down> 
<triple-wheel-down> <down-mouse-1> <mouse-1> C-a C-SPC 
<down> <down> <down> <down> <up> <down> <down> <down> 
M-w C-h f f i n d - o <tab> <tab> <tab> <backspace> 
C-a C-k d <backspace> f f - f i <tab> o <tab> <return> 
C-x o C-x 1 <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<next> <prior> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <up> <up> 
<up> <up> <up> <up> <up> <up> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <up> <up> <up> <up> <up> <up> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <right> <left> <right> 
<right> M-x r e p o r <tab> <return>

Recent messages:
Showing all blocks ... done [3 times]
Showing all blocks ... done [2 times]
Loading semantic-tag-write...done
Mark saved where search started
Mark set
Type C-x 4 C-o RET to restore the other window.  
Loading eieio-opt...done
call-interactively: End of buffer [2 times]
Loading emacsbug...done
Loading dabbrev...done

-- 
Dipl.-Inform. Arne Schmitz              Phone   +49 (0)241 80-21817
Computer Graphics Group                 Mobile  +49 (0)151 29145947
RWTH Aachen University                  Fax     +49 (0)241 80-22899
Ahornstrasse 55, 52074 Aachen, Germany  http://www.rwth-graphics.de

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Arne Schmitz <arne.schmitz <at> gmx.net>
Cc: 5751 <at> debbugs.gnu.org
Subject: Re: bug#5751: Strange behaviour of ff-find-other-file
Date: Thu, 25 Aug 2016 00:16:02 -0400

Sorry for the delay in response here.  I think I understand what you are
saying, but I think we probably would both agree this is more of a
feature request than a bug.

But I'm not sure it makes sense as a feature request - just because you
have foo.c and foo.h, it is dangerous to think they are related just
because they both exist as buffers.  I frequently have multiple copies
of the same file open in different directories to work on different
issues - it would be a bug if ff-find-other-file started flipping
between two very different working directories.

So, I'm closing this one as not a bug. 

Arne Schmitz <arne.schmitz <at> gmx.net> writes:

> Hi everyone!
>
> I have found a behaviour in ff-find-other-file that I would consider a
> bug. However, I am not sure if this is definitely the case, but at
> least I would say that the function's behaviour does not correspond to
> it's implementation. The documentation says:
>
> "Find the header or source file corresponding to this file."
>
> Consider the following: the header and source for a certain case are
> already being visited. Let's say the source is in
> $CWD/project-src/foo.c, and the header in $CWD/include/foo.h. If
> either ../project-src or ../include is not in the
> ff-search-directories, the appropriate switch to the source or header
> file will fail. Consider that this will also fail, if the
> corresponding file is already being visited! This is not explicitly
> demanded by the documentation, but would be useful behaviour in my
> opinion. Looking at the source for ff-find-other-file leads to these
> lines in the function ff-get-file-name:
>
>   (if (bufferp (get-file-buffer filename))
>       (setq found (buffer-file-name (get-file-buffer filename))))
>
> To my understanding this is supposed to search through the current
> buffers for the corresponding file. However, this seems to always
> fail, since the variable filename is not expanded, as get-file-buffer
> demands, and neither do I see how this is supposed to happen
> anyway. So in the least, this code is useless, or worst, broken. Since
> I like to have Emacs find the file, if there is a buffer visiting a
> file with the correct name (although it might not be unique), I
> changed the above lines to the following:
>
>   (let ((b (find-if (lambda(x) (string= (buffer-name x) filename)) (buffer-list))))
>     (if b
>         (setq found (buffer-file-name b))))
>
> Not sure, if this is the best code to achieve this, since I don't know
> Emacs-Lisp very well, and a friend helped me figure this out.
>
> Hope this helps and best regards,
>
> Arne
>
> In GNU Emacs 22.3.1 (i386-apple-darwin9.8.0, Carbon Version 1.6.0)
> of 2010-01-10 on gs674-seijiz.local
> Windowing system distributor `Apple Inc.', version 10.6.2
> configured using `configure  '--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CC=gcc-4.2' 'CFLAGS=-O2 -arch i386 -arch ppc7400 -DUSE_ATSUI -DUSE_MAC_TSM''
>
> 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: Help
>
> Minor modes in effect:
>  show-paren-mode: t
>  server-mode: t
>  desktop-save-mode: t
>  ecb-minor-mode: t
>  tabbar-mwheel-mode: t
>  tabbar-mode: t
>  which-function-mode: t
>  mac-print-mode: t
>  tooltip-mode: t
>  tool-bar-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
>  temp-buffer-resize-mode: t
>  column-number-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
>  view-mode: t
>
> Recent input:
> <help-echo> <help-echo> <down-mouse-1> <drag-mouse-1> 
> <down-mouse-1> <mouse-1> C-x C-f C-a C-k / . e m <tab> 
> . d <tab> i n i <tab> <return> <wheel-down> <double-wheel-down> 
> <triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
> <triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
> <triple-wheel-up> <wheel-down> <double-wheel-down> 
> <triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
> <triple-wheel-down> <wheel-down> <double-wheel-down> 
> <triple-wheel-down> <down-mouse-1> <mouse-1> C-a C-SPC 
> <down> <down> <down> <down> <up> <down> <down> <down> 
> M-w C-h f f i n d - o <tab> <tab> <tab> <backspace> 
> C-a C-k d <backspace> f f - f i <tab> o <tab> <return> 
> C-x o C-x 1 <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <next> <prior> <up> <up> <up> <up> <up> <up> <up> <up> 
> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <down> <down> <down> <up> <up> 
> <up> <up> <up> <up> <up> <up> <down> <down> <down> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <up> <up> <up> <up> <up> <up> 
> <down> <down> <down> <down> <down> <down> <down> <down> 
> <down> <down> <down> <down> <right> <left> <right> 
> <right> M-x r e p o r <tab> <return>
>
> Recent messages:
> Showing all blocks ... done [3 times]
> Showing all blocks ... done [2 times]
> Loading semantic-tag-write...done
> Mark saved where search started
> Mark set
> Type C-x 4 C-o RET to restore the other window.  
> Loading eieio-opt...done
> call-interactively: End of buffer [2 times]
> Loading emacsbug...done
> Loading dabbrev...done

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

From: npostavs <at> users.sourceforge.net
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 5751 <at> debbugs.gnu.org, Arne Schmitz <arne.schmitz <at> gmx.net>
Subject: Re: bug#5751: Strange behaviour of ff-find-other-file
Date: Thu, 25 Aug 2016 21:25:54 -0400

reopen 5751
tags 5751 - notabug
severity 5751 wishlist
retitle 5751 Let ff-find-other-file search other directories (in "project"?)
quit

Andrew Hyatt <ahyatt <at> gmail.com> writes:

> Sorry for the delay in response here.  I think I understand what you are
> saying, but I think we probably would both agree this is more of a
> feature request than a bug.
>
> But I'm not sure it makes sense as a feature request - just because you
> have foo.c and foo.h, it is dangerous to think they are related just
> because they both exist as buffers.  I frequently have multiple copies
> of the same file open in different directories to work on different
> issues - it would be a bug if ff-find-other-file started flipping
> between two very different working directories.
>
> So, I'm closing this one as not a bug. 

I'm reopening, because I think this does make sense as a feature
request.  Generally foo.c and foo.h will be related if they are in the
same "project", so probably the user will want the file to be found in
this case.  I think Emacs recently got some kind of "project API" thing,
perhaps that can be used for this?

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: 5751 <at> debbugs.gnu.org, Arne Schmitz <arne.schmitz <at> gmx.net>
Subject: Re: bug#5751: Strange behaviour of ff-find-other-file
Date: Sun, 28 Aug 2016 05:18:11 +0000

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

On Thu, Aug 25, 2016 at 9:25 PM <npostavs <at> users.sourceforge.net> wrote:

> reopen 5751
> tags 5751 - notabug
> severity 5751 wishlist
> retitle 5751 Let ff-find-other-file search other directories (in
> "project"?)
> quit
>
> Andrew Hyatt <ahyatt <at> gmail.com> writes:
>
> > Sorry for the delay in response here.  I think I understand what you are
> > saying, but I think we probably would both agree this is more of a
> > feature request than a bug.
> >
> > But I'm not sure it makes sense as a feature request - just because you
> > have foo.c and foo.h, it is dangerous to think they are related just
> > because they both exist as buffers.  I frequently have multiple copies
> > of the same file open in different directories to work on different
> > issues - it would be a bug if ff-find-other-file started flipping
> > between two very different working directories.
> >
> > So, I'm closing this one as not a bug.
>
> I'm reopening, because I think this does make sense as a feature
> request.  Generally foo.c and foo.h will be related if they are in the
> same "project", so probably the user will want the file to be found in
> this case.  I think Emacs recently got some kind of "project API" thing,
> perhaps that can be used for this?
>

This makes more sense the original proposal, but I'm still not so sure.
For example, how many projects have multiple directories with files called
util.c?  Probably quite a few.  I think any assumptions we make here will
be bound to cause problems.

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

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 5751 <at> debbugs.gnu.org, Arne Schmitz <arne.schmitz <at> gmx.net>
Subject: Re: bug#5751: Strange behaviour of ff-find-other-file
Date: Mon, 29 Aug 2016 17:55:38 -0400

On Sun, Aug 28, 2016 at 1:18 AM, Andrew Hyatt <ahyatt <at> gmail.com> wrote:
>> I'm reopening, because I think this does make sense as a feature
>> request.  Generally foo.c and foo.h will be related if they are in the
>> same "project", so probably the user will want the file to be found in
>> this case.  I think Emacs recently got some kind of "project API" thing,
>> perhaps that can be used for this?
>
>
> This makes more sense the original proposal, but I'm still not so sure.  For
> example, how many projects have multiple directories with files called
> util.c?  Probably quite a few.  I think any assumptions we make here will be
> bound to cause problems.
>

Probably it will need to be made configurable in the end, but as a
default, I don't think choosing a non-related util.c from another
nearby directory is worse than failing to choose a related one.

Previous Next

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