Re: [O] [ox, patch] Add #+SUBTITLE

[Marcin Borkowski]

On 2015-03-23, at 01:05, Rasmus <address@hidden> 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’s the criticism which can make this project
better (or help decide it’s unnecessary, which would spare the unneeded
work;-)).  Also, you make me think more and refine my idea, so thanks
for the criticism!

> Marcin Borkowski <address@hidden> writes:
>
>>> - What happens when you cannot maintain it any longer?  Note also that the
>>
>> Either the project dies, or someone takes it over.  The latter seems to
>> 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’t have any real
data, just my gut feeling.)

>>>   scope is somewhat different as a typical latex package solves a problem
>>>   like "provide good tables" or "enhance itemize 2e" (ei2e).  Such
>>>   packages are fairly easy to replace (e.g. sugfigure → subcaption).
>>
>> Fair enough.  Not a problem imho, though.  A “package” 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 fine.
> 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 or
> 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 – and that would be probably it.
Instead of replacing them, they might behave in two ways (“old” one and
“new” one) based on some option.

Finally, assuming that it gets stable after a few months, I don’t see
the need for “replacing” it.  I don’t think Org syntax 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 – some LaTeX packages, too.  (Though they
are stable, and not tightly coupled with Org itself.)

But take, for instance, the current discussion about Org and
bibliographies (which I’m only aware of, I don’t follow it).  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’s fine to call them, so it doesn’t seem a problem for
me.  Assuming we don’t want to clutter the exported file with
\usepackage’s, this would require adding /a few lines/ to the proposed
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’t expect that to happen 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} or
>> something like this, and instead of, say,
>
> OK.
>
>> : \section{{\bfseries\sffamily TODO} hello\hfill{}\textsc{world}}
>>
>> (how is that not a “special flavor”?) you would have
>>
>> : \section{\orgtodo{TODO}hello\orgtags{world}}
>>
>> or, if we decide to do a major surgery on LaTeX’s sectioning mechanism
>> (which is debatable), even
>>
>> : \section[orgtodo=TODO,orgtags=world]{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, rather
> than a new latex package.  This can even live in contrib without signing
> the copyright agreement with FSF.

If it lives in contrib – which is fine for me personally – it would be
used by a lot less people.  If it’s official, Org would have better 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 “standard” things would not have to edit LaTeX directly.  But I’m
not sure that’s 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’t contain lots of customizations for /one/
backend) and the LaTeX file is cleaner (since it doesn’t 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’s 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 to
> 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’s, for
instance.  But again: I consider this to be abusing Org to do what it
shouldn’t 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 friction
>> 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 the
>> 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’t 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) – quite a lot of LaTeX
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’s stupid, because Elisp is way easier
to program in than (La)TeX – but that’s reality; moreover, in case of
LaTeX you often don’t really need “programming”, 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’t 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 “template” 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).

> —Rasmus

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University