[m-rev.] Emacs etags support for Mercury

[fabrice nicol]

Thanks for this kind reply, which overall confirms what I thought.

So I'll be proceeding with the Emacs feature list and prioritize 
behavior (2) over (1), in the event of optional behavior not being 
accepted by Emacs reviewers.

I use both Vim *and* Emacs so hopefully I'm neutral on the alternative. 
What I can say is that, once applied patches to 'etags', 'speedbar' and 
'metal-mercury-mode' (another user-contributed tool), programming in 
Mercury using Emacs turns out to be a fairly comfortable experience 
these days.

F.

Le 24/03/2021 à 16:38, Zoltan Somogyi a écrit :
>
> 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.