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

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

[Eli Zaretskii]

> +*** 'grep-find-template' now includes the 'find' option '-H'.
> +

I think it would be better to say something like

  *** Commands that use 'grep-find' now follow symlinks by default.
  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?

Thanks.

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

[Dmitry Gutov]

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, but won't do 
that for any of the directories inside the searched directory that are 
also symlinks.

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

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.

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

semantic/symref/grep.el doesn't use the "exclusions" argument.

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

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

[Eli Zaretskii]

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

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

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.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 8 Jun 2021 17:46:16 +0300
> 
> >>>     *** 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.

Sure; thanks.

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

Not sure I follow: the user could customize grep-find-template to put
a specific directory instead of <D>, 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.
> 
> Is that better than saying that the variable changed? Possibly affecting 
> any code that uses it is an obvious implication.

How about saying both?

> We can say that about xref-matches-in-directory, noting that the change 
> is likely to only be noticeable with old versions of 'find'.

That'd be good, yes.

> Which apparently includes macOS systems, but I'm not sure which
> ones, and whether using "Homebrew" or not matters for this case.

Maybe also some *BSD?  We could mention macOS, or we could say
something like "non-GNU Find".

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

We aren't there yet, though.

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

I thought that was possible.  If not, let's say what we can.

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

[Dmitry Gutov]

On 08.06.2021 18:02, Eli Zaretskii wrote:

>>>> 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 ".".
> 
> Not sure I follow: the user could customize grep-find-template to put
> a specific directory instead of <D>, right?

I'm talking about what the 'rgrep' command does. As well as its variants 
like zrgrep.

Customizing grep-find-template to include a specific directory sounds 
stupid: that would break rgrep and other commands that use it.

So I probably don't understand what you meant.

>>>> 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.
> 
> How about saying both?

No objection from me.

>> We can say that about xref-matches-in-directory, noting that the change
>> is likely to only be noticeable with old versions of 'find'.
> 
> That'd be good, yes.
> 
>> Which apparently includes macOS systems, but I'm not sure which
>> ones, and whether using "Homebrew" or not matters for this case.
> 
> Maybe also some *BSD?  We could mention macOS, or we could say
> something like "non-GNU Find".

Some -- maybe.

But I tried one or two recent FreeBSD releases in a VM, and they didn't 
have that problem.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 8 Jun 2021 18:21:19 +0300
> 
> Customizing grep-find-template to include a specific directory sounds 
> stupid: that would break rgrep and other commands that use it.
> 
> So I probably don't understand what you meant.

What I meant was that <D> is there, and it could be used to mean
something other than ".".  But I don't think it's worth our while to
continue developing this sub-thread, it is not important enough for
the issue at hand.

> >>>> 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.
> > 
> > How about saying both?
> 
> No objection from me.
> 
> >> We can say that about xref-matches-in-directory, noting that the change
> >> is likely to only be noticeable with old versions of 'find'.
> > 
> > That'd be good, yes.
> > 
> >> Which apparently includes macOS systems, but I'm not sure which
> >> ones, and whether using "Homebrew" or not matters for this case.
> > 
> > Maybe also some *BSD?  We could mention macOS, or we could say
> > something like "non-GNU Find".
> 
> Some -- maybe.
> 
> But I tried one or two recent FreeBSD releases in a VM, and they didn't 
> have that problem.

So would you like me to propose the wording, or will you do it?

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

[Dmitry Gutov]

On 08.06.2021 18:44, Eli Zaretskii wrote:

> What I meant was that <D> is there, and it could be used to mean
> something other than ".".  But I don't think it's worth our while to
> continue developing this sub-thread, it is not important enough for
> the issue at hand.

Yes, of course. That's what other users of grep-find-template do (I 
mentioned them in the first reply).

>>>> Which apparently includes macOS systems, but I'm not sure which
>>>> ones, and whether using "Homebrew" or not matters for this case.
>>>
>>> Maybe also some *BSD?  We could mention macOS, or we could say
>>> something like "non-GNU Find".
>>
>> Some -- maybe.
>>
>> But I tried one or two recent FreeBSD releases in a VM, and they didn't
>> have that problem.
> 
> So would you like me to propose the wording, or will you do it?

I'd rather leave that to you. Happy to review the updates, though.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 8 Jun 2021 18:56:11 +0300
> 
> > So would you like me to propose the wording, or will you do it?
> 
> I'd rather leave that to you. Happy to review the updates, though.

