Alper Ersoy <dirt@gtk.org> writes:
[...]
> Oliver Scholz:
>> Most notably the markup could be syntactical rather than specifying
>> the colours to use. I *hate* it, if a document tells me the best
>> colour for me to read a certain syntactic element. Let the document
>> specify the syntactical element and let me customize the colour.
>
> Ok.  If we lean towards a syntactical markup, it should _also_ specify
> the best colour, typeface, etc. too.  We must do this, otherwise
> whenever there's a new command in Texinfo, readers will be unaware of
> how to handle it.  Something like (notation aside):
>
>   ^H^[var bi^H^]Variable^H^[/var^H^]
>
> So it's bold-italic.  But you (info reader) know it's a var, so you
> can use whatever style you want.  Sometime in the future, when we have
> this @funky command:
>
>   ^H^[funky sb,red^H^]Art Vandelay^H^[/funky^H^]
>
> You don't know what a funky text is, but you can use the style
> provided there.

You have a point here. If the format would be HTML, it would also be
possible to address that, by using <h1>, <b>, <i> etc. with the class
attribute extensivly. The class attribute would specify the
syntactical information, the raw element name would specify the
fallback.

> However, I suggested ANSI escapes in the first place because of the
> star characters around strong text.  One can use @strong only, and
> still get a flowing text in display environments supporting bold
> typeface.  Not with Info though.
>
> Introducing syntactical markup elements is IMHO burning your blanket
> because of one flea.
>
> The only way to justify changes this level is to also identify the
> other problems in Info, and to address them all at once, then declare
> it as Info2.  After all, we are breaking compatibility here, so it
> _must_ have to offer more.

I don't know the "other problems".  I have to admit that I am just an
end user as far as info is concerned.  I even hardly ever use
texinfo.  I'd like to see nicer syntactical fontification,
proportional fonts for paragraph text etc. in the Emacs info reader.
To get this properly would require changes to the info format.

If this is towards HTML with a heavy use of the `class' attribute,
then--I believe--it could provide everything necessary for future
improvement.

Well, since everybody seemed to agree that modifying the standalone
info reader would be the hard part, I decided to give it a try and
hacked a bit on it. I append both a patch to nodes.c in texinfo-4.6
and the file sample3x.info (in html) which I used for testing.

Unfortunately I am probably the person least apt for this task, being
unfamiliar with C, unfamiliar with the info source code, unfamiliar
with the info format, unfamiliar with texinfo and, finally, unfamiliar
with HTML. In fact this is the first larger chunk of C code that I
ever wrote. (My thanks go to the people on the IRC channel #emacs for
their help, BTW.)

I did it in the most primitive way I could think of: it acts like a
filter to convert HTML-info files to the current info format on the
fly when reading the file contents. Obviously it is far from being
complete (I didn't try even). It is rather proof-of-concept code. But
if this approach is not absolutely insane, and if my C code is
somewhere near of what a real C programmer could accept, then it could
serve as a starting point, because I did it in a way that should be
easily extensible.

It should be simple enough to add ANSI colour sequences for certain
tags.