emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: Info mode misformats menu entries with refs in description


From: Tim Van Holder
Subject: Re: Info mode misformats menu entries with refs in description
Date: Sat, 26 Apr 2003 11:13:58 +0200

> Thanks for your report.  rms asked me to work on it.
> 
>     The bison manual for version 1.875 contains a menu entry 
> (Pure Calling)
>     that has a @pxref in its description.  While standalone 
> info handles
>     this just fine, it seems to cause the emacs Info reader to justify
>     the menu block as a paragraph, losing menu functionality.
> 
> Unfortunately I can't reproduce this in the released 21.3, in 
> either the
> bison manual or your standalone example.  When I go to the entry you
> refer to:
> 
> * Pure Calling::      How the calling convention differs
>                         in a pure parser (*note A Pure 
> (Reentrant) Parser: Pure Decl.).

For your reference, on my emacs I get this:

 The Lexical Analyzer Function `yylex'

 * Calling Convention    How `yyparse' calls `yylex'.  Token Values::
 * How `yylex' must return the semantic value of the token it has read.
 * Token Positions       How `yylex' must return the text position (line
 * number, etc.) of the token, if the actions want that.  Pure
 * Calling               How the calling convention differs in a pure
 | parser (see A
 * Pure (Reentrant) Parser  ).

(the line starting with | is really part of the previous line, I broke
it
to avoid having the mailer breaking it).
Removing the pxref makes the paragraph appear normal again.
As Kim suggested, setting Info-hide-note-references to 0 (no
reformatting)
also fixes it, making the line appear as you list above.


>     Note that standalone info does have a quirk related to such refs -
>     when they are selected, info will jump to the menu 
> entry's node, not
>     the node specified in the ref.
> 
> Since releasing Texinfo 4.5, I've made some changes that might have
> affected that.  In any case, with my current sources, the 
> behavior again
> seems correct to me.

Okidoki - I use emacs pretty much exclusively anyway; only noticed it
when comparing emacs' behaviour to that of info.






reply via email to

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