How about the below?

  *** Commands that use 'grep-find' now follow symlinks for command-line args.
  This is because the default value of 'grep-find-template' now includes
  the 'find' option '-H'.  Commands that use that variable, including
  indirectly via a call to 'xref-matches-in-directory', will be
  affected.  In particular, there should be no need anymore to ensure
  any directory names on the 'find' command lines end in a slash.
  However, the change is likely to affect only old versions of non-GNU
  'find'.

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

[Dmitry Gutov]

On 10.06.2021 15:16, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Tue, 8 Jun 2021 18:56:11 +0300
>>
>>> So would you like me to propose the wording, or will you do it?
>>
>> I'd rather leave that to you. Happy to review the updates, though.
> 
> How about the below?
> 
>    *** Commands that use 'grep-find' now follow symlinks for command-line args.

                             ^grep-find-template, right?

>    This is because the default value of 'grep-find-template' now includes
>    the 'find' option '-H'.  Commands that use that variable, including
>    indirectly via a call to 'xref-matches-in-directory', will be
>    affected.  In particular, there should be no need anymore to ensure
>    any directory names on the 'find' command lines end in a slash.

Looks good.

>    However, the change is likely to affect only old versions of non-GNU
>    'find'.

Not exactly: the change (as described above) will affect all versions 
everywhere.

What is special about "old versions of non-GNU 'find'", is that the 
previous scheme (ensuring directory names end in a slash) created 
problems when used together with them.

We might also want to mention macOS specifically, otherwise the change 
sounds a bit ridiculous (why do we go out of the way to be compatible 
with ancient versions of 'find'?)

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 10 Jun 2021 15:26:48 +0300
> 
> >    *** Commands that use 'grep-find' now follow symlinks for command-line args.
> 
>                              ^grep-find-template, right?
> 
> >    This is because the default value of 'grep-find-template' now includes
> >    the 'find' option '-H'.  Commands that use that variable, including
> >    indirectly via a call to 'xref-matches-in-directory', will be
> >    affected.  In particular, there should be no need anymore to ensure
> >    any directory names on the 'find' command lines end in a slash.
> 
> Looks good.
> 
> >    However, the change is likely to affect only old versions of non-GNU
> >    'find'.
> 
> Not exactly: the change (as described above) will affect all versions 
> everywhere.
> 
> What is special about "old versions of non-GNU 'find'", is that the 
> previous scheme (ensuring directory names end in a slash) created 
> problems when used together with them.
> 
> We might also want to mention macOS specifically, otherwise the change 
> sounds a bit ridiculous (why do we go out of the way to be compatible 
> with ancient versions of 'find'?)

So what change do you propose to the last sentence?

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

[Dmitry Gutov]

On 10.06.2021 17:20, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Thu, 10 Jun 2021 15:26:48 +0300
>>
>>>     *** Commands that use 'grep-find' now follow symlinks for command-line args.
>>
>>                               ^grep-find-template, right?
>>
>>>     This is because the default value of 'grep-find-template' now includes
>>>     the 'find' option '-H'.  Commands that use that variable, including
>>>     indirectly via a call to 'xref-matches-in-directory', will be
>>>     affected.  In particular, there should be no need anymore to ensure
>>>     any directory names on the 'find' command lines end in a slash.
>>
>> Looks good.
>>
>>>     However, the change is likely to affect only old versions of non-GNU
>>>     'find'.
>>
>> Not exactly: the change (as described above) will affect all versions
>> everywhere.
>>
>> What is special about "old versions of non-GNU 'find'", is that the
>> previous scheme (ensuring directory names end in a slash) created
>> problems when used together with them.
>>
>> We might also want to mention macOS specifically, otherwise the change
>> sounds a bit ridiculous (why do we go out of the way to be compatible
>> with ancient versions of 'find'?)
> 
> So what change do you propose to the last sentence?

Something like:

   The main goal of this change is better compatibility with old 
versions of non-GNU 'find', such as the one distributed together with macOS.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 10 Jun 2021 20:06:09 +0300
> 
> > So what change do you propose to the last sentence?
> 
> Something like:
> 
>    The main goal of this change is better compatibility with old 
> versions of non-GNU 'find', such as the one distributed together with macOS.

Thanks, pushed.