From: "Drew Adams" <drew.adams@oracle.com>
To: "'Chong Yidong'" <cyd@gnu.org>
Cc: 10663@debbugs.gnu.org
Subject: bug#10663: 24.0.93; (elisp) `Position Parse' belongs after `Parser State'
Date: Thu, 16 Feb 2012 08:33:02 -0800 [thread overview]
Message-ID: <EDC26F391A7C4200ADBC0BFD45112512@us.oracle.com> (raw)
In-Reply-To: <87fweanbwj.fsf@gnu.org>
> > The subject line says it all. To understand `Position
> > Parse' you should have read `Parser State' to know what
> > the parser state is all about.
>
> After re-reading the chapter, I disagree. The current order reads
> better. It provides the motivation for caring about the parser state
> first, then describes how the parser state is actually represented.
> Closing the bug.
1. On second thought, I think you are right. At that point, a reader need not
know any details about the parser state. Thanks for checking/re-reading.
2. But a reader might well wonder what the text here is talking about when it
mentions "parser state" without any description, however brief.
A forward cross reference here to the node that tells readers what "parser
state" is would help. (Too bad we can't simply make the words "parser state"
here be such a link.)
3. Another minor improvement to consider: be consistent about the "state"
terminology. This node uses both "parse state" (in the heading) and "parser
state". Presumably these terms refer to the same state.
FYI, the term "parse state" is used only once in this section of the book (in
this heading), and only once in another section: node `Syntactic Font Lock'.
Elsewhere, "parser state" seems to be the preferred term - including (a) as a
node name, (b) as an index entry, and (c) within double quotes as a defined
term.
prev parent reply other threads:[~2012-02-16 16:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 18:06 bug#10663: 24.0.93; (elisp) `Position Parse' belongs after `Parser State' Drew Adams
2012-02-16 13:30 ` Chong Yidong
2012-02-16 16:33 ` Drew Adams [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EDC26F391A7C4200ADBC0BFD45112512@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=10663@debbugs.gnu.org \
--cc=cyd@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.