resend: [PATCH] ignoring Info extensions

resend: [PATCH] ignoring Info extensions

[Jan Nieuwenhuizen]

Let's try this one again.

From: Jan Nieuwenhuizen <janneke@gnu.org>
Subject: [PATCH] ignoring Info extensions
To: karl@freefriends.org (Karl Berry)
cc: emacs-devel@gnu.org
Date: Thu, 26 Feb 2004 12:12:36 +0100
Message-ID: <87ptc2rt5n.fsf@peder.flower>

Karl Berry writes:

>     We may want to skip some whitespace around the
>     cookie...
>
> I think [..] we do want to skip a newline after a cookie.

> I think it would be good to post the code to the list and ask "someone"
> to make sure it gets into the RC branch (somehow).

Done, patch below.

Greetings,
Jan.

Index: lisp/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/ChangeLog,v
retrieving revision 1.5713
diff -p -u -r1.5713 ChangeLog
--- lisp/ChangeLog	25 Feb 2004 00:07:33 -0000	1.5713
+++ lisp/ChangeLog	26 Feb 2004 01:38:24 -0000
@@ -1,3 +1,8 @@
+2004-02-25  Jan Nieuwenhuizen  <janneke@gnu.org>
+
+	* info.el (Info-hide-cookies-node): New function.
+	(Info-select-node): Use it.
+
 2004-02-24  Vinicius Jose Latorre  <viniciusjl@ig.com.br>
 
 	* ebnf-abn.el: New file, implements an ABNF parser.
Index: lisp/info.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/info.el,v
retrieving revision 1.376
diff -p -u -r1.376 info.el
--- lisp/info.el	29 Dec 2003 19:18:53 -0000	1.376
+++ lisp/info.el	26 Feb 2004 01:38:35 -0000
@@ -1139,6 +1139,23 @@ any double quotes or backslashes must be
 	       start (point) `(display ,image rear-nonsticky (display)))))))
     (set-buffer-modified-p nil)))
 
+;; Texinfo 4.7 will add cookies of the form ^@^H[NAME CONTENTS ^@^H].
+;; Hide any construct of the general form ^@[^@-^_][ ...  ^@[^@-^_]],
+;; including one optional trailing newline.
+(defun Info-hide-cookies-node ()
+  "Hide unrecognised cookies in current node."
+  (save-excursion
+    (let ((inhibit-read-only t)
+	  (case-fold-search t))
+      (goto-char (point-min))
+      (while (re-search-forward
+	      "\\(\0[\0-\37][[][^\0]*\0[\0-\37][]]\n?\\)"
+	      nil t)
+	(let* ((start (match-beginning 1)))
+	  (if (not (get-text-property start 'invisible))
+	      (put-text-property start (point) 'invisible t)))))
+    (set-buffer-modified-p nil)))
+
 (defun Info-select-node ()
   "Select the info node that point is in."
   ;; Bind this in case the user sets it to nil.
@@ -1175,6 +1192,7 @@ any double quotes or backslashes must be
 	(if Info-enable-active-nodes (eval active-expression))
 	(Info-fontify-node)
 	(Info-display-images-node)
+	(Info-hide-cookies-node)
 	(run-hooks 'Info-selection-hook)))))
 
 (defun Info-set-mode-line ()

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: resend: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Thu, 11 Mar 2004 20:47:57 +0100
> 
> > I think it would be good to post the code to the list and ask "someone"
> > to make sure it gets into the RC branch (somehow).
> 
> Done, patch below.

Thanks!

> +;; Texinfo 4.7 will add cookies of the form ^@^H[NAME CONTENTS ^@^H].

Please use present or past tense here.  For one thing, Texinfo 4.7
is already in pretest.  For another, a year from now that "will add"
will we wrong.

Re: resend: [PATCH] ignoring Info extensions

[Jan Nieuwenhuizen]

Eli Zaretskii writes:

> Thanks!
>
>> +;; Texinfo 4.7 will add cookies of the form ^@^H[NAME CONTENTS ^@^H].
>
> Please use present or past tense here.

Yes, you are right.  I never made that mistake again.  There's another
thing, in the Info-display-images-node, there is still:

	  (message "Found image: %S" image-file)

which is more a debugging thing.  I think it should be removed.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [PATCH] ignoring Info extensions

[Jan Nieuwenhuizen]

>> +;; Texinfo 4.7 will add cookies of the form ^@^H[NAME CONTENTS ^@^H].
>
> Please use present or past tense here.

Done.  I haven't seen this in CVS yet, so I'm sending a new version.

The new patch below also removes the debugging message with the image
file name, which is quite annoying when reading the new (LilyPond)
info pages with images.

Greetings,
Jan.



Index: lisp/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/ChangeLog,v
retrieving revision 1.5823
diff -p -u -r1.5823 ChangeLog
--- lisp/ChangeLog	29 Mar 2004 03:51:41 -0000	1.5823
+++ lisp/ChangeLog	29 Mar 2004 07:50:52 -0000
@@ -1,3 +1,13 @@
+2004-03-29  Jan Nieuwenhuizen  <janneke@gnu.org>
+
+	* info.el (Info-display-images-node): Remove message with image
+	file name.
+
+2004-02-25  Jan Nieuwenhuizen  <janneke@gnu.org>
+
+	* info.el (Info-hide-cookies-node): New function.
+	(Info-select-node): Use it.
+
 2004-03-29  Kenichi Handa  <handa@m17n.org>
 
 	* international/mule-util.el (char-displayable-p): Fix generation
Index: lisp/info.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/info.el,v
retrieving revision 1.378
diff -p -u -r1.378 info.el
--- lisp/info.el	22 Mar 2004 17:12:16 -0000	1.378
+++ lisp/info.el	29 Mar 2004 07:50:53 -0000
@@ -1134,12 +1134,28 @@ any double quotes or backslashes must be
 	       (image (if (file-exists-p image-file)
 			  (create-image image-file)
 			"[broken image]")))
-	  (message "Found image: %S" image-file)
 	  (if (not (get-text-property start 'display))
 	      (add-text-properties
 	       start (point) `(display ,image rear-nonsticky (display)))))))
     (set-buffer-modified-p nil)))
 
