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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10663 in the body.
You can then email your comments to 10663 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.93; (elisp) `Position Parse' belongs after `Parser State'
Date: Mon, 30 Jan 2012 10:06:51 -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.

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'
 

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

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
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 21:30:36 +0800

"Drew Adams" <drew.adams <at> 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.

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.