bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: incorrect yychar for unambiguous GLR


From: Joel E. Denny
Subject: Re: incorrect yychar for unambiguous GLR
Date: Wed, 11 Jan 2006 11:48:22 -0500 (EST)

On Tue, 10 Jan 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> > 3. I tend to follow the usual LaTeX and HTML coding style: one line break 
> > after a sentence, two line breaks after a paragraph.  This makes editing 
> > much easier for me: it's easier to reorder sentences, and it's easier to 
> > fix line-wrapping after editing. I did this in the text I edited in this 
> > patch, but this isn't the current style.  Why?
> 
> Most likely, it's because Emacs does it that way when you type Escape-q.

I use vim.  It has gqap, which I believe is the same as Emacs' Escape-q.  
However, this doesn't work when there are adjacent lines that shouldn't be 
wrapped (@c, @vindex, etc).  gqas usually manages to wrap just one 
sentence.  If it doesn't manage, it's easy enough to handle one sentence 
manually.  But I'm off topic....

> > Either way, the resulting ".info" file looks fine.
> 
> Yes.  It's no big deal either way.

Great.

> > +This raises caveats for several bison features you might use in a semantic
> 
> bison -> Bison

OK

> > +Variable containing the look-ahead token.
> > +When there is no look-ahead token, the value @code{YYEMPTY} is stored in 
> > the
> > +variable.
> > +When the look-ahead is the end of the input stream, the value @code{YYEOF} 
> > is
> > +stored in the variable.
> 
> Some wordsmithing is needed here.  Perhaps change to:
> 
> Variable containing either the look-ahead token, or @code{YYEOF} when
> the look-ahead is the end of the input stream, or @code{YYEMPTY} when
> no look-ahead has been performed so the next token is not yet known.

Sounds fine.

Thanks.

Joel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]