On Sat, 7 Feb 2026 at 20:49, Ihor Radchenko <[email protected]> wrote:
> Pedro Andres Aranda Gutierrez <[email protected]> writes: > > >> > the user should read the manual to find that the Org exporter > produces a > >> > list of missing scripts for the fonts used in the document in the > >> > *Messages* buffer. > >> > >> What about emitting this information as a warning? That should make it > >> more visible. Maybe we can also explicitly refer to the manual when we > > > > do emit the list of missing scripts. > >> > > > > Isn't this enough??? > > > > #+FROM:THE MANUAL > > If the fonts specified in the document class, or the fonts you specify > don't > > support a specific script, the LaTeX compiler will fail and Emacs will > > warn you. To help you fix the font setup, Org will include a list of > > /problematic/ fonts with the Emacs scripts they don't support in the > > *~*Messages*~* buffer. For example: > > > > #+begin_example > > Scripts missing: > > For font lmroman10-regular: emoji > > #+end_example > > > > In this case ... > > #+END_FROM:THE MANUAL > > > > Read through it once again... > > The manual is perfectly fine. > However, *Messages* do not pop when the problem occurs. So, users will > have to read the manual in advance to know that they should be looking > into *Messages*. Most users do not read /the whole manual/. > > In other words, I think that what is there is good, but can be better if > the list of scripts were in the *warnings* instead of *messages*. > > Is there any specific reason why you think that putting it is in > *warnings* is worse? > Because it is a multi-line message (one line per font) and unless you have a multi-line minibuffer eating up your editing window you would just see an incoherent For font lmroman10-regular: emoji In your minibuffer, provided this is the last warning. Because if there are other warnings, you wouldn't even see it. We would have to direct the user to the warnings buffer and he would have to open it. So, what is the difference between opening the warnings and the messages buffer there? > > >> > I don't know how much I break the style, but I have inserted > @headings to > >> > structure the text further and have added further hints about the > default > >> > fonts. Check and tell me. > >> > >> I like the changes. However, @heading feels off. Why not adding an > >> actual Org heading? > >> > > > > Because a) I already feel that we are having headings with too many > levels > > and > > b) the numbered headers break the flow and unnumbered heading just > > highlight a > > topic without breaking the logical flow. > > But you still introduce a heading, right? > Numbering can be explicitly disabled using UNNUMBERED property. > But is it quicker than adding ¿how many? stars and then a :property block. Just trying to be practical here... >> I have no intention to downgrade the features available in > >> org-latex-*-config. What I am looking for is a way to feed into these > >> variable using simple in-buffer keywords. The keywords, if present, will > >> override parts org-latex-*-config. > >> If you are ok with it, I will prepare a patch to support such in-buffer > >> keywords. > > > > Ideally, they shouldn't override, just populate... > > But once again, as long as the full functionality is accessible through > the > > variables, do whatever you see fit. > > Ok. > > -- > 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 2 of the New Koprocracy
