[m-rev.] Emacs etags support for Mercury
fabrnicol at gmail.com
Thu Mar 25 02:16:51 AEDT 2021
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.
# ------------------------------- #
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>
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=utf-8; format=flowed
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 17286 bytes
Desc: not available
More information about the reviews