Re: Spell checking of the commentary section by checkdoc.el.

[Stefan Monnier]

> My preference for a Wiki-style markup is based on the assumption that
> only a small subset of Texinfo is needed here and that designing the
> markup and implementing the code to convert it is straightforward. I
> may be wrong with either of these two assumptions, of course, but I
> don't see it yet. As for the benefit of having the "Info:" section
> look like plain ascii: well, your mileage varies, obviously. :-)

The question to me is not whether "the full Texinfo" is needed
but whether it hurts and I think the only way it can hurt is if
it makes the text more difficult to write/read/maintain, so clearly
the crux of the matter is the variation in mileage.

> Just to make sure: are we really talking about the same thing here?
> What I have in mind is to generate the info manual on the fly: extract
> the "Info:" section from the el-file, convert it to the format which
> the info reader takes as input and display it in info-mode. I presume
> that it would be significantly faster to do this with a simple markup
> that supports only a subset of Texinfo. But I have no experience here,
> so I may be much mistaken.

That would be one use (basically a `finder-commentary' on steroids).
Another would be to generate actual info files and make them
available in info for browsing:

   C-h i m locally installed emacs packages RET m rmime RET
or
   C-h i m emacs RET m other bundled packages RET m smerge RET

[ Note I assume that the info version of the manual would include those
  things even though they wouldn't be included in the printed version. ]

Another would be for HTML versions of the docs, such as on the
home page of the author where he distributes the package.

Being able to print it (nicely) is also a plus.
All in all, I'd want to go through Texinfo even if we designed a
special purpose super-lightweight markup.

The potentially positive thing about a new markup is that we might be
able to get good quality Texinfo output from a very lightweight markup
because we get to look at the attached code to see what is what.
But that'll require more work.


        Stefan