From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcin Borkowski Subject: Re: [ox, patch] Add #+SUBTITLE Date: Mon, 23 Mar 2015 09:32:23 +0100 Message-ID: <87iodst8q0.fsf@wmi.amu.edu.pl> References: <87a8z7z20k.fsf@gmx.us> <87vbht2kri.fsf@nicolasgoaziou.fr> <87sicx6of8.fsf@gmx.us> <87oanku5d0.fsf@wmi.amu.edu.pl> <87384w7iwy.fsf@gmx.us> <87lhiotyc7.fsf@wmi.amu.edu.pl> <87y4mo60ji.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZxmo-00026V-4S for emacs-orgmode@gnu.org; Mon, 23 Mar 2015 04:32:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZxmj-0007eq-66 for emacs-orgmode@gnu.org; Mon, 23 Mar 2015 04:32:38 -0400 Received: from msg.wmi.amu.edu.pl ([2001:808:114:2::50]:60777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZxmi-0007eg-RK for emacs-orgmode@gnu.org; Mon, 23 Mar 2015 04:32:33 -0400 Received: from localhost (localhost [127.0.0.1]) by msg.wmi.amu.edu.pl (Postfix) with ESMTP id AE7C55AE9C for ; Mon, 23 Mar 2015 09:32:30 +0100 (CET) Received: from msg.wmi.amu.edu.pl ([127.0.0.1]) by localhost (msg.wmi.amu.edu.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGSLAL+Ct3Rc for ; Mon, 23 Mar 2015 09:32:30 +0100 (CET) Received: from localhost (117-116.echostar.pl [213.156.117.116]) by msg.wmi.amu.edu.pl (Postfix) with ESMTPSA id 7CE3B5AE83 for ; Mon, 23 Mar 2015 09:32:29 +0100 (CET) In-reply-to: <87y4mo60ji.fsf@gmx.us> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org On 2015-03-23, at 01:05, Rasmus wrote: > Hi, > > First: Please don't take me being critical as meaning I'm necessarily > negative about. I'm just minimizing risk over the expectation. Of course, fine with me. It=E2=80=99s the criticism which can make this = project better (or help decide it=E2=80=99s unnecessary, which would spare the un= needed work;-)). Also, you make me think more and refine my idea, so thanks for the criticism! > Marcin Borkowski writes: > >>> - What happens when you cannot maintain it any longer? Note also tha= t the >> >> Either the project dies, or someone takes it over. The latter seems t= o >> be quite common in the LaTeX community, so I wouldn't be very worried. > > That does not seem like something you'd want to base Org on... You might have misunderstood me. I did not claim that it's often in the TeX world that people abandon projects, but /if/ they do, it's common that someone takes over the package. (Though I don=E2=80=99t have any re= al data, just my gut feeling.) >>> scope is somewhat different as a typical latex package solves a pro= blem >>> like "provide good tables" or "enhance itemize 2e" (ei2e). Such >>> packages are fairly easy to replace (e.g. sugfigure =E2=86=92 subca= ption). >> >> Fair enough. Not a problem imho, though. A =E2=80=9Cpackage=E2=80=9D= has a very wide >> definition in the LaTeX world, and I explained why a package would be >> better than a class (even though doing it as a package would be a bit >> more work with ensuring that it works with wide range of classes). > > I am talking about latex packages and the example mentions real latex > packages. A class would be a sure route to failure. A packages is fin= e. > But it's beside the point. You argue, if I understand correctly, for > amending ox-latex to rely on a very specialized package, which we may o= r > may not easily be able to replace should it come to that. Well, currently it relies on 15 packages anyway, including marvosym and wasysym which might not be present in every TeX installation, btw. (They should /really/ be only included when actually needed!) I don't see much difference. Besides, I'm not telling about /replacing/ the current exporter. The behavior I'm talking about could be optional, and turned on by an option. It would require changes to, say, maybe half of the transcoders in ox-latex, and a new preamble =E2=80=93 and that would be probably it. Instead of replacing them, they might behave in two ways (=E2=80=9Cold=E2= =80=9D one and =E2=80=9Cnew=E2=80=9D one) based on some option. Finally, assuming that it gets stable after a few months, I don=E2=80=99t= see the need for =E2=80=9Creplacing=E2=80=9D it. I don=E2=80=99t think Org s= yntax is about to change drastically. I can see your concern, though. If my proposal gets some traction, then Org would indeed depend on something which is not under its control, and it might be a real concern for some people. OTOH, it /does/ depend on a few third-party tools anyway =E2=80=93 some LaTeX packages, too. (Thou= gh they are stable, and not tightly coupled with Org itself.) But take, for instance, the current discussion about Org and bibliographies (which I=E2=80=99m only aware of, I don=E2=80=99t follow i= t). Assuming Org gets some standard syntax for citations, there will be a need for properly exporting them to LaTeX (probably using biblatex or optionally amsrefs). But these packages already exists, and are stable and well-known, and it=E2=80=99s fine to call them, so it doesn=E2=80=99t see= m a problem for me. Assuming we don=E2=80=99t want to clutter the exported file with \usepackage=E2=80=99s, this would require adding /a few lines/ to the pro= posed package (\RequirePackage{biblatex} and possibly some simple default setup). OTOH, the change in the proposed package /would/ be needed if something is added to Org core (like TODO keywords, tags or timestamps), which is not directly supported by LaTeX. I wouldn=E2=80=99t expect that to happe= n very often. >>> - I don't want latex code generated by org to a "special flavor" like= with >>> LyX. > >> In my vision, the huge preamble is replaced by \usepackage{orglatex} o= r >> something like this, and instead of, say, > > OK. > >> : \section{{\bfseries\sffamily TODO} hello\hfill{}\textsc{world}} >> >> (how is that not a =E2=80=9Cspecial flavor=E2=80=9D?) you would have >> >> : \section{\orgtodo{TODO}hello\orgtags{world}} >> >> or, if we decide to do a major surgery on LaTeX=E2=80=99s sectioning m= echanism >> (which is debatable), even >> >> : \section[orgtodo=3DTODO,orgtags=3Dworld]{hello} > > Both are appealing. > >>> - Why can the issues you have in mind not be solved by a specialized >>> derived backend? Such as ox-beamer or ox-koma-letter. >> >> This seems to bug you enough that you basically asked twice;-). > > No. Here is ask why you can't settle for another Org-mode backend, rat= her > than a new latex package. This can even live in contrib without signin= g > the copyright agreement with FSF. If it lives in contrib =E2=80=93 which is fine for me personally =E2=80=93= it would be used by a lot less people. If it=E2=80=99s official, Org would have bett= er PDF support /by default/. Notice that there might be also Org options mapped to many of the proposed package options, too, so that people wanting to change some more =E2=80=9Cstandard=E2=80=9D things would not have to edit LaTeX direc= tly. But I=E2=80=99m not sure that=E2=80=99s necessary, and it might be missing the point altogether. The point is (among others) to delegate typesetting to LaTeX, including setting various options. This way, both Org file is cleaner (since it doesn=E2=80=99t contain lots of customizations for /one= / backend) and the LaTeX file is cleaner (since it doesn=E2=80=99t contain hardwired things like the mentioned \bfseries, \sffamily or \hfill). Let me repeat: Org-mode is not a typesetting engine, and should not be imho, so typesetting/layout issues should be delegated to the tool which does that. Currently it=E2=80=99s not the case, and indeed Org exporter = makes some poor typographic decisions. > E.g. you could get a very similar result to what you are talking about = by > defining the macros at export-level (e.g. write-out > \providecommand\orgtodo...) and allowed writing a preamble or similar = (if > you really mind long preambles). That way anybody would also be able t= o > customize on the latex end, if they so desire. Of course. Even now, extensive customization on the LaTeX level is possible; some of my files have /a lot/ of #+LATEX_HEADER=E2=80=99s, for instance. But again: I consider this to be abusing Org to do what it shouldn=E2=80=99t do. >> As I said, people use Org-mode in various ways. [...]. For other >> people, [they make] a draft in Org they continue their work in LaTeX >> (...). For them, human-readable (and editable) LaTeX code is a nice >> thing. > > Good point. > >> Also, adding some options in a LaTeX package seems to have less fricti= on >> than in Org. In the former, you just code it and make a pull request = to >> the package maintainer (or send a patch, or even just file a feature >> request). In the latter, you bug Nicolas, and he has to think about t= he >> impact of your feature request for other backends (because Org is not >> LaTeX-centric!). > > I don't see the difference. For one, it /might/ be easier to find a TeX hacker (even for hire) to change something than an Emacs hacker (though I don=E2=80=99t really know= , both Emacs and LaTeX are kind of niche). Then, in case of LaTeX, basically /anyone/ can make a change; in case of Org, you need those pesky FSF papers. And, it might be a tad easier for a more casual user to tweak something on the LaTeX side (though I might be biased) =E2=80=93 quite a lot of LaT= eX tutorials mention \renewcommand and friends, and somehow people do it (sometimes even too often, imo!); seemingly, people are much more scared by Elisp. You might argue that it=E2=80=99s stupid, because Elisp is way= easier to program in than (La)TeX =E2=80=93 but that=E2=80=99s reality; moreover= , in case of LaTeX you often don=E2=80=99t really need =E2=80=9Cprogramming=E2=80=9D, = just replacing some strings with others, without fancy stuff like loops, conditionals etc., hence the macro system TeX uses is often enough even for casual users. You don=E2=80=99t need to be a programmer to understand : \newcommand{\reals}{\mathbb{R}} or even : \newcommand{\abs}[1]{\lvert #1\rvert} % btw, this is deprecated while even a simple change in Org transcoders or filters requires some knowledge of programming (and of Org exporter structure). Finally, the LaTeX package might make use of the =E2=80=9Ctemplate=E2=80=9D= mechanism of LaTeX3, which is aimed at ease of customization of various constructs in LaTeX (and is already usable, and in fact used by some packages). > =E2=80=94Rasmus Best, --=20 Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University