bug#10663: 24.0.93; (elisp) `Position Parse' belongs after `Parser State'

bug#10663: 24.0.93; (elisp) `Position Parse' belongs after `Parser State'

[Drew Adams]

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.

In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-01-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
 -LD:/devel/emacs/libs/gnutls-3.0.9/lib'
 

bug#10663: 24.0.93; (elisp) `Position Parse' belongs after `Parser State'

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

bug#10663: 24.0.93; (elisp) `Position Parse' belongs after `Parser State'

[Drew Adams]

> > 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.