emacs-devel
[Top][All Lists]
Advanced

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

Re: Divergence in menu appearance between Emacs Info and standalone Info


From: David Kastrup
Subject: Re: Divergence in menu appearance between Emacs Info and standalone Info
Date: 06 Jun 2003 15:02:02 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

"Eli Zaretskii" <address@hidden> writes:

> > Date: Thu, 5 Jun 2003 19:56:40 -0400 (EDT)
> > From: "Robert J. Chassell" <address@hidden>
> > 
> > I fear the Web browser mindset, which is to accept an inefficient
> > and obsolete tool as if it were modern.
> 
> So let's make Info documents look and feel modern, like HTML does,
> without losing any of the wonderful features HTML lacks.
> 
> With that attitude in mind, I don't see how hiding node names could
> be a step in the wrong direction.  Granted, it should be possible to
> reveal the node names, but I don't think it means we should show
> them unconditionally as part of the displayed text.

Quite so.  The purpose of an info reader is _not_ just to provide a
syntax highlighted info source file, but to render the structure
expressed in it.

I'd make a much more radical proposal: image support.  At the current
point of time, images can only be placed within the printed manual,
and only in jpeg format.  Obviously, for things like screen shots and
so on, png would also be desirable, but the main point is that in an
Emacs buffer, only ASCII art renditions are allowed in info files.
While the ASCII rendition will of course be needed as a fallback in
the standalone terminal reader and on text consoles, there is no
reason to press the same restriction in Emacs buffers.  In particular
screen shots (perhaps optionally in thumbnail form) could help in a
lot in some explanatory texts.

More ambitious, for example, would be mechanisms for automatically
rendering equations and similar material as bitmaps, like
preview-latex does in LaTeX source buffers.  However, the latter might
possibly better be done "live", since one does not know in advance
what size and colors the screen of a user might have.  Alternatively,
one could generate a scalable format (like PostScript with Type1
fonts, or SVG).

Sorry for spinning out of control, but stuff like that could decrease
the advantages of a printout further and thus save trees.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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