Hi Eli,
>> 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?

Mercury-specific declarations will be tagged by default.

What is confusing is not the implementation but the fact that, after it 
was decided **not** to use language-specific options (like the initially 
proposed -m/-M), we were left with no choice as to which existing option 
could be used to implement the optional "Prolog legacy/porting" 
behavior. --declarations was the option that the first third-party 
reviewer proposed, and both of us followed suit. It is to be understood 
as "**all** declarations", meaning Mercury-specific declarations **and** 
Prolog-support-style declarations (i.e. first rule predicates in clauses).

I've tried to make the documentation patch a bit clearer.

> This option isn't the default in etags,
> so either the declarations are tagged by default (i.e. without using
> this option)

Yes. Mercury-specific declarations are tagged by default, this is what I 
explained in my latest two emails.

> or only when --declarations is specified on the command
> line.

No. --declarations adds Prolog-style 'declarations' in addition to 
Mercury-specific declarations, so that porting Prolog to Mercury is 
facilitated. It is always necessary to tag Mercury-specific 
(non-Prolog-style) declarations, in all circumstances. It is only useful 
to tag Prolog-style declarations (actually definitions) in some 
circumstances.

> You seem to say both, which I don't understand.

Mercury-specific declarations are tagged by default **and** with 
--declarations. This is what the Mercury community wants, I consulted 
them on the user list.

Prolog-style 'declarations' (which are actually definitions, as there 
are **no** declarations in Prolog) are additionaly tagged when 
--declarations is used.

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

This will not be confusing to people who have practiced Mercury even a 
little bit. A Mercury-specific declaration is by definition preceded by 
':-'.

I changed this to '... and are always tagged'. Which may be clearer.

>> ++++
>> +** 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.

By default, when --declarations is not used, all Mercury-specific 
declarations (i.e. beginning a line with ':-' ) are tagged, **and only 
them**.

When --declarations is used, all Mercury-specific declarations **plus** 
all Prolog-support-style 'declarations' are tagged.

I see no confusing phrasing in the proposed sentences. I changed 'also' 
into 'in addition', which is (perhaps) clearer.

>> --- /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.

Ah, I thought commit log messages were yours to make as I am not granted 
committing rights.

>> +      /* 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.

Done.

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

OK.

Upon closer inspection, the COPYING.LIB license that applies to library 
files is a kind of dual license with an optional way out of GPL v2 into 
LGPL-like licensing terms.

Admittedly this is a bit complex and uncertain.

However these complex licensing terms only apply to library files. 
Compiler files, on the contrary, are casher GPLv2. So I removed my 
example file (array.m from the library) and replaced it with a compiler 
file (accumulator.m). This now leaves no uncertainty whatsoever. The 
COPYING file referred to in the accumulator.m header is GPL v2.

I hope this works,

Fabrice