From: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: egh@e6h.org, 42184@debbugs.gnu.org, mail@nicolasgoaziou.fr, bzg@gnu.org
Subject: bug#42184: 27.0.91; org-fontify-whole-heading-line does not work in emacs 27
Date: Wed, 08 Jul 2020 13:50:54 +0200 [thread overview]
Message-ID: <871rlm1azl.fsf@gmail.com> (raw)
In-Reply-To: <871rlqeyrn.fsf@gmail.com> ("Kévin Le Gouguec"'s message of "Sun, 05 Jul 2020 18:02:04 +0200")
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>>> AFAICT, this is the simplest way to fix org-fontify-whole-heading-line
>>> and org-fontify-whole-block-delimiter-line for Emacs ≥27. These user
>>> options work under the assumption that simply fontifying the final
>>> newline is enough to extend attributes past EOL.
>>
>> Nevertheless, I would like to see the :extend attribute applied only
>> under the above options; there's the set-face-extend function for
>> doing that.
>
> OK. That's more or less what I had in mind when I went into my
> "long-term fix" ideas.
>
> Note that Org tries to support older Emacs versions. AFAICT, with my
> patch, (1) org-fontify-whole-heading-line is fixed for Emacs 27, (2) no
> further modification is needed for Emacs ≤26.
>
> I can try to cook up a patch based on set-face-extend instead, with all
> the fboundp fun that entails to prevent byte-compiler warnings with
> older Emacs versions. I'm not sure where the calls to set-face-extend
> should be inserted; when setting up the major mode?
Since all the other threads I'm following are stalled, I've taken a stab
at this:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1435 bytes --]
diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el
index c1aaf17ca2..b53c06c94f 100644
--- a/lisp/org/org-compat.el
+++ b/lisp/org/org-compat.el
@@ -101,6 +101,10 @@ org-table1-hline-regexp
(defun org-time-convert-to-list (time)
(seconds-to-time (float-time time))))
+(defun org--extend-faces (faces)
+ (when (fboundp 'set-face-extend)
+ (mapc (lambda (f) (set-face-extend f t)) faces)))
+
\f
;;; Emacs < 26.1 compatibility
diff --git a/lisp/org/org.el b/lisp/org/org.el
index 568f5b9b87..7ff4f5587f 100644
--- a/lisp/org/org.el
+++ b/lisp/org/org.el
@@ -5310,6 +5310,9 @@ org-fontify-meta-lines-and-blocks-1
beg-of-endline
(min (point-max) (if whole-blockline (min (point-max) (1+ end-of-endline)) end-of-endline))
'(face org-block-end-line))
+ (when whole-blockline
+ (org--extend-faces '(org-block-begin-line
+ org-block-end-line)))
t))
((member dc1 '("+title:" "+author:" "+email:" "+date:"))
(org-remove-flyspell-overlays-in
@@ -5600,7 +5603,8 @@ org-set-font-lock-defaults
'(org-font-lock-hook)
;; Headlines
`(,(if org-fontify-whole-heading-line
- "^\\(\\**\\)\\(\\* \\)\\(.*\n?\\)"
+ (prog1 "^\\(\\**\\)\\(\\* \\)\\(.*\n?\\)"
+ (org--extend-faces org-level-faces))
"^\\(\\**\\)\\(\\* \\)\\(.*\\)")
(1 (org-get-level-face 1))
(2 (org-get-level-face 2))
[-- Attachment #3: Type: text/plain, Size: 583 bytes --]
While it fixes the issue, I don't know if it's the cleanest way to do it
(repeatedly calling set-face-extend on the same faces every time an Org
buffer is opened/reverted seems a bit silly).
Also, while this is not part of the report because Erik's example
happens not to have any text between the block delimiters (#+begin_src
and #+end_src), I would like to re-emphasize that I'm pretty sure
org-block (and maybe org-quote and org-verse) should be defined with
:extend t unconditionally, to maintain the "rectangular" aspect the
blocks have in a browser once exported to HTML:
[-- Attachment #4: bug#42184-org-block.png --]
[-- Type: image/png, Size: 319121 bytes --]
[-- Attachment #5: Type: text/plain, Size: 84 bytes --]
If people agree, I can make at patch similar to bug#42184#17 for those
faces only.
next prev parent reply other threads:[~2020-07-08 11:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-04 2:29 bug#42184: 27.0.91; org-fontify-whole-heading-line does not work in emacs 27 Erik Hetzner
2020-07-04 17:13 ` Kévin Le Gouguec
2020-07-04 17:18 ` Eli Zaretskii
2020-07-04 17:50 ` Kévin Le Gouguec
2020-07-04 19:52 ` Kévin Le Gouguec
2020-07-05 2:30 ` Eli Zaretskii
2020-07-05 8:57 ` Kévin Le Gouguec
2020-07-05 14:58 ` Eli Zaretskii
2020-07-05 16:02 ` Kévin Le Gouguec
2020-07-05 16:21 ` Eli Zaretskii
2020-07-08 11:50 ` Kévin Le Gouguec [this message]
2020-07-09 14:16 ` Kévin Le Gouguec
2020-08-06 4:10 ` Kyle Meyer
2020-08-06 9:32 ` Kévin Le Gouguec
2020-08-06 13:35 ` Eli Zaretskii
2020-09-06 8:12 ` Bastien
2020-09-06 14:10 ` Kévin Le Gouguec
2020-09-06 15:06 ` Stefan Kangas
2020-09-06 14:19 ` Kyle Meyer
2020-09-06 15:06 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871rlm1azl.fsf@gmail.com \
--to=kevin.legouguec@gmail.com \
--cc=42184@debbugs.gnu.org \
--cc=bzg@gnu.org \
--cc=egh@e6h.org \
--cc=eliz@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.