From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jonathan Leech-Pepin Newsgroups: gmane.emacs.devel Subject: Re: On being web-friendly and why info must die Date: Sat, 6 Dec 2014 21:33:44 -0500 Message-ID: References: <20141205123549.GA29331@thyrsus.com> <2815659.zRQ0WWWeRr@descartes> <20141205175810.GD3120@thyrsus.com> <87wq66ufyt.fsf@wanadoo.es> <87zjb04tlw.fsf@gmx.us> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134ef5cc14e1d0509972453 X-Trace: ger.gmane.org 1417919672 4663 80.91.229.3 (7 Dec 2014 02:34:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 02:34:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rasmus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 07 03:34:27 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XxRg1-0003WL-Uc for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 03:34:26 +0100 Original-Received: from localhost ([::1]:56228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxRg0-000658-Tm for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 21:34:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxRfk-000652-BZ for emacs-devel@gnu.org; Sat, 06 Dec 2014 21:34:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxRfi-0007PU-Qy for emacs-devel@gnu.org; Sat, 06 Dec 2014 21:34:08 -0500 Original-Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:40708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxRfi-0007PL-K2 for emacs-devel@gnu.org; Sat, 06 Dec 2014 21:34:06 -0500 Original-Received: by mail-qg0-f52.google.com with SMTP id a108so2135934qge.25 for ; Sat, 06 Dec 2014 18:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sGJjtxIsr0+jYNBMhjhORxc9XWFNl1VTriV9Szi3Wm0=; b=qqF828g8qA+/YP357os8z90StXVZSxQRAO9+JxgE01TT3dTm4krM27zIxVKB54dESJ C9TCO0vHgi1yw7PD8/Y5KhNbbAkdF7m/pfnhw4S43KETseXH5OYWQMi80novq3alz0ko 655XcTUWAW3DBmFFPrSIij38vPQ2Otln+FheA7qPnLIoajTJepVFLLFU6oLXKYg3UWjs d8c7cjRWPQtq5XWGxXf/TJADHPcxIxB2oJNM3EVP0mW93lpXxVhSg4ztBd3EE2PV7i+x LtQJs1vB7SG5S5HmwIg2pAtHlyacm1kdbn+WejEQvWldV4f3s3tmNQMBYGedbXgC3kat qSvA== X-Received: by 10.140.19.104 with SMTP id 95mr39453471qgg.0.1417919644910; Sat, 06 Dec 2014 18:34:04 -0800 (PST) Original-Received: by 10.96.99.233 with HTTP; Sat, 6 Dec 2014 18:33:44 -0800 (PST) In-Reply-To: <87zjb04tlw.fsf@gmx.us> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179230 Archived-At: --001a1134ef5cc14e1d0509972453 Content-Type: text/plain; charset=UTF-8 Note: I'm only chiming in with regards to a few limitations of the org->texinfo export process. I wrote the exporter as a way to better understand the new exporter and came across a few syntax limitations when trying to account for texinfo syntax. On 6 December 2014 at 11:43, Rasmus wrote: [...] > > As pointed out earlier, Thomas S. Dye has converted the Org-manual to Org. > It's out of date, but may still be illustrative. > > > https://raw.githubusercontent.com/tsdye/orgmanual/master/orgmanual.org > Org only has a single sort of link specification "[[link][description]]" where link can be formatted in multiple ways to provide a method to retrieve the correct destination. This lead to a very limited subset of the @ref/@xref link types (which in turn requires the author to assume the burden of ensuring any "see" contexts. I made this decision with the assumption that the ox-texinfo exporter would be used solely for final export to info format, while other ox- backends could be used for HTML, plain text, etc. Org also does not have any concept of indexes. Thomas S. Dye took one path (after discussion of this issue with me while I was working on the exporter) and defined macros for each texinfo index type. An alternate path would be to define a link type that behaved similarly (replaced itself on export with an @index command. Neither is an ideal solution, the macro solution is probably the easier to work with, however implementing indexes in Org would require adding them to the syntax and providing a method to parse them when exporting to other formats (even if only ignoring them). > I could consider Org mode as a way of formatting manuals if I saw > > documentation presenting Org mode _as_ a way to format manuals. > > However, it would still have two big drawbacks as a candidate for GNU > > documentation. > > > > * It is a program. What we need is a format. > > This claim is simply wrong. > > (info "(org) Org syntax") > and > http://orgmode.org/worg/dev/org-syntax.html > If org were to be considered as a source of texinfo/info, determining a possible syntax for indexes would likely be necessary, but once that was done, the only real difference would be the lack of the multiple methods of defining cross references, yet if the only use was to output to info (leaving other formats to the org export process [html, ascii]) then this lack could be worked around by ensuring the correct context. Regards, Jonathan --001a1134ef5cc14e1d0509972453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note: I'm only chiming in with regards to a few l= imitations of the org->texinfo
export process.=C2=A0 I wrote th= e exporter as a way to better understand the new
exporter and came acros= s a few syntax limitations when trying to account
for texinfo syntax.

On 6 D= ecember 2014 at 11:43, Rasmus <rasmus@gmx.us> wrote:
[...]
=C2=A0

As pointed out earlier, Thomas S. Dye has converted the Org-manual t= o Org.
It's out of date, but may still be illustrative.

=C2=A0 =C2=A0 =C2=A0 https://raw.githubuserconten= t.com/tsdye/orgmanual/master/orgmanual.org
<= /blockquote>

Org only has a single sort of link specific= ation "[[link][description]]" where link
can be formatted in m= ultiple ways to provide a method to retrieve the correct
destination.=C2= =A0 This lead to a very limited subset of the @ref/@xref link types
(which in turn requires the author to assume the burden of ensuring = any "see"
contexts. I made this decision with the a= ssumption that the ox-texinfo exporter
would be used solely for final ex= port to info format, while other ox- backends
could be used f= or HTML, plain text, etc.

Org also does not have any conc= ept of indexes.=C2=A0 Thomas S. Dye took one path
(after disc= ussion of this issue with me while I was working on the exporter) and
de= fined macros for each texinfo index type.=C2=A0 An alternate path would be = to define
a link type that behaved similarly (replaced itself= on export with an @index
command.=C2=A0 Neither is an ideal solution, t= he macro solution is probably the easier
to work with, however implement= ing indexes in Org would require adding them to
the syntax and providing= a method to parse them when exporting to other formats
(even= if only ignoring them).

> I could consider Org mode as a way of formatting manuals if I saw
> documentation presenting Org mode _as_ a way to format manuals.
> However, it would still have two big drawbacks= as a candidate for GNU
> documentation.
>
> * It is a program.=C2=A0 What we need is a for= mat.

This claim is simply wrong.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (info "(org) Org syntax")
and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://orgmode.org/worg/dev/org-syntax.ht= ml

If org w= ere to be considered as a source of texinfo/info, determining a
possible= syntax for indexes would likely be necessary, but once that
was done, t= he only real difference would be the lack of the multiple methods
of def= ining cross references, yet if the only use was to output to info (leaving<= br>other formats to the org export process [html, ascii]) then this lack co= uld be
worked around by ensuring the correct context.

= Regards,
Jonathan
--001a1134ef5cc14e1d0509972453--