Re: master 82ccc3a: ; Mention the previous change in NEWS

[Dmitry Gutov]

On 08.06.2021 15:16, Eli Zaretskii wrote:
> > Cc: emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > 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.

Just helping get the details right.

> > >     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?

It's a prominent variable, and the change can affect other users of it, 
ones we don't control. It also might be handy to know of if some user 
does encounter a compatibility problem (as we discussed, it's unlikely, 
but still).

> > 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?

No, that's what it does: it passes for directory to search in through 
the value of default-directory. The argument to 'find' is always ".".

> > 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.

Is that better than saying that the variable changed? Possibly affecting 
any code that uses it is an obvious implication.

We can say that about xref-matches-in-directory, noting that the change 
is likely to only be noticeable with old versions of 'find'. Which 
apparently includes macOS systems, but I'm not sure which ones, and 
whether using "Homebrew" or not matters for this case.

Also, we'll probably mark xref-matches-in-directory as obsolete sooner 
or later (xref-matches-in-files is generally a better, more composable 
choice), so I'm not sure how much attention we should bring to it.

> > 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.

I figured you wanted to enumerate the exact commands that were affected. 
Hence the reply.