Pedro Andres Aranda Gutierrez <[email protected]> writes:
>>>> Including fontspec seems sometimes redundant, but I'm still not 100%
>> fine
>> >>> with not including it because of tracinglostchars.
>> >>
>> >> Does \tracinglostchars have anything to do with fontspec package? It
>> >> seems to be a TeX primitive:
>> https://tug.org/utilities/plain/cseq.html#tracinglostchars-rp
>> >
>> > Was not part of the generated code before, right. But it improves the
>> > information provided by the log.
>>
>> Then, I do not understand what you mean by
>> >>> ... I'm still not 100% fine with not including it because of
>> tracinglostchars
>
> That I'll keep it FTMB. This is not cast in stone and people may come up
> with better solutions. Currently, it does what I need, which is to provide
> explicit enough messages (we may want to detect and use in the future).
Are we still talking about keeping \usepackage{fontspec} (not
\tracinglostchars) in
;; Tracing lost chars: https://tex.stackexchange.com/questions/548901
;; FIXME: do we really need fontspec??
(insert "\\tracinglostchars=2\n%%\\usepackage{fontspec}")
?
>> In short, I have seen bugs introduced when code around calls to pop or
>> other function with side effect changes. It is not that your code is not
>> correct. It is my worry about maintainability of that code.
>> So, I generally prefer avoiding modifying staff by side effect unless
>> strictly necessary.
>
> I have changed that under protest. `pop' has been around in my programmer's
> life since I used the Intel 8008 and it is part of a 101 in programming.
There is nothing wrong with pop, except that IMHO it makes
maintainability of the code slightly worse. That's all.
(I am not sure why protest - car/cdr and pop would be equivalent
logic-wise)
Also, you did not change it. At least, I do not see any commits to that
effect on the branch.
>> >>> >> (warn "Fallback fonts only work with lualatex!")))
>> >>...
>> Let me elaborate.
>> Consider a user who sometimes want to use lualatex and sometimes
>> xelatex. Since xelatex does not support fallabacks, the user may want to
>> have a completely different font config for xelatex (more generic, less
>> satisfying font), but maintain a separate config for lualatex (better
>> font + fallback for rare strange symbols).
>> This would not be possible on your branch.
>
> The way I cope with this is I have a root .dir-locals.el in my
> $HOME/Documents with the most probable configuration (lualatex+fontspec)
> and when I need to go beyond that I place a document-specific
> .dir-locals.el, where I would put everything xelatex "needs and loves".
Ok. I personally would prefer a different workflow, but you definitely
proved that my example can work just fine for users. And we can
introduce an extra customization to split between xelatex and lualatex
if necessary anyway, so let's keep the warning.
>>> But why should we? There is org-latex-packages-alist where users can add
>> >> default packages. xpinyin might (or might not) be a nice default package
>> >> to load, by it has little to do with babel/polyglossia/font
>> configuration.
>> >
>> > Not so sure about this. Imagine someone comes up with a config that we
>> > can reasonably fit in this... Unfortunately, I haven't had time to
>> > study Japanese. Maybe when I retire...
>>
>> If someone comes up with ideas how to improve font config, we can add
>> whatever idea is presented then. I still do not understand why is it
>> necessary to keep reference to xpinyin in the code?
>> ...
> 2. I have seen it in most examples for xelatex with fontspec and CJK fonts
> and since I don't speak it, I can't judge whether it can be omitted or not.
> So better keep it.
Let's just ask.
https://emacs-china.org/t/help-implementing-better-out-of-the-box-xelatex-export-in-org/30405
>> >>> (when multi-lang
>> >>> (insert "%% \\usepackage[utf8]{inputenc}\n")
>> >>
>> >> Why do you need to insert a commented-out usepackage call?
>> >
>> > Helps me when looking at the result in a LaTeX export buffer.
>>
>> Could you elaborate?
>
> When I have problems, I export to a .tex file and then edit from there
> until I debug/cleanup. I may want to revert to pdflatex and there I would
> uncomment this line.
Ok. But than also produce a comment that explains this workflow to
others. Something like
(when multi-lang
(insert "%% Uncomment the following if you are debugging Org export and need
to use pdflatex\n")
(insert "%% \\usepackage[utf8]{inputenc}\n")
Otherwise, it will only be practically useful to you.
>> >>> (let ((lang-tag lang))
>> >>> ;; (message "new font family: (%s . %s)" lang props)
>> >>> (if-let* ((lang-alist (assoc lang
>> org-latex-language-alist))
>> >>> (lang-plist (cdr lang-alist)))
>> >>> (setq lang-tag (plist-get lang-plist
>> :polyglossia)))
>> >>> ;; (message "polyglossia language name is %s"
>> lang-tag)
>> >>> (insert (format "\n\\newfontfamily{\\%sfont%s}%s{%s}"
>> >>
>> >> Should the above comments be removed?
>> >
>> > Do they harm? They will help me remember what I did a couple months from
>> > now.
>>
>> No harm, except that they distract reading the code (for me).
>> I'd prefer proper comments that will not only remind _you_ what you did
>> but also explain things to others ;)
>
> Maybe the first is a bit more '(cryptic|distracting)' but I think the
> second isn't.
> And well, the lines can be uncommented in case we need to debug any
> specific configuration. I keep saying to me that this code is by no means
> perfect and we will need to debug. Am I over-cautious?
You are not. However, occasional messages rarely help debugging in
practice. They could in the specific scenarios you tested in the past,
but the same messages may be useless in the future. Also, messages are
not really the only way to debug Elisp. Elisp also has proper debuggers.
I would be OK if we _systematically_ added debug messages in a form of
logs everywhere. But occasional lines of commented code are unlikely to
be useful, IMHO.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
