emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug#42184: org-fontify-whole-*-line in emacs 27 (was: Couple of issues w


From: Kévin Le Gouguec
Subject: Bug#42184: org-fontify-whole-*-line in emacs 27 (was: Couple of issues with org block meta lines faces)
Date: Tue, 14 Jul 2020 12:19:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Could Org maintainers weigh in on bug#42184?

To recap my understanding of the issue:

- org-fontify-whole-heading-line controls whether
  org-set-font-lock-defaults includes the final newline in the headline
  regexp (resp. org-fontify-whole-block-delimiter-line with begin/end
  block regexps).

- This assumes that fontifying the final newline is enough to fontify
  everything beyond this newline.

- This assumption is no longer valid with Emacs 27, where this extension
  is opt-in, using the :extend face attribute.

With Eli's help, I proposed a patch for org-mode against the emacs-27
branch that does something similar to what is done for the org-hide
face: when setting up the major mode, depending on those user options,
the :extend attribute is (re)set for the relevant faces (using a
compatibility function defined in org-compat).

I've reattached the patch for convenience.  Does it look sound?

Attachment: 0001-Fix-org-fontify-whole-line-by-setting-face-extension.patch
Description: Text Data


In addition to this issue, I'd like to ask about the org-block face:
should it be defined with :extend t unconditionally?  As explained in
bug#42184#35, I feel like it should (cf. attached screenshot), but
that's only my opinion.

Attachment: org-block.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]