GNU bug report logs - #10663
24.0.93; (elisp) `Position Parse' belongs after `Parser State'

Previous Next

Full log

Message #13 received at 10663 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 10663 <at> debbugs.gnu.org
Subject: RE: bug#10663: 24.0.93;
	(elisp) `Position Parse' belongs after `Parser State'
Date: Thu, 16 Feb 2012 08:33:02 -0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.