From: Eli Zaretskii <eliz@gnu.org>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: yantar92@posteo.net, emacs-devel@gnu.org
Subject: Re: [PATCH] Re: Make peg.el a built-in library?
Date: Sun, 27 Nov 2022 10:57:51 +0200 [thread overview]
Message-ID: <831qporcz4.fsf@gnu.org> (raw)
In-Reply-To: <878rjxkw4j.fsf@ericabrahamsen.net> (message from Eric Abrahamsen on Sat, 26 Nov 2022 17:46:04 -0800)
> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: emacs-devel@gnu.org
> Date: Sat, 26 Nov 2022 17:46:04 -0800
>
> Here's a new version, that I hope clarifies these questions (instead of
> doing the opposite).
Thanks, a few minor comments below.
> Lastly, nobody with a maintainer's hat on has actually given the green
> light on this, and I assume we'll want to hold off until the next
> version of Emacs is released; anyway it would be good to know what
> Eli/Lars think. I haven't done any NEWS additions or anything, either.
What exactly are you asking about here?
> @c -*-texinfo-*-
> @c This is part of the GNU Emacs Lisp Reference Manual.
This would mean a suitable change to elisp.texi at the least, and probably
also to another file that is part of the ELisp reference manual sources?
> A @acronym{PEG} parser is defined as a list of named rules, each of
> which match text patterns, and/or contain references to other rules.
^^^^^ ^^^^^^^
"matches" and "contains", in singular.
> Parsing is initiated with the function @code{peg-run} or the macro
> @code{peg-parse}, and parses text after point in the current buffer,
> using a given set of rules.
This function and this macro need to be formally documented with @defun and
@defmac, as we do elsewhere in the ELisp reference.
> The definition of each rule is referred to as a @dfn{parsing
> expression} (@acronym{PEX}), and can consist of a literal string, a
Ideally, each @dfn in the manual should have a @cindex entry, because people
are likely to look up these terms.
> Or set as the value of a variable, and the variable used in a
> combination of calls to @code{with-peg-rules} and @code{peg-run},
> where the ``entry-point'' rule is given explicitly:
This sentence reads awkwardly, because it starts with "Or set". Suggest to
rephrase:
Alternatively, use a variable whose value is a grammar, and use it in a
combination of calls to...
> @example
> (defvar number-grammar
> '((number sign digit (* digit))
> (sign (or "+" "-" ""))
> (digit [0-9])))
Btw, this begs a question: how come the value of the variable is a (quoted)
list, but the value you pass to peg-parse in the previous example was not
quoted?
> By default, calls to @code{peg-run} or @code{peg-parse} produce no
> output: parsing simply moves point. In order to return or otherwise
> act upon parsed strings, rules can include @dfn{actions}, see
> @xref{Parsing Actions} for more information.
Again, a @cindex for "actions" is in order here.
Also, @xref produces a Capitalized "See", so you want a @ref here, not
@xref. And please always follow the closing brace of a cross-reference with
a period or a comma, because some versions of Texinfo insist on that. (The
only exception from this rule is @pxref inside parentheses.)
> Individual rules can also be defined using a more @code{defun}-like
> syntax, using the macro @code{define-peg-rule}:
>
> @example
> (define-peg-rule digit ()
> [0-9])
> @end example
define-peg-rule should be documented with a @defmac.
> @node PEX Definitions
> @section PEX Definitions
There should be a @menu in the parent @chapter's node for all the child
@section nodes. Otherwise, makeinfo will barf.
> @item "abc"
> A literal string.
You don't mean "abc" literally here, do you? The correct way of expressing
"a string" is
@item @var{string}
> @item (char C)
> A single character, as an Elisp character literal.
Likewise here:
@item @var{C}
A single character @var{C}, as a Lisp character literal.
> @item (* E)
> Zero or more of an expression, as the regexp ``*''. Matching is
> always ``greedy''.
Likewise. Basically, all the elements here are meta-syntactic variables:
they stand for something else. The right markup for them is @var.
Also, "zero or more of an expression" reads awkwardly. I don't even think I
understand what you mean.
And please quote regexps using @samp, not literal quotes (here and
elsewhere).
> @item (+ E)
> One or more of an expression, as the regexp ``+''. Matching is always
> ``greedy''.
Likewise about "one or more of an expression".
> @item (opt E)
> Zero or one of an expression, as the regexp ``?''.
Same.
> @item (range A B)
> The character range between A and B, as the regexp ``[A-B]''.
It is better to use CH1 and CH2 instead of A and B.
> @item [a-b "+*" ?x]
> A character set, including ranges, literal characters, or strings of
> characters.
Same comment about a and b.
> @vindex peg-char-classes
> Named character classes include the following:
Instead of listing them, just use a cross-reference to the node where
classes are documented as part of regexp syntax.
> The first action pushes the initial value of point to the stack. The
> intervening @acronym{PEX} moves point over the next word. The second
^^
Two spaces there.
> action pops the previous value from the stack (binding it to the
> variable @code{start}), and uses that value to extract a substring
> from the buffer and push it to the stack. This pattern is so common
> that peg.el provides a shorthand function that does exactly the above,
^^^^^^
@file{peg.el}. Or maybe just @acronym{PEG}.
> @item (substring E)
> Match @acronym{PEX} E and push the matched string to the stack.
Same comments here regarding @var markup of meta-syntactic variables.
> @item (replace E "repl")
> Match E and replaced the matched region with the string "repl".
"repl" is not a literal string, it's a meta-syntactic variable, just like E.
Finally, this needs a lot of index entries to make it a useful reference
that is easily looked up for stuff.
Thanks.
next prev parent reply other threads:[~2022-11-27 8:57 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-25 18:52 Make peg.el a built-in library? Eric Abrahamsen
2021-08-26 6:17 ` Eli Zaretskii
2021-08-26 15:34 ` Eric Abrahamsen
2021-09-09 4:36 ` Eric Abrahamsen
2021-09-19 15:25 ` Eric Abrahamsen
2021-09-30 19:44 ` Stefan Monnier
2021-09-30 20:34 ` Adam Porter
2021-10-01 8:14 ` Augusto Stoffel
2021-10-01 18:05 ` Stefan Monnier
2021-10-01 18:40 ` Eric Abrahamsen
2021-10-02 3:57 ` Stefan Monnier
2021-10-02 7:32 ` Adam Porter
2021-10-02 14:45 ` Stefan Monnier
2021-10-02 15:13 ` Adam Porter
2021-08-26 17:02 ` Adam Porter
2021-08-26 17:25 ` Eric Abrahamsen
2021-08-27 3:17 ` Eric Abrahamsen
2021-08-27 6:41 ` Helmut Eller
2021-08-27 16:57 ` Eric Abrahamsen
2021-09-26 10:59 ` Augusto Stoffel
2021-09-26 15:06 ` Eric Abrahamsen
2021-09-26 18:36 ` Augusto Stoffel
2021-09-27 16:18 ` Eric Abrahamsen
2021-09-27 22:34 ` Richard Stallman
2021-09-28 3:52 ` Eric Abrahamsen
2021-09-28 8:09 ` tomas
2021-09-28 9:32 ` Helmut Eller
2021-09-28 10:45 ` tomas
2021-09-28 15:24 ` Augusto Stoffel
2021-09-30 6:04 ` Richard Stallman
2021-10-01 3:27 ` Eric Abrahamsen
2021-10-09 1:31 ` Michael Heerdegen
2021-10-09 5:28 ` Michael Heerdegen
2021-10-09 8:12 ` Helmut Eller
2021-10-09 12:52 ` Stefan Monnier
2021-10-10 5:49 ` Helmut Eller
2021-10-14 10:25 ` Michael Heerdegen
2021-10-09 12:54 ` Stefan Monnier
2021-10-09 16:47 ` Eric Abrahamsen
2021-10-10 4:20 ` Michael Heerdegen
2021-10-10 21:40 ` Eric Abrahamsen
2021-10-13 2:58 ` Michael Heerdegen
2021-10-09 16:49 ` Eric Abrahamsen
2021-10-10 3:43 ` Stefan Monnier
2021-10-10 4:46 ` Michael Heerdegen
2021-10-10 5:58 ` Helmut Eller
2021-10-10 13:56 ` Stefan Monnier
2021-10-22 16:33 ` Michael Heerdegen
2021-10-31 23:43 ` Michael Heerdegen
2021-11-15 23:16 ` Michael Heerdegen
2022-11-07 3:33 ` Ihor Radchenko
2022-11-07 19:46 ` Eric Abrahamsen
2022-11-08 6:57 ` Helmut Eller
2022-11-08 8:51 ` Ihor Radchenko
2022-11-10 4:04 ` Richard Stallman
2022-11-10 5:25 ` tomas
2022-11-10 8:15 ` Eli Zaretskii
2022-11-10 8:29 ` tomas
2022-11-11 4:36 ` Richard Stallman
2022-11-08 8:47 ` Ihor Radchenko
2022-11-08 16:18 ` Eric Abrahamsen
2022-11-08 19:08 ` tomas
2022-11-08 19:42 ` Eric Abrahamsen
2022-11-16 4:27 ` [PATCH] " Eric Abrahamsen
2022-11-16 5:07 ` tomas
2022-11-16 5:39 ` Eric Abrahamsen
2022-11-16 15:53 ` tomas
2022-11-16 6:24 ` Ihor Radchenko
2022-11-16 18:15 ` Eric Abrahamsen
2022-11-17 12:21 ` Ihor Radchenko
2022-11-27 1:46 ` Eric Abrahamsen
2022-11-27 8:57 ` Eli Zaretskii [this message]
2022-11-28 1:09 ` Eric Abrahamsen
2022-11-28 12:16 ` Eli Zaretskii
2023-09-25 1:30 ` Eric Abrahamsen
2023-09-25 2:27 ` Adam Porter
2023-09-25 13:00 ` Alexander Adolf
2024-03-24 14:19 ` Ihor Radchenko
2024-03-24 15:32 ` Eli Zaretskii
2024-03-25 1:45 ` Eric Abrahamsen
2023-01-11 7:39 ` Michael Heerdegen
2023-01-11 8:04 ` Ihor Radchenko
2023-01-11 11:01 ` Michael Heerdegen
2023-01-11 11:32 ` tomas
2023-02-05 12:10 ` Ihor Radchenko
2023-02-05 15:41 ` Eduardo Ochs
2023-02-05 15:45 ` Ihor Radchenko
2023-02-05 16:19 ` Eduardo Ochs
2023-02-05 16:50 ` Ihor Radchenko
2023-02-09 5:44 ` Jean Louis
2023-02-06 0:33 ` Michael Heerdegen
2022-11-08 14:01 ` Stefan Monnier
2022-11-08 14:42 ` tomas
2022-11-08 15:08 ` Visuwesh
2022-11-08 16:29 ` Juanma Barranquero
2022-12-02 20:20 ` Augusto Stoffel
2022-11-08 16:10 ` Eric Abrahamsen
2022-11-08 18:59 ` tomas
2022-11-08 19:42 ` Eric Abrahamsen
2022-11-08 22:03 ` Tim Cross
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=831qporcz4.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=eric@ericabrahamsen.net \
--cc=yantar92@posteo.net \
/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).