Answers inline... On Fri, 7 Nov 2025 at 19:51, Ihor Radchenko <[email protected]> wrote:
> 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}") > > ? > Yes, we are. >> 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. > Fine. There seems to have been a major hiccup in savannah and, as I see, this specific commit is part of what they haven't restored. > >> >>> >> (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. > Workflows and preferences... I could write a couple monologues for stand-up comedy on this ;-) > >>> 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 Which introduced a lot of configurations to look at in the future. I'll remove xpinyin stuff FTBM > >> >>> (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. > OK, done. >> >>> (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 know, I have used them and they are sort of an overkill here IMvvHO. 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. > I have transformed the messages into proper comments. Otherwise, we will systematically bloat the *Message* buffer. -- > 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> > -- Fragen sind nicht da, um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler "Sagen's Paradeiser" (ORF: Als Radiohören gefährlich war) => write BE! Year 1 of the New Koprocracy
