[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) [
Re: [O] Some thought about `org-latex-pdf-process-alist', was Re: (V9) [PATCH] New feature: Use dvisvgm to preview latex formular
Mon, 23 May 2016 12:20:52 +0800
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
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?