Jacob Gerlach <jacobgerl...@gmail.com> writes: > The MWE (with native fontification -> t) looks ok for me, > > Thanks for taking time to check this. I should note that if I find a > new file (test.org) and yank the MWE, it is fontified correctly, but > if I save and kill the buffer and then find the file again, that is > when the problem occurs. In general, if I make a change that brings > back the fontification, it doesn't disappear again until freshly > finding the file.
I did this too (save and kill the buffer and then find the file again), again no issues, and even the issue described below disappeared ;) What you describe reminds me a bit of fontification issues with outshine.el, only that its just the opposite. When I find a file with e.g .el extension (having stored `outline-minor-mode' in the major-mode hook, and `outshine-hook-function' in the outline-minor-mode hook), the buffer is fontified correctly right away. But when I write some (outshine-style structured) content in a temp buffer in e.g. fundamental-mode, and then call `emacs-lisp-mode' on that buffer, the org-mode like headline-fontification is not there immediately, I first have to do something (visibility cycling, add a char or so...), then the 1st level headers turn blue ... > the only > fontification issue I see (and not only in your MWE) is that > headline > > > > ,---- > | * Heading with some add-to-list's (some commented) > > `---- > > looses its font due to the "list" in it -> '(some commented)'. > I see that often in my Org files - as soon as I type parens in a > headline it turn white. > > I do not observe the same. Since it is outside of an emacs-lisp source > block, why would it be interpreted as a "list"? no idea, but this 'unfontification' of headline with '(...)' in them happens quite frequently for me. -- cheers, Thorsten
