From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 82ccc3a: ; Mention the previous change in NEWS Date: Tue, 08 Jun 2021 15:16:39 +0300 Message-ID: <835yyoft5k.fsf@gnu.org> References: <83lf7lfwc8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15308"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 08 14:17:48 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lqag0-0003nQ-Dv for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Jun 2021 14:17:48 +0200 Original-Received: from localhost ([::1]:57614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqafz-0007vc-Ab for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Jun 2021 08:17:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57072) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqafA-0005hv-Rp for emacs-devel@gnu.org; Tue, 08 Jun 2021 08:16:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59994) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqafA-0006rW-GV; Tue, 08 Jun 2021 08:16:56 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2123 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqafA-0002vd-3E; Tue, 08 Jun 2021 08:16:56 -0400 In-Reply-To: (message from Dmitry Gutov on Tue, 8 Jun 2021 03:48:46 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270561 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Tue, 8 Jun 2021 03:48:46 +0300 > > On 07.06.2021 19:55, Eli Zaretskii wrote: > > I think it would be better to say something like > > > > *** Commands that use 'grep-find' now follow symlinks by default. > > Not exactly: going by the option's description in the manual, it follows > symlinks for all arguments passed from the command line That's easily fixed, and isn't the main point of my message. > > This affects the following commends: 'rgrep', ... > > > > This describes the change in terms of user commands, but can you help > > me comping up with the list of affected commands? > > I don't think there's any visible change in behavior because of that > change. It mostly mirrored the one in 2e55201b8085 for better/uniform > approach to the problem. If there's no visible change in behavior, why have this NEWS entry at all? > The latter change fixed ignore entries not being applied by the default > implementation of project-files with certain old versions of 'find'. > > rgrep, which also has some ignores to handle, uses "." as the DIR > argument, so it should see no change. That's just the default, right? > xref-matches-in-directory has no known callers anymore, but any > third-party code should see the IGNORES honored better with those old > versions of 'find'. So we could say that any command which uses xref-matches-in-directory is affected. > And as for following the symlinks, the existing users of > grep-find-template, which were changed, previously used a different > approach: having DIR end with '/' (hence the file-name-as-directory > calls which were replaced with directory-file-name calls). Once again, if nothing's changed, why did you decide to add this entry? I guess you thought it had some importance. I just think we should better explain what have really changed, and doing that in the terms of a not-so-simple value of an option doesn't make that clear.