GNU bug report logs - #47408
Emacs etags support for Mercury [v0.2]

Previous Next

Full log

Message #84 received at 47408 <at> debbugs.gnu.org (full text, mbox):

From: fabrice nicol <fabrnicol <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pot <at> gnu.org, 47408 <at> debbugs.gnu.org
Subject: bug#47408: Etags support for Mercury -- fix explicit tags for
 existentially-quantified procedures
Date: Thu, 10 Jun 2021 22:39:29 +0200

Hi Eli,
>> your latest fix for Mercury 'etags' support has introduced a regression
>> for existentially quantified predicates.
> Is it a "regression" in the sense that "M-." no longer finds the
> definitions?

Exactly. M-.  no longer finds the definition for 
existentially-quantified predicates (or functions), so this is a 
regression strictly speaking.

Prior code did not abide by pfnote input constraints, but it "just 
worked" in all cases, at least for 'etags' invocation.

>> These predicates have the following (somewhat simplified) syntax (in
>> extended regexp  form, \s for white space):
>>
>> :-[:blank:]+some[:blank:]*\[[:blank:]*T(,[:blank:]*[:upper:]{1})*[:blank:]*\][:blank:]+pred[:blank:]+([:lower:]+([:alnum:]|[:punct:])*)+[:blank:]*\([^()]+\)([:blank:]|[:lower:])*\.
>>
>> Example:
>>
>> :- some [T] pred unravel_univ(univ::in, T::out) is det.
>>
>> Your fix incorrectly outputs such quantified predicates. For example on
>> tagging univ.m (attached), your commit version yields:
>>
>>
>> :- some [T] pred unravel_univ(^?[T] pred unravel_univ^A141,4333
>>
>>
>> whilst my original code yields the correct tag:
>>
>>
>> :- some [T] pred unravel_univ(^?141,4333
> Why do you think the current result is incorrect, while the previous
> result was correct?

The previous code issued TAGS file that were correctly parsed by 'etags' 
and so M-. / M-, "just worked" in all cases.

The new code introduces such chunks as "[T] pred " at the beginning of 
explicit tags, which looks wrong and is likely to be the reason why 
these explicit tags are not parsed, hence useless.

>
> The original code was incorrect, so it doesn't sound right to me to
> revert to it.  I will work on fixing the cases you described (unless
> you beat me to it).
>
> Thanks for turning my attention to this issue.

I will not be able to spare enough free time to implement explicit tag 
parsing for existential predicates before a couple of weeks, so in the 
meantime, it would be safer to revert to original code and just 
flag/blame it as 'to-be-fixed for ctags by FN.'

As I explained in prior mail, this is anyway a use case in which 'ctags' 
is not useful at all, whilst 'etags' is.

Fabrice

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.