Hi, Eli,

I could finalize my tests against the entire Mercury library code.

All is OK. I applied your patch on top of mine.

Also, I added two new corner-case fixes, which are mentioned in the 
commit message:

1. The first new fix is for 0-arity predicates and functions. Yes, 
Mercury has them. (They play the role of global immutable constants in 
other languages).

They happened not to be caught by the previous code, now they are.

2. I also removed module names from within tag names. The point is that 
module name prefixing is optional in most cases, so if you leave the 
module prefix within the tag, you will fail to get to the declaration 
when striking M-. on a (non-prefixed) predicate name. It is better to 
remove the name altogether. This will automatically trigger an explicit tag.

Fabrice

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