[m-rev.] Emacs etags support for Mercury
zoltan.somogyi at runbox.com
Thu Mar 25 02:38:35 AEDT 2021
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.
More information about the reviews