* bug#5751: Strange behaviour of ff-find-other-file
@ 2010-03-21 19:21 Arne Schmitz
2016-08-25 4:16 ` Andrew Hyatt
0 siblings, 1 reply; 5+ messages in thread
From: Arne Schmitz @ 2010-03-21 19:21 UTC (permalink / raw)
To: 5751
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5751: Strange behaviour of ff-find-other-file
2010-03-21 19:21 bug#5751: Strange behaviour of ff-find-other-file Arne Schmitz
@ 2016-08-25 4:16 ` Andrew Hyatt
2016-08-26 1:25 ` npostavs
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Hyatt @ 2016-08-25 4:16 UTC (permalink / raw)
To: Arne Schmitz; +Cc: 5751
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@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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5751: Strange behaviour of ff-find-other-file
2016-08-25 4:16 ` Andrew Hyatt
@ 2016-08-26 1:25 ` npostavs
2016-08-28 5:18 ` Andrew Hyatt
0 siblings, 1 reply; 5+ messages in thread
From: npostavs @ 2016-08-26 1:25 UTC (permalink / raw)
To: Andrew Hyatt; +Cc: 5751, Arne Schmitz
reopen 5751
tags 5751 - notabug
severity 5751 wishlist
retitle 5751 Let ff-find-other-file search other directories (in "project"?)
quit
Andrew Hyatt <ahyatt@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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5751: Strange behaviour of ff-find-other-file
2016-08-26 1:25 ` npostavs
@ 2016-08-28 5:18 ` Andrew Hyatt
2016-08-29 21:55 ` Noam Postavsky
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Hyatt @ 2016-08-28 5:18 UTC (permalink / raw)
To: npostavs; +Cc: 5751, Arne Schmitz
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
On Thu, Aug 25, 2016 at 9:25 PM <npostavs@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@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.
[-- Attachment #2: Type: text/html, Size: 1986 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#5751: Strange behaviour of ff-find-other-file
2016-08-28 5:18 ` Andrew Hyatt
@ 2016-08-29 21:55 ` Noam Postavsky
0 siblings, 0 replies; 5+ messages in thread
From: Noam Postavsky @ 2016-08-29 21:55 UTC (permalink / raw)
To: Andrew Hyatt; +Cc: 5751, Arne Schmitz
On Sun, Aug 28, 2016 at 1:18 AM, Andrew Hyatt <ahyatt@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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-08-29 21:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-21 19:21 bug#5751: Strange behaviour of ff-find-other-file Arne Schmitz
2016-08-25 4:16 ` Andrew Hyatt
2016-08-26 1:25 ` npostavs
2016-08-28 5:18 ` Andrew Hyatt
2016-08-29 21:55 ` Noam Postavsky
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).