Re: On being web-friendly and why info must die

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:
>> In org this would be:
>> 
>> * Abbrevs
>> 
>> A defined \abbrev\ is a word which \expands\, if you insert it into some
>> different text.
>> 
>> ** Abbrev Concepts
>> 
>> An \abbrev\ is a word that has been defined to \expand\ into a
>> specificed \expansion\.
>> 
>> 
>> Now, I agree that the loss of semantics from @dfn is not good. But org
>> (or markdown or asciidoc or latex) can work out the navigation from the
>> document structure.
>
> So does 'makeinfo', but I guess you are not aware of that.  I explain
> a little bit of that below, but there's more to Texinfo than meets the
> eye, so you are encouraged to study it in more detail, because IMO
> criticizing Texinfo without detailed knowledge of its features frankly
> doesn't feel right.

Indeed, you are correct, I have never used texinfo in anger and am not
an expert at it's use. I've used asciidoc extensively, and org-mode a
reasonable amount. It's just the way that it is -- you can't be an
expert at everything.


> What you wrote above in Org format defines a chapter and its
> subordinate section.  And that's the _only_ structure supported by the
> above paradigm: a tree, whereby the child nodes must immediately
> follow their parents, in the depth-first order.
>
> By contrast, Texinfo manuals do not have to have a tree structure.
> Their structure can be an arbitrary graph.  At least one popular Info
> manual (info.info) actually uses this feature: it doesn't present a
> tree-like structure, but instead has a cycle or two within it.

I guessed that this would be case, but wasn't sure whether it was used
or not. Actually, I even implemented a feature like this for Emacs Muse
several years ago, because I needed info like next/prev functionality.
The node information was stored in a data structure which could support
an arbitary graph.

In all the time that I had this capability, I never used it to represent
anything other than a tree. The problem is, of course, that users are
not going to expect this kind of behaviour: next/prev should move, well,
next and previous. In the end, I put a facade over the graph data
structure which only allowed trees.

So, I am not convinced this is much in the way of a feature, even if
info.info uses it.

> AFAIK, to do that in Org, you need to create a link; the outline-style
> document you show above won't cut it.  IOW, Org requires you in that
> case to insert links very similar to Texinfo menus.

Sure. Navigation menus happen automatically. Then there are hyperlinks,
and see also links.


> As with node pointers, the Emacs Texinfo mode commands can
> automatically create the menus as well, again on the assumption that
> the section nodes immediately following a chapter node are child nodes
> of that chapter, recursively.  Thus, in simple tree-like documents,
> generating these menus is a keystroke away.

And, in non-simple tree-like documents they are not. Which probably
means that the non-simple tree-like documents are rarely written.

> So, as you see, both Org and Texinfo solve the same problems, and they
> do that in similar, albeit different, ways.  I see no advantage to Org
> methods here, as long as you consider Texinfo together with its Emacs
> support.

I'm just struggling to think of another document format with explicit
menu navigation in the source. To me, it does not make sense to have a
source format within knowledge that could be infered out; it's more
error prone, but also less semantic. In so far as possible, I think,
navigation be a feature of the representation, not the source.


> On the contrary, I see an advantage to Texinfo, because it can easily
> express non-tree structured documents, something that in Org is not so
> easy, perhaps even not easy at all.

As you will.

Phil