bug#47408: Etags support for Mercury -- fix explicit tags for existentially-quantified procedures

[fabrice nicol]

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