[m-rev.] Emacs etags support for Mercury

[fabrice nicol]

Hi,

After a two-month test phase, I'm considering formal submission of 
'etags' support to the Emacs development team, who have agreed on 
examining the proposal.

Before moving on with a patch submission to the Emacs team I would 
appreciate if the Mercury core team gave me some feedback (at least on 
the overall design).

In particular, on whether:

1. you find it useful to maintain a degree of backward compatibility 
with Emacs 'etags' support for Prolog.

In this Prolog support behavior, first occurrences of predicates and 
functions in the implementation are tagged irrespective of arity and 
types. Although imperfect, I find this tagging method useful at times, 
notably (but not only) for Prolog code porting into Mercury.

2. or you find it better to only tag Mercury declarations (whether in 
the interface or in the implementation).


Currently I'm proposing both ways: 'etags -m'  is behavior (2), while 
'etags -M' would support (1) *and* (2).

Attached is the git-format patch to a recent Emacs source code commit 
and below is a copy of recent feedback from the Emacs devel list.

I hope this proposal, if accepted, will be useful to Emacs users having 
a go at Mercury.

Best,

Fabrice Nicol

# ------------------------------- #

Message-Id: <E1lOzjX-00GjV8-Hj at tucano.isti.cnr.it>

>You will note an unconventional move. I was daring enough to add two 
>options to 'etags' (-m and -M) to implement some kind of backward 
>compatibility with Prolog etags support (based on tagging definitions, 
>-M) while allowing a simpler, more idiomatic approach that focuses on 
>tagging  Mercury declarations only (-m).  Backward compatibility is 
>legitimate and quite useful, but having it on board all the time may be 
>cumbersome for some use cases.  Hence the 'behavioral' options I added.

I fear this is too intrusive, but easy to amend.

Instead of -M, you should use --declarations

Instead of -m, you should use --no-defines

In both cases, the description of the options should be augmented with
their Mercury use.

-------------------------

In-Reply-To: <b9e2c35c-ba8f-5114-031f-36f580ae994e at gmail.com>
Content-Type: multipart/mixed;
  boundary="------------7AF01A37602B0D491A3765DF"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------7AF01A37602B0D491A3765DF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

As a follow-up to my message of March 22, I would appreciate to get some
feedback on the attached patch implementing Mercury support for 'etags'
before considering a formal submission.

You will note an unconventional move.  I was daring enough to add two
options to 'etags' (-m and -M) to implement some kind of backward
compatibility with Prolog etags support (based on tagging definitions,
-M) while allowing a simpler, more idiomatic approach that focuses on
tagging  Mercury declarations only (-m).  Backward compatibility is
legitimate and quite useful, but having it on board all the time may be
cumbersome for some use cases.  Hence the 'behavioral' options I added.

Fabrice Nicol

------------------------

Date: Mon, 22 Mar 2021 19:23:33 +0200
Message-Id: <83y2ef9k6i.fsf at gnu.org>
From: Eli Zaretskii <eliz at gnu.org>
Cc: emacs-devel at gnu.org
In-Reply-To: <b9e2c35c-ba8f-5114-031f-36f580ae994e at gmail.com> (message from
	fabrice nicol on Mon, 22 Mar 2021 03:02:03 +0100)
Subject: Re: etags support for the Mercury programming language
References: <b9e2c35c-ba8f-5114-031f-36f580ae994e at gmail.com>

> Date: Mon, 22 Mar 2021 03:02:03 +0100
> 
> I have been developing Emacs etags support for the Mercury 
> logic/functional programming language (https://mercurylang.org/), based 
> on the current code for Prolog support.
> 
> Before proposing a patch for review, I would like to know if 
> (considering the limited audience) such a proposal stands a chance of 
> being accepted. All the changes are located in lib-src/etags.c (plus two 
> lines in lisp/speedbar.el).

Yes, I think support for additional languages in etags is always
welcome.  But please also be sure to update the etags.1 man page with
the relevant information, and announce the addition in NEWS.

If the changes are substantial, we will need you to assign the
copyright for these changes to the FSF.  Would you like to start the
legal paperwork rolling now?  If so, I will send you the form to fill.

Thanks.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Applied-Changes-for-Mercury-Fabrice-Nicol.patch
Type: text/x-patch
Size: 17286 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20210324/8a9bf30b/attachment-0001.bin>