Re: Invisible colons in Emacs Info.

[Luc Teirlinck]

Karl Berry wrote:

       still recognize some of those old entries (as long as such tweaking does
       not impact valid cases).

   Of course that's fine and desirable.

   I guess that if there are no other colons or periods in the menu entry
   after the first :, it can be unambiguously parsed. (Not counting the ::
   form, of course.)  But if there are following colons or periods, then it
   seems the space is needed.

Which means that Stefan's recent changes do not reduce the importance
of making people aware that the rules have changed.  The example I
gave shows that it is easy for colons to appear in descriptions.  So
it is important that Stefan's partial and unreliable support for the
old syntax does not give people the misleading impression that the old
syntax is still reliably supported.  Any form of incomplete support
always carries the danger of misleading people into assuming full
support.

I guess that we could have makeinfo print warnings in case of subtopic
names that contain a colon or end in a colon without following
whitespace, pointing out that:

1.  Subtopic names containing colons, while supported by Emacs Info, are
    not currently supported by the stand-alone Info.

2.  Only a colon followed by a space (or tab), or two colons, still
    reliably terminate a subtopic name.  Other subtopic names are
    deprecated and may or may not still be recognized.

So 

* Mtools:(mtools).        Mtools: utilities to access DOS disks in Unix.

would consider:

Mtools:(mtools).        Mtools

to be the subtopic name and:

utilities to access DOS disks in Unix

to be the node name, but makeinfo would warn the user of that fact and
also of the fact that this syntax is not currently recognized by the
stand-alone Info.

On the other hand:

* Mtools: (mtools).        Mtools: utilities to access DOS disks in Unix.

would consider Mtools to be the subtopic name without warnings of any
kind (of course).

I believe that Emacs' current echo area behavior for `m' in this case
should be changed, as I pointed out before.

Sincerely,

Luc.