search

minad / org-modern

:unicorn: Modern Org Style
GNU General Public License v3.0
1.54k stars 48 forks source link

face nil and invisible in font-lock spec #168

Closed jdtsmith closed 10 months ago

jdtsmith commented 10 months ago

I've been trying track down a small issue in org-modern-indent together with org-modern. As you know both operate on blocks. When org-modern-block-name=t, upon flushing font lock or creating a new block "from scratch", the first opening curved bracket in org-modern does not appear at first, but only after "something" happens, like an overlay gets moved, etc. Like so:

image

Eventually this resolves, but sometimes this takes many seconds. This issue only occurs for the org-modern-block-name=t case below, ~and I've confirmed that face nil is the culprit. Somehow setting face to nil causes the line prefix to inherit this and not apply the updated line prefix at first. Do you know why face nil is required?~

Update: it's not face nil but invisible org-modern that causes the line prefix not to get applied. Works fine with the "Static replacement" case. I'm not sure why that doesn't happen on the #END line, but a simple fix is to use display to do the hiding, ala:

            (hide `(,@indent (2 '(face nil display "")) ,name))

With this, org-modern-indent works as intended. I can just recommend org-modern-block-name = '("" . "") but would be nice to work by default. Do you actually toggle invisible? Any other ideas/workaround you could suggest?

https://github.com/minad/org-modern/blob/418b1adeec936e42abe1e3151633951055909ea4/org-modern.el#L738-L747

minad commented 10 months ago

Good question, I wonder myself why the face nil is needed. I use this at multiple places (25 times in org-modern!) and the reason is that the other properties are not applied otherwise. But I can check if there is another way.

minad commented 10 months ago

it's not face nil but invisible org-modern that causes the line prefix not to get applied. Works fine with the "Static replacement" case. I'm not sure why that doesn't happen on the #END line, but a simple fix is to use display to do the hiding, ala:

Just saw your update. Using display "" is an alternative but this is generally considered the worse approach than using the invisible property (also by the Emacs maintainers), so we should not change that. See for example 067f9319d67b1170d46a394e039537bb9cb413e3.

Any other ideas/workaround you could suggest?

Maybe one should disable all org-modern block-related fontification if org-modern-indent is used? We should probably finally add the indent-related code to org-modern itself, which should make it easier to ensure compatibility.

jdtsmith commented 10 months ago

See for example https://github.com/minad/org-modern/commit/067f9319d67b1170d46a394e039537bb9cb413e3.

One mystery solved: that would explain why this delayed-draw bracket behavior just "showed up" one day last year! Is display="" worse from a speed point of view or is it just that org-fold is incompatible? I mean the static case (("‣" . "‣")) is already a display "something". It's probably a bug in the display code where line-prefix on invisible chars gives trouble. I've tracked down and helped with a few display bugs with inline images, but it's a wearying process. There's even one I'm ignoring related to invisible chars at the start of line which I came across in developing ultra-scroll.

Maybe one should disable all org-modern block-related fontification if org-modern-indent is used?

But it's so nice ;). For now I think I'll just recommend adding (org-modern-block-name '("" . "")) ; or other chars; so top bracket is drawn promptly.

We should probably finally add the indent-related code to org-modern itself, which should make it easier to ensure compatibility.

Would be happy to do this and retire org-modern-indent. It's inefficient of course to have font-lock match the same blocks twice, and my impression is that most people like org-modern-block-name enabled.