Subject: Re: [PATCH] Etags support for Mercury -- fix explicit tags for existentially-quantified procedures

From: Eli Zaretskii <[email-masked]>
Date: Thu, 17 Jun 2021 14:42:47 +0300

> From: Fabrice Nicol <[email-masked]>
> Date: Thu, 17 Jun 2021 13:19:26 +0200
> Cc: Francesco Potortì <[email-masked]>, [email-masked]
> 
>  1. It adds tags for some identifiers that AFAUI are actually
>     keywords, and shouldn't be in the TAGS tables.  Examples:
>     "interface" (e.g., on line 146 of accumulator.m) and
>     "implementation" (e.g., on line 166).  I guess this is unintended?
>     If so, how to fix it?
> 
> This is intended. I commented this in the commit message (one-word declarations). 

Understood, thanks.

>     To fix this second issue, I propose the change below, which should
>     be applied on top of your patches:
> 
>  diff --git a/lib-src/etags.c b/lib-src/etags.c
>  index 370e825..2b0288e 100644
>  --- a/lib-src/etags.c
>  +++ b/lib-src/etags.c
>  @@ -6585,10 +6585,8 @@ mercury_pr (char *s, char *last, ptrdiff_t lastlen)
>               && c_isspace (s[pos - namelength - offset]))
>          --offset;
> 
>  -      /* There is no need to correct namelength or call notinname.  */
>  -      s[pos - offset - 1] = '\0';
>  -
>  -      make_tag (s + pos - namelength - offset, namelength, true, s, pos, lineno, linecharno);
>  +      make_tag (s + pos - namelength - offset, namelength - 1, true,
>  +               s, pos - offset - 1, lineno, linecharno);
>         return pos;
>       }
> 
>  I've verified that etags after this change still produces the correct
>  TAGS file, including for the file univ.m you sent up-thread.
> 
>  Do you agree with the changes I propose?  If not, could you please
>  explain what I miss here?
> 
> OK, this is another way of achieving an equivalent result. Please leave me until tomorrow to perform more
> tests so that I can formally confirm that this is fine.

Thanks.

I also plan on adding a few lines from univ.m to accumulator.m,
because those few lines use a feature accumulator.m doesn't.  Is this
OK with you?