From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Irritation in C-u M-x grep, caused by overprotectiveness Date: Sun, 29 Jul 2007 13:33:06 -0400 Message-ID: References: <20070729110910.GA1955@muc.de> <20070729153027.GB1955@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1185730400 2062 80.91.229.12 (29 Jul 2007 17:33:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2007 17:33:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 29 19:33:14 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IFCdl-0005gq-AZ for ged-emacs-devel@m.gmane.org; Sun, 29 Jul 2007 19:33:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IFCdk-0007y6-R2 for ged-emacs-devel@m.gmane.org; Sun, 29 Jul 2007 13:33:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IFCdh-0007xp-GN for emacs-devel@gnu.org; Sun, 29 Jul 2007 13:33:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IFCdg-0007xY-A8 for emacs-devel@gnu.org; Sun, 29 Jul 2007 13:33:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IFCdg-0007xV-6i for emacs-devel@gnu.org; Sun, 29 Jul 2007 13:33:08 -0400 Original-Received: from tomts40.bellnexxia.net ([209.226.175.97] helo=tomts40-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IFCdf-0004Sb-TE for emacs-devel@gnu.org; Sun, 29 Jul 2007 13:33:08 -0400 Original-Received: from pastel.home ([70.53.195.62]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070729173307.XASD29719.tomts40-srv.bellnexxia.net@pastel.home> for ; Sun, 29 Jul 2007 13:33:07 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D10CB8014; Sun, 29 Jul 2007 13:33:06 -0400 (EDT) In-Reply-To: <20070729153027.GB1955@muc.de> (Alan Mackenzie's message of "Sun\, 29 Jul 2007 15\:30\:27 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:75785 Archived-At: >> Currently the code checks whether the previous "list of files" >> (typically a global pattern) matches the current buffer's file name. > No, it doesn't quite do this. If several "filenames" have been given on > the top command line of grep's history, it only uses the first one, > (match-string 3 grep-default). Maybe it should be using (substring > grep-default (match-begin 3)) instead. But this is a separate issue. Yes, the code could be improved. >> If it does then the previous list of files is reused, otherwise the >> previous list of files is ignored and replaced by a new glob pattern. >> Now in your case, the list of files which *you* wrote did not "match" >> the current buffer's file name, so clearly, the above heuristic >> shouldn't be applied anyway. I.e. we should only check "does it match >> the current file?" if it did match the current file in its previous >> use. > Maybe $VARIABLEs should be evaluated first. What do you think? > Something like (getenv (substring grep-default (1+ (match-begin 3)))) fed > into `regexp-opt', each element having been through `wildcard-to-regexp'. > That might be heavy overkill, though. Again, I agree that the implementation of the heuristic can be improved, but in any case the implementation won't be perfect and the heuristic isn't always correct, so it seems that if the heuristic doesn't apply to the original case (either because of imperfect implementation or for some other reason), then there's no reason to think it'll apply to the next case. Stefan