[m-rev.] Emacs etags support for Mercury

[Zoltan Somogyi]

On Wed, 24 Mar 2021 16:16:51 +0100, fabrice nicol <fabrnicol at gmail.com> wrote:
> 1. you find it useful to maintain a degree of backward compatibility 
> with Emacs 'etags' support for Prolog.

I haven't used Prolog in years, possibly decades, so for me,
Prolog compatibility is irrelevant. Also, I am a vim user who has
tried Emacs only once, and bounced off it very hard. So take what
follows with more than a grain of salt.

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

I see why this behavior may be useful in Prolog, since (standard) Prolog
has no declarations for a tag to jump to. I have no experience with
this behavior, since when I *did* program in Prolog, there was as yet
no tags support for Prolog, and my programs were small enough that
none was really needed.

However, in the languages I *do* use tags files with, C and Mercury,
it is *always* the declaration that I want to jump to. The first occurrence
may be a call or other non-defining occurrence, and this would
just about never be what I am looking for when I use the tag.

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

Yes, I much prefer this behavior.

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

Accommodating different people's different preferences is a good idea
if it can be done at acceptable cost.

> Instead of -M, you should use --declarations
> 
> Instead of -m, you should use --no-defines

There is no need for "instead"; you can support both forms of both options.

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

Examples do help users, but there is also virtue in keeping help messages
short, so they should be chosen for maximum info density.

Zoltan.