[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On being web-friendly and why info must die
From: |
Phillip Lord |
Subject: |
Re: On being web-friendly and why info must die |
Date: |
Fri, 19 Dec 2014 21:06:35 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
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
- Re: On being web-friendly and why info must die, (continued)
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/12
- Re: On being web-friendly and why info must die, Phillip Lord, 2014/12/15
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/15
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/16
- Re: On being web-friendly and why info must die, Phillip Lord, 2014/12/17
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/17
- Re: On being web-friendly and why info must die,
Phillip Lord <=
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/18
- Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/18
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/18
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/19
- Re: On being web-friendly and why info must die, Phillip Lord, 2014/12/19
- Re: On being web-friendly and why info must die, Phillip Lord, 2014/12/19
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/21
- Re: On being web-friendly and why info must die, Rasmus, 2014/12/07
- Re: On being web-friendly and why info must die, Christopher Allan Webber, 2014/12/05
- Re: On being web-friendly and why info must die, Eric S. Raymond, 2014/12/05