+;; Texinfo 4.7 adds cookies of the form ^@^H[NAME CONTENTS ^@^H].
+;; Hide any construct of the general form ^@[^@-^_][ ...  ^@[^@-^_]],
+;; including one optional trailing newline.
+(defun Info-hide-cookies-node ()
+  "Hide unrecognised cookies in current node."
+  (save-excursion
+    (let ((inhibit-read-only t)
+	  (case-fold-search t))
+      (goto-char (point-min))
+      (while (re-search-forward
+	      "\\(\0[\0-\37][[][^\0]*\0[\0-\37][]]\n?\\)"
+	      nil t)
+	(let* ((start (match-beginning 1)))
+	  (if (not (get-text-property start 'invisible))
+	      (put-text-property start (point) 'invisible t)))))
+    (set-buffer-modified-p nil)))
+
 (defun Info-select-node ()
   "Select the info node that point is in."
   ;; Bind this in case the user sets it to nil.
@@ -1176,6 +1192,7 @@ any double quotes or backslashes must be
 	(if Info-enable-active-nodes (eval active-expression))
 	(Info-fontify-node)
 	(Info-display-images-node)
+	(Info-hide-cookies-node)
 	(run-hooks 'Info-selection-hook)))))
 
 (defun Info-set-mode-line ()

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

Jan Nieuwenhuizen <janneke@gnu.org> writes:
>>> +;; Texinfo 4.7 will add cookies of the form ^@^H[NAME CONTENTS ^@^H].
>>
>> Please use present or past tense here.
>
> Done.  I haven't seen this in CVS yet, so I'm sending a new version.

I tested it: it works well and could be installed.

> The new patch below also removes the debugging message with the image
> file name, which is quite annoying when reading the new (LilyPond)
> info pages with images.

BTW, I noticed that lilypond.info has Info nodes with trailing
whitespace in their names (in older LilyPond versions there
were several such nodes, and in the latest there are still two
such nodes).  This causes some problems for the Emacs Info reader.
Perhaps you may correct them in the LilyPond, but I have a general
question: is trailing whitespace allowed in Info node names
officially by Texinfo documentation and by `makeinfo'? If it is so,
then we should take additional care for them in the info.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Karl Berry]

    question: is trailing whitespace allowed in Info node names

No.  It "should" not occur.

    officially by Texinfo documentation and by `makeinfo'? 

By coincidence, there was a recent bug report pointing that TeX barfed
on node names with trailing whitespace, while makeinfo accepted them.  I
will change makeinfo to make this an error, or at least a warning, and
remove such trailing whitespace so it doesn't get into the output.

I can't find anything in the documentation that says explicitly one way
or the other.  I'll change that.

Thanks,
k

Re: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> Date: Wed, 31 Mar 2004 21:01:33 -0500
> From: karl@freefriends.org (Karl Berry)
> 
> By coincidence, there was a recent bug report pointing that TeX barfed
> on node names with trailing whitespace, while makeinfo accepted them.  I
> will change makeinfo to make this an error, or at least a warning

I'd suggest to make it a warning, not an error.  My reasoning is that
something that makeinfo supported since day one shouldn't suddenly
become a fatal error that causes the output to be removed.

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

karl@freefriends.org (Karl Berry) writes:
> I will change makeinfo to make this an error, or at least a warning,
> and remove such trailing whitespace so it doesn't get into the output.

I think a warning is ok.  But moreover, I noticed other places
in Info manuals that cause problems for Info readers:

By funny coincidence, the LilyPond music glossary contains words
`*note*' emphasized by asterisks around them, where the word `note'
means a symbol for a musical tone.  But it is interpreted by the Info
reader as an Info reference, and if Info-hide-note-references=t it is
displayed as `See *'.  Even though the Texinfo manual warns about
using asterisks with the word `note', it suggests to replace it
by a phrase such as *Please notice* which is inappropriate here.
Perhaps makeinfo should produce a warning about it, but still
I don't see how the author would fix this problem.

There are many other Info manuals that have a string `*Note:'
which is treated incorrectly by Info readers.  What do you think
about interpreting a `*Note' as an Info reference only if it
has whitespace around it, i.e. if it matches the following regexp?

[ \t\n]+\*[Nn]ote[ \t\n]+

It would also solve the problem of incorrect interpreting of
the quoted ``*Note:'' string such as in the following Info nodes:

(info "(info)Cross-refs")
(info "(info-stnd)Parts of an Xref")
(info "(texinfo)Cross Reference Commands")

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Thu, 01 Apr 2004 19:33:15 +0300
> 
> There are many other Info manuals that have a string `*Note:'
> which is treated incorrectly by Info readers.

What manuals are those?

> What do you think
> about interpreting a `*Note' as an Info reference only if it
> has whitespace around it, i.e. if it matches the following regexp?
> 
> [ \t\n]+\*[Nn]ote[ \t\n]+

I don't think it is wise for us to make changes in the de-facto format
of Info files.  The current format clearly doesn't require any
whitespace, so you are suggesting an incompatible change.

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> From: Juri Linkov <juri@jurta.org>
>> Date: Thu, 01 Apr 2004 19:33:15 +0300
>> 
>> There are many other Info manuals that have a string `*Note:'
>> which is treated incorrectly by Info readers.
>
> What manuals are those?

I just ran on Debian GNU/Linux (the biggest Info base I was able to find):

find /usr/share/info -type f -exec zgrep -iH "\*Note[^ \t]" {} \;

and it reported 116 matches: 6 in cvs, 22 in gawk, 11 in gcc, 16 in gtk,
20 in libc, and many other files.  And _none_ of them is an Info reference.

>> What do you think
>> about interpreting a `*Note' as an Info reference only if it
>> has whitespace around it, i.e. if it matches the following regexp?
>> 
>> [ \t\n]+\*[Nn]ote[ \t\n]+
>
> I don't think it is wise for us to make changes in the de-facto format
> of Info files.  The current format clearly doesn't require any
> whitespace, so you are suggesting an incompatible change.

I am not aware of any Info files with references without whitespace
after `*Note'.  Perhaps somewhere such files may exist that was
generated by a program other than makeinfo, or was hand-written?

OTOH, while the change in Info readers will make such possible
references unavailable for navigation, it will fix the problem
in known Info files.  For example, look at the node
(info "(gtk)GtkNotebook") in the latest GTK version.
With Info-hide-note-references=t it is so distorted that
it is almost unreadable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 02 Apr 2004 06:27:11 +0300
> 
> I am not aware of any Info files with references without whitespace
> after `*Note'.  Perhaps somewhere such files may exist that was
> generated by a program other than makeinfo, or was hand-written?

I don't know; I just hate incompatible changes.

How about if we instead detect the "*Note:*" case and don't treat it
as a reference?  (Also the "_Note:_" case, I think.)

Re: [PATCH] ignoring Info extensions

[Richard Stallman]

    I am not aware of any Info files with references without whitespace
    after `*Note'.  Perhaps somewhere such files may exist that was
    generated by a program other than makeinfo, or was hand-written?

Isn't it the case that Texinfo will always produce whitespace
after *Note when it is a cross reference?  I don't think we need
to worry very much about hand-made Info files which might fail
to have whitespace there.

Re: [PATCH] ignoring Info extensions

[Karl Berry]

    Perhaps makeinfo should produce a warning about it, but still

It does now (in the current sources, in some circumstances).

    [ \t\n]+\*[Nn]ote[ \t\n]+

There are many cases where the preceding character is not whitespace,
such as (@pxref{foo}) -> (*note foo::).  So that part of the proposed
regexp won't work.

However, I cannot find or think of any case where the *following*
character will not be whitespace.  Looking at makeinfo/xref.c and
texinfmt.el, it looks to me like when *[nN]ote is output, it is always
followed by a space.  So it seems this would be a good improvement!

I don't think anything else generates Info files, and even if it does,
it seems highly unlikely it would output anything else.

Eli, can you think of a way
  \*[Nn]ote[ \t\n]+
could fail?  I also looked in all the dozens of info files installed on
my system, and could not find any problematic cases.

As Juri says, there are tons of places where "*Note*" is output for
various reasons.  It would be nice if it just worked, this has been a
longstanding nagging problem.

Thanks,
k

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

karl@freefriends.org (Karl Berry) writes:
> There are many cases where the preceding character is not whitespace,
> such as (@pxref{foo}) -> (*note foo::).  So that part of the proposed
> regexp won't work.

You are right.  Actually, what I wanted to refer to is the code in the
`Info-fontify-node' function with the commentary telling that skipping
a quoted reference is a hack.  I think `*Note' quoted with a preceding
` or " character should not be considered as a valid reference, so that
the final regexp for a reference would be the following (case-insensitive):

[^"`]\*Note[ \t\n]+

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Karl Berry]

    juri> I think `*Note' quoted with a preceding
    ` or " character should not be considered as a valid reference

I guess I can't think of a reason to write something like `@ref{foo}' or
"@ref{foo}", and I don't see any cases in reality, so this might be ok,
but neither am I clear as to why it is necessary.  What does
fontification have to do with quote chars?  (Sorry, I could not quickly
make sense of the code.)  Could you explain a little?

    juri> I am not aware of any Info files with references without
    whitespace after `*Note'.  Perhaps somewhere such files may exist
    that was generated by a program other than makeinfo, or was
    hand-written?

I agree, the space is always there.  I very much doubt there are
handwritten Info files, or ones generated by something other than
makeinfo/texinfmt.el, that do something different.  I think it is a safe
change.  But keep reading.

    eliz> How about if we instead detect the "*Note:*" case and don't
    treat it as a reference?  

I believe this amounts to *Note:[^*] (vs. *Note:\s).  I think either one
is ok, it won't make any difference in practice.  I slightly tend toward
the latter, because it is clearer to understand "*Note: is always
followed by whitespace" rather than "*Note: is followed by anything
except a *" (which, in practice, is always whitespace).

However, if you really think it is an issue, we can go with the former.

    eliz> (Also the "_Note:_" case, I think.)

I don't think that one is problematic.  No *.

Thanks,
k

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

karl@freefriends.org (Karl Berry) writes:
>     juri> I think `*Note' quoted with a preceding
>     ` or " character should not be considered as a valid reference
>
> I guess I can't think of a reason to write something like `@ref{foo}' or
> "@ref{foo}", and I don't see any cases in reality, so this might be ok,
> but neither am I clear as to why it is necessary.  What does
> fontification have to do with quote chars?  (Sorry, I could not quickly
> make sense of the code.)  Could you explain a little?

There are three cases with quoted `*Note' I was able to find:

./info.info:like a menu item except that it has `*note' instead of `*'.  It
./info-stnd.info:with `*Note', and continue with a label and a target.
./texinfo-1:     or an Info cross-reference saying `*Note NAME: NODE.'.

Currently they are fontified incorrectly: the text between them and
the next reference in the same Info node with them is very distorted.

However, the first two cases will be fixed when the reference regexp
will be changed to \*Note[ \t\n]+ because they have no whitespace
after *Note.  And the third case (in texinfo-1), even though it has
whitespace after *Note, is not a problem at all, because it's just
an example.  Moreover, by coincidence, it refers to the node named
`NODE', and the Texinfo manual has a node with the same name,
so this reference is not broken!

Currently the function `Info-fontify-node' has the code to skip the
reference if the preceding character is ".  The commentary says that
it's a "hack".  I haven't seen Info references with a leading ".
Could someone tell is this code really needed.  Otherwise, it could be
removed.

>     eliz> How about if we instead detect the "*Note:*" case and don't
>     treat it as a reference?  
>
> I believe this amounts to *Note:[^*] (vs. *Note:\s).  I think either one
> is ok, it won't make any difference in practice.  I slightly tend toward
> the latter, because it is clearer to understand "*Note: is always
> followed by whitespace" rather than "*Note: is followed by anything
> except a *" (which, in practice, is always whitespace).

I guess you actually meant *Note[^:*] vs. *Note\s.  Anyway,
restricting the character after *Note to [:*] instead of
whitespace apparently will not solve the problem for all
known references.  Here is the distribution of \*Note[^ \t]+
matches on the biggest Info base I found:

     78 *Note:*
      8 *NOTEBOOK,
      6 *Note:
      4 *NOTE:*
      4 *NOTE*
      3 *Note*:
      2 *note:*
      2 *NOTEBOOK)
      2 *NOTE*:
      1 *note*
      1 *Notes:*
      1 *Note2:
      1 *note'
      1 *Note',

So perhaps whitespace is a better choice.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 02 Apr 2004 21:19:17 +0300
> 
> >     eliz> How about if we instead detect the "*Note:*" case and don't
> >     treat it as a reference?  
> >
> > I believe this amounts to *Note:[^*] (vs. *Note:\s).  I think either one
> > is ok, it won't make any difference in practice.  I slightly tend toward
> > the latter, because it is clearer to understand "*Note: is always
> > followed by whitespace" rather than "*Note: is followed by anything
> > except a *" (which, in practice, is always whitespace).
> 
> I guess you actually meant *Note[^:*] vs. *Note\s.  Anyway,
> restricting the character after *Note to [:*] instead of
> whitespace apparently will not solve the problem for all
> known references.  Here is the distribution of \*Note[^ \t]+
> matches on the biggest Info base I found:
> 
>      78 *Note:*
>       8 *NOTEBOOK,
>       6 *Note:
>       4 *NOTE:*
>       4 *NOTE*
>       3 *Note*:
>       2 *note:*
>       2 *NOTEBOOK)
>       2 *NOTE*:
>       1 *note*
>       1 *Notes:*
>       1 *Note2:
>       1 *note'
>       1 *Note',
> 
> So perhaps whitespace is a better choice.

But if we use *Note[^:*], we remain compatible to whatever Info files
are out there that don't have a whitespace after "*Note:", right?
Isn't that better to solve a problem without breaking what previously
worked?

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> From: Juri Linkov <juri@jurta.org>
>> So perhaps whitespace is a better choice.
>
> But if we use *Note[^:*], we remain compatible to whatever Info files
> are out there that don't have a whitespace after "*Note:", right?
> Isn't that better to solve a problem without breaking what previously
> worked?

Actually, [^:*] is as incompatible as whitespace.  There may exist
some imaginable Info files with non-standard references with : or *
after `*Note' as a separator between `*Note' and node name.
So [^:*] is not better than whitespace.  However, whitespace is better
for Info files generated by makeinfo.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Karl Berry]

    juri> I guess you actually meant *Note[^:*] vs. *Note\s.  Anyway,

Yes, sorry.

    eliz> But if we use *Note[^:*], 

That won't fix all of the cases Juri found:
>       8 *NOTEBOOK,
>       1 *Notes:*
>       1 *Note2:
>       1 *note'

These would still be misidentified as references.  So according to these
findings, it would have to be *Note[^:*Bs2'], and obviously some day
there will be some other character.  Let's fix it for real, right now,
by saying *Note is followed by whitespace.

    we remain compatible to whatever Info files
    are out there that don't have a whitespace after "*Note:", right?

But there aren't any, I feel more sure than ever.  Every Info writer
writes "*Note " for references.  So let's reflect that in the Info readers.
I see no problem here.

    Isn't that better to solve a problem without breaking what previously
    worked?

As a general rule, I of course agree with you.  As you know, I am a bear
for compatibility, and we have tried our utmost never to break old Info
readers with new Info files.  I think the last time we did was with
@anchor, umpteen years ago.

However, in this particular case, it seems to me that the proposed
change (a) would not break old Info files that would break, and (b) it
fixes the original problem, of references being misidentified, for good
(as well as we can, anyway), whereas the alternative does not.

Therefore, I believe that
  \*[Nn]ote[ \t\n]
is preferable to
  \*[Nnote][^anything]

Let's do it.  I will change the Info reader.

Thanks,
k

Re: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> Date: Fri, 2 Apr 2004 09:16:34 -0500
> From: karl@freefriends.org (Karl Berry)
> 
>     eliz> (Also the "_Note:_" case, I think.)
> 
> I don't think that one is problematic.  No *.

Right.  Sorry for the line noise.

Re: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> Date: Thu, 1 Apr 2004 20:50:01 -0500
> From: karl@freefriends.org (Karl Berry)
> 
> Eli, can you think of a way
>   \*[Nn]ote[ \t\n]+
> could fail?

That one could work; I was mainly concerned by the preceding blank.

> As Juri says, there are tons of places where "*Note*" is output for
> various reasons.  It would be nice if it just worked

What if we make this case to silently fail, instead of making an
incompatible change?

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

There are other problems in Info manuals:

1. If an Info node contains two menus, then the first menu item after
the second `* Menu:' is hidden.  And both standalone and Emacs Info
readers add an item `Menu' to the menu completion list (invoked by
`m').  An example of such node is (info "(gnus)Marking Articles").
Are two menus allowed in one node, or should we fix Info readers?

2. If a menu has an empty item (a single `*' on the whole line)
then the previous menu item is displayed in Info-title-1-face.
An example of such menu is the START-INFO-DIR-ENTRY of coreutils.info.
Perhaps a line should be displayed in Info-title-1-face only
if the following line has two or more `*'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Karl Berry]

    Are two menus allowed in one node, or should we fix Info readers?

One menu.  I changed texinfo.txi at some point to say this:

  A menu must be located at the end of a node, without any regular text
  or additional commands between the @code{@@end menu} and the beginning
  of the next node.  (As a consequence, there may be at most one menu in
  a node.)

At some point I'll add a warning to makeinfo when this condition isn't
met.

    2. If a menu has an empty item (a single `*' on the whole line)

This also seems invalid to me.  There's no provision for "empty" menu
items.

    then the previous menu item is displayed in Info-title-1-face.
    An example of such menu is the START-INFO-DIR-ENTRY of coreutils.info.

I don't see it.  I'm looking at coreutils 5.2.1.

    Perhaps a line should be displayed in Info-title-1-face only
    if the following line has two or more `*'.

I don't understand?  Why would a line start with two *'s?

Re: [PATCH] ignoring Info extensions

[Juri Linkov]

>     2. If a menu has an empty item (a single `*' on the whole line)
>
> This also seems invalid to me.  There's no provision for "empty" menu
> items.
>
>     then the previous menu item is displayed in Info-title-1-face.
>     An example of such menu is the START-INFO-DIR-ENTRY of coreutils.info.
>
> I don't see it.  I'm looking at coreutils 5.2.1.

Yes, original package is ok.  A single `*' character is added
only in Debian.

>     Perhaps a line should be displayed in Info-title-1-face only
>     if the following line has two or more `*'.
>
> I don't understand?  Why would a line start with two *'s?

To underline Info titles, like this:

Title
*****

I assumed that there is no title shorter than two characters,
so only a sequence of two or more `*' characters could fontify
the previous line in Info-title-1-face.

But I think we have nothing to do here - Debian developers should fix 
menu lines with a single `*' character.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [PATCH] ignoring Info extensions

[Eli Zaretskii]

> Date: Fri, 2 Apr 2004 20:25:54 -0500
> From: karl@freefriends.org (Karl Berry)
> 
>     2. If a menu has an empty item (a single `*' on the whole line)
> 
> This also seems invalid to me.

Agreed.  Manuals who do that should be fixed.

Re: [PATCH] ignoring Info extensions

[Richard Stallman]

    1. If an Info node contains two menus, then the first menu item after
    the second `* Menu:' is hidden.

Could you explain what that means?

				     And both standalone and Emacs Info
    readers add an item `Menu' to the menu completion list (invoked by
    `m').

That would seem to be a bug.

	   An example of such node is (info "(gnus)Marking Articles").
    Are two menus allowed in one node, or should we fix Info readers?

A node can only have one menu, but a second `* Menu:' should just be
a no-op.