[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Some thought about `org-latex-pdf-process-alist', was Re: (V9) [

From: Feng Shu
Subject: Re: [O] Some thought about `org-latex-pdf-process-alist', was Re: (V9) [PATCH] New feature: Use dvisvgm to preview latex formular
Date: Mon, 23 May 2016 12:20:52 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

> This is mixing together org-latex-packages-alist, org-latex-pdf-process
> and org-latex-document-class, org-latex-default-class,
> org-koma-letter-default-class etc, and latexmk/carara into one (modulus
> typos).  IMO, it introduces too much dependency and convolution.  Take
> :valid-class; When I add a new class CLASS, I need to add it to the
> correct entries in org-latex-pdf-process-alist.  You ask me to form a
> joint opinion about too many things at once.

Yes, I think: compile + class + packages = process, if I don't joint
them to a profile setting, it is impossible to swith process easily.

If you know the default class and packages setting is suitable for your
process, just ignore :default-class :valid-classes :packages-alist
:default-packages-alist and :packages-override, the four options are
used by user special processes.

> equivalent should be used.  I don’t care about the process.  I care about
> the final document and its correctness.

because latex system can deal with English very well by default, so you
can "don't care about the process", if I don't care about the process,
"the final document and its correctness" is just a dream. :-)

> This is the nature of LaTeX.  The packages that Org selects by default do
> not conflict with each other.

packages selected by org may conflict with user's latex package, so user
should edit `org-latex-default-packages-alist' by hand.

>> 2. I don't want every users have to write latex-header in every org-file
>> and I like: install ox-latex-chinese and
>>        (setq org-latex-default-pdf-process "cn/xelatex-xelatex-xelatex")
>> every org-file can export to pdf.
> I strongly disagree with this vision.
> This should be possible with org-latex-classes without limiting the
> flexibility of ox-latex.  Also, we already have a way of solving this
> use-case, namely org-export-define-derived-backend`.

`org-export-define-derived-backend' seem to be overkill for this situation.

> LaTeX success rests in its flexibility, so this critique is misfounded
> IMO.  The success of ox-latex is that it’s flexible enough to satisfy even
> power users’ use-cases, making it an uncompromizing alternative to plain
> LaTeX.

power users can do "anything" in org-mode, even rewrite ox-latex, my
question is that: is it flexible enough to let some power users to well
maintain some predefined configures which can make many beginning user's
install and config easily?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]