emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#21175: closed (24.5; progmodes/etags.el: next-file


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#21175: closed (24.5; progmodes/etags.el: next-file does (find-file next novisit))
Date: Sat, 01 Aug 2015 11:46:02 +0000

Your message dated Sat, 1 Aug 2015 14:45:06 +0300
with message-id <address@hidden>
and subject line Re: bug#21175: 24.5; progmodes/etags.el: next-file does 
(find-file next novisit)
has caused the debbugs.gnu.org bug report #21175,
regarding 24.5; progmodes/etags.el: next-file does (find-file next novisit)
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
21175: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21175
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.5; progmodes/etags.el: next-file does (find-file next novisit) Date: Sat, 01 Aug 2015 11:53:04 +0200 User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 when submitting bug #21167 I looked at the source code in progmodes/etags.el and wondered why next-file
passes the novisit flag when calling find-file.

novisit asks tags to use a temp buffer " *next-file*" rather than visiting the file unless it is already visited (in which case we want tags to search the version that we are currently editing and modifying). It is t by default.

What is actually done is (line 1765 in v24.5):

    (if (not (and new novisit))
      (find-file next novisit)
      ;; Like find-file, but avoids random warning messages.

So when the file is already visited, new is nil in the above code and we just use find-file.

Passing novisit is dangerous since find-file takes this as the wildcards flag, nothing to do with the meaning of novisit. Actually, if the filename contains * or ? (and is currently visited, or "not new") tags may create many buffers visiting many files that match the filename interpreted as a pattern, not an actual file name. What buffer will be searched next is maybe not the one associated with filename.

The comment too is incorrect.

To trip the bug in an empty directory:
% touch foo1.c foo2.c foo3.c "*.c" ;  etags "*.c"; emacs -q "*.c"
Now modify the *.c buffer, just type foo in it
Now M-x etags-search foo
I get the message "Symbolic link that points to nonexistent file" and emacs has buffers visiting foo{1,2,3}.c that are not listed in the TAGS file.

---
All this seems to be inherited from older versions. I just checked 21.4 from 10+ years ago and it had

    (if (not (and new novisit))
      (set-buffer (find-file-noselect next novisit))
      ;; Like find-file, but avoids random warning messages.

Here too the novisit flag was already misinterpreted but the comment made sense.





--- End Message ---
--- Begin Message --- Subject: Re: bug#21175: 24.5; progmodes/etags.el: next-file does (find-file next novisit) Date: Sat, 1 Aug 2015 14:45:06 +0300 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0
Version: 25.1

On 08/01/2015 12:53 PM, phs wrote:

Passing novisit is dangerous since find-file takes this as the wildcards
flag, nothing to do with the meaning of novisit. Actually, if the
filename contains * or ? (and is currently visited, or "not new") tags
may create many buffers visiting many files that match the filename
interpreted as a pattern, not an actual file name. What buffer will be
searched next is maybe not the one associated with filename.

Thanks, this is fixed now as well.

The comment too is incorrect.

I think the comment refers to the code below it.



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]