Hi,As a follow-up to my previous threads on the Emacs devel list (see below), I am now submitting a revised patch that takes into account suggestions from two devel-list members (and adds in support for declarations with variable quantifiers over predicates and functions).
I also consulted members from the Mercury devel list (reviews-request@lists.mercurylang.org). Although they did not go into the 'etags' code, as they mostly use Vim, the overall design does seem to meet approval there.
The patch proposes adding two options to 'etags', namely -M/--declarations and -m/--no-defines. As explained in my prior threads, this is justified by the fact that Mercury is derived from Prolog. It is not unusual to have to port Prolog code into Mercury. Yet Emacs 'etags' Prolog support is quite different, as Prolog has no types or declarations, so predicates appearing first in clauses are tagged as a workaround in Prolog 'etags' support. Unlike Prolog, Mercury has declarations, which should be tagged in priority (this is the community consensus). But preserving some sort of backward compatibility with Prolog may be quite useful for porting purposes, notably. There is no clean way to achieve this without adding at least one extra option to 'etags' (with an argument), or two options without argument, which I personally find clearer.
Regarding tests, the following link to source code from the Mercury compiler has (almost) all the possible use cases:
https://raw.githubusercontent.com/Mercury-Language/mercury/master/library/array.m Thanks in advance for considering this submission. Fabrice Nicol Message-Id: <E1lOzjX-00GjV8-Hj@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@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@gnu.org> From: Eli Zaretskii <eliz@gnu.org> Cc: emacs-devel@gnu.org In-Reply-To: <b9e2c35c-ba8f-5114-031f-36f580ae994e@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@gmail.com>
Date: Mon, 22 Mar 2021 03:02:03 +0100I 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.
0001-Prepare-commit-for-submission-Mercury-etags-support.patch
Description: Text Data
--- End Message ---