unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: fabrice nicol <fabrnicol@gmail.com>
Cc: 47408@debbugs.gnu.org
Subject: bug#47408: Etags support for Mercury [v0.5]
Date: Thu, 10 Jun 2021 20:20:45 +0300	[thread overview]
Message-ID: <83h7i5bpqq.fsf@gnu.org> (raw)
In-Reply-To: <d87c67eb-34f8-96fe-0c10-71cbbb303a34@gmail.com> (message from fabrice nicol on Thu, 10 Jun 2021 18:52:49 +0200)

> Cc: 47408@debbugs.gnu.org
> From: fabrice nicol <fabrnicol@gmail.com>
> Date: Thu, 10 Jun 2021 18:52:49 +0200
> 
> 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?

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

> In other words, 'pred unravel_univ' is wrongly repeated in your latest 
> commit.

It isn't "wrongly repeated".  TAGS files support 2 different ways of
specifying a tag: implicitly named or explicitly named.  The "repeated
name" form is the latter; it should be used whenever the NAME argument
passed to make_tag includes characters that etags.el doesn't expect to
find in an identifier; see the function notinname and the comments
before make_tag.

It should have been the job of mercury_pr to find the identifier
itself within the line whose pointer it accepts as S, and pass only
that to make_tag as NAME/NAMELEN arguments.  I made a step in that
direction, but it turns out I didn't go far enough.  Feel free to
propose improvements to the code I installed so as to identify the
name of the identifier and nothing else, as other callers of make_tag
do.

> The issue seems to be located at the patch line below:
> 
> 
> + char *name = skip_non_spaces (s + len0);

The only problem with the above line is that it assumes there's only
one non-space "word" before the identifier proper, whereas the example
you show makes it clear there could be more than one.  Which means the
code might need to repeatedly skip these non-identifier words until we
exhaust them all.  I will look into fixing that (but I really prefer
that you do it in my stead, as I don't know enough about the Mercury's
syntax).

But other than that, the changes I installed are IMO a step in the
right direction: your original code incorrectly passed to make_tag the
same arguments as both NAME and LINESTART, and passed zero as NAMELEN,
which was the immediate reason why ctags didn't output anything for
Mercury sources.  Please compare the way you called make_tag with how
the rest of the code calls that function.

> Pending a more accurate 'fix for the fix', it would probably be wiser to 
> revert to original code, as it - at least - gives a correct output for 
> 'etags' invocation.

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.





  parent reply	other threads:[~2021-06-10 17:20 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <25b8baef-11f2-7079-69d8-3207a24658fc@gmail.com>
2021-03-26  7:09 ` bug#47408: Emacs etags support for Mercury [v0.2] fabrice nicol
2021-03-27 10:51   ` bug#47408: Etags support for Mercury [v0.3] fabrice nicol
2021-03-28 13:11     ` Eli Zaretskii
2021-03-28 15:49       ` fabrice nicol
2021-03-28 16:22         ` Eli Zaretskii
2021-03-29 11:53           ` bug#47408: Etags support for Mercury [v0.4] fabrice nicol
     [not found]             ` <70503251-f8ea-9006-b7e7-b13b93bb71de@gmail.com>
2021-05-15  8:31               ` bug#47408: Fwd: " Eli Zaretskii
     [not found]                 ` <53162dfb-0715-3077-78d1-3a8340943f2f@gmail.com>
2021-05-29  8:01                   ` Eli Zaretskii
     [not found]                     ` <CANTSrJtDMu=4SWUcBRt51X8n42mOfB6_sFi8mNoZ0YgYdtE-DA@mail.gmail.com>
2021-05-29 10:22                       ` Eli Zaretskii
2021-06-01  2:38                     ` bug#47408: Etags support for Mercury [v0.5] fabrice nicol
2021-06-06  9:48                       ` Eli Zaretskii
2021-06-06 13:34                         ` fabrice nicol
2021-06-06 18:18                           ` Francesco Potortì
2021-06-06 20:49                             ` fabrice nicol
2021-06-06 21:04                               ` Francesco Potortì
2021-06-07 12:13                               ` Eli Zaretskii
2021-06-08  0:38                                 ` Fabrice Nicol
2021-06-08 10:53                                 ` Francesco Potortì
2021-06-08 11:47                                   ` Eli Zaretskii
2021-06-08 12:47                                     ` Francesco Potortì
2021-06-10 13:59                                       ` Eli Zaretskii
2021-06-10 16:52                                         ` fabrice nicol
2021-06-10 17:05                                           ` Francesco Potortì
2021-06-10 17:20                                           ` Eli Zaretskii [this message]
2021-06-10 19:15                                             ` Eli Zaretskii
2021-06-10 20:39                                             ` bug#47408: Etags support for Mercury -- fix explicit tags for existentially-quantified procedures fabrice nicol
2021-06-11  5:56                                               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h7i5bpqq.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=47408@debbugs.gnu.org \
    --cc=fabrnicol@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).