* Johann Gunnar Oskarsson <johann@xxxxxxxxxxxxxx> writes:
> Steve asked me what I have against info (in 25 words or less).
> I'm not sure I can keep to the 25 word limit, we'll see.
That's OK, I'll let you off this once. :-)
> Info is ugly.
I agree. But it is infinitely better than having to fire up some
bloated fucking web browser just to read plain text.
> It just seems ... evil to me, to actually make an info reader that
> works around the crud in the generated info files, when it's possible
> to generate better looking html (which'll be easier to render and so
> on and so forth).
Oh God! HTbloodyML for docs? As a customisable alternative option,
sure no problem. As the default, no fucking way!
> Info does not adapt well to variable width screens. This is mostly
> the reason why I want something that's more dynamically rendered.
OK, but surely the SXEmacs info parser/reader/whatever could easily be
made to handle this?
> I do know that info *can* include pictures, and it *is* possible to
> use ascii art when pictures can't be shown, but I truly feel this can
> be done better.
Yes! SXEmacs can display pictures, so info files under SXEmacs should
display pictures too.
> When it comes to the dir files .... it annoys me a lot that I can't
> choose between 2 different versions of installed info files, I'll
> always be reading the one that's first in the info path, no matter
> where it's added to the actual "dir".
C-u C-h i /path/to/the/file_you_really_want RET
> It is very hard to include some markup like underline, italics, bold
> and so on, into info, without possible clashes with characters like *,
> _ and so on (at least, not that I'm aware of).
It is just as hard to do these things no matter what you are using to
do the rendering on the types of terminals that info was originally
designed for.
But I agree, if the terminal can handle it, info should display it.
> Please note that I like to write docs, and I want some control of the
> layout, both on graphical and text displays, and I'm not getting that
> control with info.
You are not getting _enough_ control.
> In other words, I'd like something like <strong> and <em> in on-line
> docs.
Have we switched from discussing Texinfo manuals to lisp source doc
strings now? If we are, eval this in scratch...
(defvar test-var nil
"this is `emphasised' in the doc string.")
then do C-h a test-var RET, then RET on the var name in the Hyper
Apropos buffer, look at the doc string.
I know that this is a _very_ cruddy way of doing it and it doesn't
work if your just do C-h v, but what I am getting at is that
emphasising text in lisp source doc strings is almost there already.
> There are gazillion ways to handle footnotes on-screen, and I want to
> be able to choose between all of them.
Yes. A good customisation.
> The rest of the world has moved to html or other xmls for on-line
> docs, why do we stay in the dark ages? Becouse of rmsism?
No. Because the rest of the world is stupid. The best way to render
plain text is with plain text. If our docs and manuals are in HTML
only, or even primarily in HTML, sooner or later (and I'm betting a
lot sooner than later) we'll get complaints from people saying they
can't read our docs in their latest-flavour-of-the-month web browser.
Now, please understand this, I _do not_ have any problems with us
distributing HTML docs. I _do_ have a problem with distributing _only_
HTML docs, or even making HTML docs the primary medium.
> Preferably, I'd like the same kind of control of doc strings, and
> render them excacly the same way.
I'd like to be able to have a little more control with doc strings
too, but probably no where near as much as you. :-)
> And last, but not least, I want something that is easily translated
> with fallbacks to default language or something.
Ah, so you want Texinfo. Cool.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| In space, |
| No one can hear you rip a stinky |
|------------------------------------<steve@xxxxxxxxxxx>---|
pgpHLPgutCzq4.pgp
Description: PGP signature
|