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: Fwd: bug#47408: Etags support for Mercury [v0.4]
Date: Sat, 29 May 2021 11:01:01 +0300	[thread overview]
Message-ID: <838s3y6kaq.fsf@gnu.org> (raw)
In-Reply-To: <53162dfb-0715-3077-78d1-3a8340943f2f@gmail.com> (message from fabrice nicol on Sat, 15 May 2021 12:19:26 +0200)

[Please use Reply All to have the bug address on the CC list.]

> From: fabrice nicol <fabrnicol@gmail.com>
> Date: Sat, 15 May 2021 12:19:26 +0200
> 
> The confusion stems from an earlier discussion with a third party (I 
> forgot his name), who proposed to reuse '--no-defines' **and** 
> '--declarations' to replace Mercury-specific short options that I had 
> introduced. You followed this advice and so did I except for one detail 
> that I will outline below.
> 
> To make things clearer, I will rephrase the way I implemented this:
> 
> 1. There are **no longer** Mercury-specific short options -m/-M.
> 
> 2. As advised by this third party and your review comments, 
> '--declarations' is implemented in a Mercury-specific way (hence the - 
> correct - NEWS item about it, as well as a couple of sentences in the 
> man page, this is just what your review advised).
> 
> Using '--declarations', etags will tag not only Mercury language 
> declarations (strictly speaking) but also 'legacy declarations', i.e. 
> the old Prolog way (in actual terms, these are definitions in Mercury, 
> but there is unfortunately no '--definitions' etags options, so we must 
> do with what we have in store).

OK.  But the documentation patches you submitted seem to be somewhat
confusing: will Mercury declarations be tagged by default, or only
when --declarations is used?  This option isn't the default in etags,
so either the declarations are tagged by default (i.e. without using
this option) or only when --declarations is specified on the command
line.  You seem to say both, which I don't understand.

And I have several minor comments to the patch:

> +In Mercury, declarations start a line with "\|\fB:-\fP\|" and are tagged
> +by default.

Here, this is the confusing part about tagging Mercury declarations.

> ++++
> +** Etags support for the Mercury programming language (https://mercurylang.org).
> +** Etags command line option --declarations now has Mercury-specific behavior.
> +All Mercury declarations are tagged by default.
> +For compatibility with Prolog etags support, predicates and functions appearing
> +first in clauses will also be tagged if etags is run with '--declarations'.

And this as well.  It leaves me wondering what is the difference
between the results when using --declarations and not using it.

> --- /dev/null
> +++ b/lib-src/ChangeLog

We don't maintain ChangeLog files anymore in the repository, so what
you wanted to say there should be instead in the commit log message
(which you didn't include).  See CONTRIBUTE for more details about
formatting commit log messages.

> +      /* Disambiguate file names between Objc and Mercury */
> +      if (lang != NULL && strcmp(lang->name, "objc") == 0)
> +	test_objc_is_mercury(curfdp->infname, &lang);

Our C style conventions are to leave one space between the function's
name and the left parenthesis following it, as below:

   if (lang != NULL && strcmp (lang->name, "objc") == 0)
     test_objc_is_mercury (curfdp->infname, &lang);

Please make sure you use this style everywhere.

> diff --git a/test/manual/etags/merc-src/array.m b/test/manual/etags/merc-src/array.m
> new file mode 100644
> index 0000000000..0663c41087
> --- /dev/null
> +++ b/test/manual/etags/merc-src/array.m
> @@ -0,0 +1,3416 @@
> +%---------------------------------------------------------------------------%
> +% vim: ft=mercury ts=4 sw=4 et
> +%---------------------------------------------------------------------------%
> +% Copyright (C) 1993-1995, 1997-2012 The University of Melbourne.
> +% Copyright (C) 2013-2018 The Mercury team.
> +% This file is distributed under the terms specified in COPYING.LIB.

Adding test file(s) for Mercury is great, but we cannot have there
files under arbitrary license/copyright.  If COPYING.LIB mentioned
above specifies GPL or a compatible license, then it's okay for us to
distribute this file, but we need a copy of that COPYING.LIB file as
well.  If the license is not compatible with GPL, we cannot distribute
this file; in that case, please find some other test file, or provide
your own.

Thanks.





  parent reply	other threads:[~2021-05-29  8:01 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 [this message]
     [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
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=838s3y6kaq.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).