From: fabrice nicol <fabrnicol@gmail.com>
To: 47408@debbugs.gnu.org
Subject: bug#47408: Etags support for Mercury [v0.3]
Date: Sun, 28 Mar 2021 17:49:20 +0200 [thread overview]
Message-ID: <97f573da-ec63-7362-13c2-ca28a6634480@gmail.com> (raw)
In-Reply-To: <834kgvo220.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 6495 bytes --]
Thanks for this review.
Changes will be implemented soon as indicated.
(1) There is just one point that I would like to discuss before changing
things around: the proposed -m/-M short option issue.
I left this couple of options in (following Francesco Potorti only for
long options --declarations/--no-defines), for two reasons:
1. The ambiguity between Objective C and Mercury
Both languages having the same file extension .m, it was necessary to
add in a heuristic test function, in the absence of explicit language
identification input from command line.
Yet all heuristics may fail in rare cases. Tests show a fairly low
failure rate on the Mercury compiler source code. Less than 0.5 % of .m
files are not identified as Mercury files by the test (this should have
been documented somewhere). File concerned by test failure are some
Mercury test files and documentary test files with only (or almost only)
comments and blank lines.
While this could be improved by tweaking the heuristic test, it would
make it more complex, bug-prone and ultimately hard to maintain.
So -m/-M are useful to deal with these rare files, as they do not rely
on the heuristic test function at all but on their own semantics, which
explicitly identifies Mercury.
The only alternative I see is to explicitly warn users about adding '-l
mercury' to command line when using long options (in etags.1 and
possibly other docs).
Whether this is less intrusive (or more) than -m/-M is not crystal-clear
to me. Both solutions look on a par wrt this criterion, but -m/-M may
be more user-friendly.
If two short options are one too many, I propose redesigning the short
option pair as just one -m option with a binary argument (like: '-m
defines / -m all', or -m 0 / -m 1).
2. The social side of things
As indicated previously, I also consulted the Mercury review list, and
the feedback was positive on -m/-M (see below):
> 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.
>
So I opted for a compromise: renaming long options, following F.
Potorti, and keeping -m/-M, following Z. Somogyi.
(2) Your following question:
> diff --git a/lisp/speedbar.el b/lisp/speedbar.el
> index 12e57b1108..63f3cd6ca1 100644
> --- a/lisp/speedbar.el
> +++ b/lisp/speedbar.el
> @@ -3534,6 +3534,8 @@ speedbar-fetch-etags-parse-list
> speedbar-parse-c-or-c++tag)
> ("^\\.emacs$\\|.\\(el\\|l\\|lsp\\)\\'" .
> "def[^i]+\\s-+\\(\\(\\w\\|[-_]\\)+\\)\\s-*\C-?")
> + ("^\\.m$\\'" .
> + "\\(^:-\\)?\\s-*\\(\\(pred\\|func\\|type\\|instance\\|typeclass\\)+\\s+\\([a-z]+[a-zA-Z0-9_]*\\)+\\)\\s-*(?^?")
> ; ("\\.\\([fF]\\|for\\|FOR\\|77\\|90\\)\\'" .
> ; speedbar-parse-fortran77-tag)
> ("\\.tex\\'" . speedbar-parse-tex-string)
What about ObjC here? or are these keywords good for ObjC as well?
has the following reply: Objective C .m files are not parsed by
speedbar.el in current repository code, so the added feature does not
break anything. Issues will only arise if/when Emacs maintainers for
Objective C support decide on adding this file format to the speedbar
parser. It would be premature (and out-of-place) for me to settle this
on my own. Should this move happen, the heuristics used in etags.c
(function test_objc_is_mercury) could then be ported to elisp code.
>> +.TP
>> +.B \-M, \-\-no\-defines
>> +For the Mercury programming language, tag both declarations and
>> +definitions. Declarations start a line with \fI:\-\fP optionally followed by a
>> +quantifier over a variable (\fIsome [T]\fP or \fIall [T]\fP), then by
>> +a builtin operator like \fIpred\fP or \fIfunc\fP.
>> +Definitions are first rules of clauses, as in Prolog.
>> +Implies \-\-language=mercury.
>> +.TP
>> +.B \-m, \-\-declarations
>> +For the Mercury programming language, tag declarations as with \fB\-M\fP, but do not
>> +tag definitions. Implies \-\-language=mercury.
> This is not what Francesco Potortì suggested to do. He suggested that
> you use the existing options --no-defines and --declarations, but give
> them Mercury-specific meanings when processing Mercury source files.
> IOW, let's not introduce the new -m and -M shorthands for these options,
> and let's describe the Mercury-specific meaning of the existing
> options where they are currently described in etags.1. OK?
> +** Etags support for the Mercury programming language (https://mercurylang.org).
> +** New etags command line options '-M/-m' or --declarations/--no-defines'.
> +Tags all Mercury declarations. For compatibility with Prolog etags support,
> +predicates and functions appearing first in clauses will be tagged if etags is
> +run with the option '-M' or '--declarations'. If run with '-m' or
> +'--no-defines', declarations will be tagged but definitions will not.
> +Both options imply --language=mercury.
> This should be amended for the changes in the options I described
> above.
> As mentioned, let's not introduce -m and -M.
>
>> + case 'M':
>> + with_mercury_definitions = true; FALLTHROUGH;
>> + case 'm':
>> + {
>> + language lang =
>> + { "mercury", Mercury_help, Mercury_functions, Mercury_suffixes };
>> +
>> + argbuffer[current_arg].lang = ⟨
>> + argbuffer[current_arg].arg_type = at_language;
>> + }
>> + break;
> Shouldn't be needed anymore.
>
>> diff --git a/lisp/speedbar.el b/lisp/speedbar.el
>> index 12e57b1108..63f3cd6ca1 100644
>> --- a/lisp/speedbar.el
>> +++ b/lisp/speedbar.el
>> @@ -3534,6 +3534,8 @@ speedbar-fetch-etags-parse-list
>> speedbar-parse-c-or-c++tag)
>> ("^\\.emacs$\\|.\\(el\\|l\\|lsp\\)\\'" .
>> "def[^i]+\\s-+\\(\\(\\w\\|[-_]\\)+\\)\\s-*\C-?")
>> + ("^\\.m$\\'" .
>> + "\\(^:-\\)?\\s-*\\(\\(pred\\|func\\|type\\|instance\\|typeclass\\)+\\s+\\([a-z]+[a-zA-Z0-9_]*\\)+\\)\\s-*(?^?")
>> ; ("\\.\\([fF]\\|for\\|FOR\\|77\\|90\\)\\'" .
>> ; speedbar-parse-fortran77-tag)
>> ("\\.tex\\'" . speedbar-parse-tex-string)
> What about ObjC here? or are these keywords good for ObjC as well?
>
> Last, but not least: if you can, please provide a test file for the
> etags test suite, see test/manual/etags/.
>
> Thanks again for working on this.
[-- Attachment #2: Type: text/html, Size: 9323 bytes --]
next prev parent reply other threads:[~2021-03-28 15:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <25b8baef-11f2-7079-69d8-3207a24658fc@gmail.com>
2021-03-26 7:09 ` bug#47408: Emacs etags support for Mercury [v0.2] fabrice nicol
2021-03-27 10:51 ` bug#47408: Etags support for Mercury [v0.3] fabrice nicol
2021-03-28 13:11 ` Eli Zaretskii
2021-03-28 15:49 ` fabrice nicol [this message]
2021-03-28 16:22 ` Eli Zaretskii
2021-03-29 11:53 ` bug#47408: Etags support for Mercury [v0.4] fabrice nicol
[not found] ` <70503251-f8ea-9006-b7e7-b13b93bb71de@gmail.com>
2021-05-15 8:31 ` bug#47408: Fwd: " Eli Zaretskii
[not found] ` <53162dfb-0715-3077-78d1-3a8340943f2f@gmail.com>
2021-05-29 8:01 ` Eli Zaretskii
[not found] ` <CANTSrJtDMu=4SWUcBRt51X8n42mOfB6_sFi8mNoZ0YgYdtE-DA@mail.gmail.com>
2021-05-29 10:22 ` Eli Zaretskii
2021-06-01 2:38 ` bug#47408: Etags support for Mercury [v0.5] fabrice nicol
2021-06-06 9:48 ` Eli Zaretskii
2021-06-06 13:34 ` fabrice nicol
2021-06-06 18:18 ` Francesco Potortì
2021-06-06 20:49 ` fabrice nicol
2021-06-06 21:04 ` Francesco Potortì
2021-06-07 12:13 ` Eli Zaretskii
2021-06-08 0:38 ` Fabrice Nicol
2021-06-08 10:53 ` Francesco Potortì
2021-06-08 11:47 ` Eli Zaretskii
2021-06-08 12:47 ` Francesco Potortì
2021-06-10 13:59 ` Eli Zaretskii
2021-06-10 16:52 ` fabrice nicol
2021-06-10 17:05 ` Francesco Potortì
2021-06-10 17:20 ` Eli Zaretskii
2021-06-10 19:15 ` Eli Zaretskii
2021-06-10 20:39 ` bug#47408: Etags support for Mercury -- fix explicit tags for existentially-quantified procedures fabrice nicol
2021-06-11 5:56 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97f573da-ec63-7362-13c2-ca28a6634480@gmail.com \
--to=fabrnicol@gmail.com \
--cc=47408@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).