GNU bug report logs - #42184
27.0.91; org-fontify-whole-heading-line does not work in emacs 27

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42184 in the body.
You can then email your comments to 42184 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Erik Hetzner <egh <at> e6h.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.91; org-fontify-whole-heading-line does not work in emacs 27
Date: Fri, 03 Jul 2020 19:29:01 -0700

[Message part 1 (text/plain, inline)]

Setting `org-fontify-whole-heading-line' and `org-fontify-whole-block-delimiter-line' does not give a background color to the entire line in emacs 27. It works in 26.3 (although the latter variable is not present).

To reproduce, evaluate:

(require 'org)
(setq org-fontify-whole-heading-line t
      org-fontify-whole-block-delimiter-line t) ;; omit in emacs 26
(load-theme 'leuven t) ;; uses a colored background for org headings

Then open a simple org file, e.g.

* Hello world
** test
#+begin_src
#+end_src

In emacs 26.3, the entire heading line (and block delimiter) has a background color. In emacs 27, this is not the case.

See attached images.

[emacs-26.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

[emacs-27.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

In GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10)
 of 2020-06-29 built on lcy01-amd64-005
Repository revision: 59e768d64ad97782249fda9e53b6adc94c6d0130
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit

Configured using:
 'configure --prefix= --prefix=/snap/emacs/current/usr --with-xwidgets
 --with-x-toolkit=gtk3 --without-xaw3d --with-modules --with-cairo
 'CFLAGS= -isystem/build/emacs/parts/emacs/install/usr/include'
 'CPPFLAGS= -isystem/build/emacs/parts/emacs/install/usr/include'
 'LDFLAGS= -L/build/emacs/parts/emacs/install/lib
 -L/build/emacs/parts/emacs/install/usr/lib
 -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
 -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr ob-ditaa ob-plantuml ol-bibtex bibtex org-clock
org-colview org-crypt org-habit org-agenda org-indent org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-faces
org-entities noutline outline easy-mmode org-version ob-emacs-lisp
org-table ol org-loaddefs find-func cal-menu calendar cal-loaddefs
org-list org-pcomplete pcomplete org-src org-keys ob-comint comint
ansi-color ring ob-core org-compat advice ob-eval org-macs thingatpt
help-fns radix-tree help-mode emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date subr-x seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 114056 8874)
 (symbols 48 12853 1)
 (strings 32 44116 2167)
 (string-bytes 1 1452734)
 (vectors 16 19756)
 (vector-slots 8 231546 15454)
 (floats 8 80 118)
 (intervals 56 298 0)
 (buffers 1000 12))

Message #8 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Erik Hetzner <egh <at> e6h.org>
Cc: 42184 <at> debbugs.gnu.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sat, 04 Jul 2020 19:13:58 +0200

[Message part 1 (text/plain, inline)]

Erik Hetzner <egh <at> e6h.org> writes:

> In emacs 26.3, the entire heading line (and block delimiter) has a background color. In emacs 27, this is not the case.
>
> See attached images.

With the attached diff against leuven, running

    emacs -Q -l $your_elisp_snippet $your_org_file

yields this (with commit d453cee177 on emacs-27):

[bug#42184-leuven-patch.png (image/png, attachment)]

[Message part 3 (text/plain, inline)]

I don't know if patching leuven is TRT?  Maybe the :extend t should be
added to the face definitions directly, since Org provides a knob
(org-fontify-whole-heading-line) to control whether the final newline is
fontified?

[leuven.patch (text/x-patch, inline)]

diff --git a/etc/themes/leuven-theme.el b/etc/themes/leuven-theme.el
index c298b536d2..30ac880e00 100644
--- a/etc/themes/leuven-theme.el
+++ b/etc/themes/leuven-theme.el
@@ -45,7 +45,7 @@ leuven
       ;; Leuven generic colors
       (cancel '(:slant italic :strike-through t :foreground "gray55"))
       (clock-line '(:box (:line-width 1 :color "#335EA8") :foreground "black" :background "#EEC900"))
-      (code-block '(:foreground "#000088" :background "#FFFFE0"))
+      (code-block '(:foreground "#000088" :background "#FFFFE0" :extend t))
       (code-inline '(:foreground "#006400" :background "#FDFFF7"))
       (column '(:height 1.0 :weight normal :slant normal :underline nil :strike-through nil :foreground "#E6AD4F" :background "#FFF2DE"))
       (diff-added '(:foreground "#008000" :background "#DDFFDD"))
@@ -66,14 +66,14 @@ leuven
       (mail-unread '(:weight bold :foreground "black"))
       (marked-line '(:weight bold :foreground "white" :background "red"))
       (match '(:weight bold :background "#FBE448")) ; occur patterns
-      (ol1 '(:height 1.3 :weight bold :overline "#A7A7A7" :foreground "#3C3C3C" :background "#F0F0F0"))
-      (ol2 '(:height 1.0 :weight bold :overline "#123555" :foreground "#123555" :background "#E5F4FB"))
-      (ol3 '(:height 1.0 :weight bold :foreground "#005522" :background "#EFFFEF"))
-      (ol4 '(:height 1.0 :weight bold :slant normal :foreground "#EA6300"))
-      (ol5 '(:height 1.0 :weight bold :slant normal :foreground "#E3258D"))
-      (ol6 '(:height 1.0 :weight bold :slant italic :foreground "#0077CC"))
-      (ol7 '(:height 1.0 :weight bold :slant italic :foreground "#2EAE2C"))
-      (ol8 '(:height 1.0 :weight bold :slant italic :foreground "#FD8008"))
+      (ol1 '(:height 1.3 :weight bold :overline "#A7A7A7" :foreground "#3C3C3C" :background "#F0F0F0" :extend t))
+      (ol2 '(:height 1.0 :weight bold :overline "#123555" :foreground "#123555" :background "#E5F4FB" :extend t))
+      (ol3 '(:height 1.0 :weight bold :foreground "#005522" :background "#EFFFEF" :extend t))
+      (ol4 '(:height 1.0 :weight bold :slant normal :foreground "#EA6300" :extend t))
+      (ol5 '(:height 1.0 :weight bold :slant normal :foreground "#E3258D" :extend t))
+      (ol6 '(:height 1.0 :weight bold :slant italic :foreground "#0077CC" :extend t))
+      (ol7 '(:height 1.0 :weight bold :slant italic :foreground "#2EAE2C" :extend t))
+      (ol8 '(:height 1.0 :weight bold :slant italic :foreground "#FD8008" :extend t))
       (paren-matched '(:background "#99CCFF"))
       (paren-unmatched '(:underline "red" :foreground nil :background "#FFDCDC"))
       (region '(:background "#ABDFFA"))
@@ -515,8 +515,8 @@ leuven
    `(org-beamer-tag ((,class (:box (:line-width 1 :color "#FABC18") :foreground "#2C2C2C" :background "#FFF8D0"))))
    `(org-block ((,class ,code-block)))
    `(org-block-background ((,class (:background "#FFFFE0"))))
-   `(org-block-begin-line ((,class (:underline "#A7A6AA" :foreground "#555555" :background "#E2E1D5"))))
-   `(org-block-end-line ((,class (:overline "#A7A6AA" :foreground "#555555" :background "#E2E1D5"))))
+   `(org-block-begin-line ((,class (:underline "#A7A6AA" :foreground "#555555" :background "#E2E1D5" :extend t))))
+   `(org-block-end-line ((,class (:overline "#A7A6AA" :foreground "#555555" :background "#E2E1D5" :extend t))))
    `(org-checkbox ((,class (:weight bold :box (:line-width 1 :style pressed-button) :foreground "white" :background "#777777"))))
    `(org-clock-overlay ((,class (:foreground "white" :background "SkyBlue4"))))
    `(org-code ((,class ,code-inline)))

Message #11 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org
Subject: Re: bug#42184: 27.0.91;
 org-fontify-whole-heading-line does not work in emacs 27
Date: Sat, 04 Jul 2020 20:18:10 +0300

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Sat, 04 Jul 2020 19:13:58 +0200
> Cc: 42184 <at> debbugs.gnu.org
> 
> I don't know if patching leuven is TRT?  Maybe the :extend t should be
> added to the face definitions directly, since Org provides a knob
> (org-fontify-whole-heading-line) to control whether the final newline is
> fontified?

Yes, I think the change should be in Org, not in the themes.

Message #14 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>, Bastien <bzg <at> gnu.org>
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sat, 04 Jul 2020 19:50:38 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
>> Date: Sat, 04 Jul 2020 19:13:58 +0200
>> Cc: 42184 <at> debbugs.gnu.org
>> 
>> I don't know if patching leuven is TRT?  Maybe the :extend t should be
>> added to the face definitions directly, since Org provides a knob
>> (org-fontify-whole-heading-line) to control whether the final newline is
>> fontified?
>
> Yes, I think the change should be in Org, not in the themes.

OK.  Paging in Nicolas and Bastien (I don't know who exactly should join
in on our fun, or if I should just cross-post to emacs-orgmode <at> gnu.org).

Have the Org maintainers given some thought to what should become of
org-fontify-whole-heading-line and
org-fontify-whole-block-delimiter-line from Emacs 27 onward?

If these options still make sense (i.e. users should be able to choose
between extended or non-extended backgrounds/under/overlines,
independently of how themes customize the faces), org-level-* and
org-block-{begin,end}-line should probably be defined with :extend t?


Relatedly (but not crucial to solving this bug), should org-block and
org-block-background also have :extend t?  It would make sense to me
since they delimit visual "blocks".


Last question (that one might be answered somewhere in Org's
documentation): how should we patch org-mode?  First on emacs-27, then
on org-mode's maint branch?

Message #17 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>, Bastien <bzg <at> gnu.org>
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sat, 04 Jul 2020 21:52:08 +0200

[Message part 1 (text/plain, inline)]

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> If these options still make sense (i.e. users should be able to choose
> between extended or non-extended backgrounds/under/overlines,
> independently of how themes customize the faces), org-level-* and
> org-block-{begin,end}-line should probably be defined with :extend t?

To make the discussion more concrete: here's a suggested patch for Org
against the emacs-27 branch; what say you?

[Message part 2 (text/x-patch, inline)]

diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el
index c1aaf17ca2..7c905ef07e 100644
--- a/lisp/org/org-compat.el
+++ b/lisp/org/org-compat.el
@@ -334,6 +334,13 @@ org-compatible-face
     specs))
 (make-obsolete 'org-compatible-face "you can remove it." "Org 9.0")
 
+(defmacro org-extended-face (attributes)
+  "Make face that extends beyond end of line.
+
+Up to Emacs 26, all faces extended beyond end of line; getting
+the same behaviour starting with Emacs 27 requires :extend t."
+  `(nconc ,attributes (when (>= emacs-major-version 27) '(:extend t))))
+
 (defun org-add-link-type (type &optional follow export)
   "Add a new TYPE link.
 FOLLOW and EXPORT are two functions.
diff --git a/lisp/org/org-faces.el b/lisp/org/org-faces.el
index 30eab9bc6b..37a47e7c50 100644
--- a/lisp/org/org-faces.el
+++ b/lisp/org/org-faces.el
@@ -28,6 +28,8 @@
 
 ;;; Code:
 
+(require 'org-compat)
+
 (defgroup org-faces nil
   "Faces in Org mode."
   :tag "Org Faces"
@@ -45,35 +47,35 @@ org-hide
 color of the frame."
   :group 'org-faces)
 
-(defface org-level-1 '((t :inherit outline-1))
+(defface org-level-1 `((t ,(org-extended-face '(:inherit outline-1))))
   "Face used for level 1 headlines."
   :group 'org-faces)
 
-(defface org-level-2 '((t :inherit outline-2))
+(defface org-level-2 `((t ,(org-extended-face '(:inherit outline-2))))
   "Face used for level 2 headlines."
   :group 'org-faces)
 
-(defface org-level-3 '((t :inherit outline-3))
+(defface org-level-3 `((t ,(org-extended-face '(:inherit outline-3))))
   "Face used for level 3 headlines."
   :group 'org-faces)
 
-(defface org-level-4 '((t :inherit outline-4))
+(defface org-level-4 `((t ,(org-extended-face '(:inherit outline-4))))
   "Face used for level 4 headlines."
   :group 'org-faces)
 
-(defface org-level-5 '((t :inherit outline-5))
+(defface org-level-5 `((t ,(org-extended-face '(:inherit outline-5))))
   "Face used for level 5 headlines."
   :group 'org-faces)
 
-(defface org-level-6 '((t :inherit outline-6))
+(defface org-level-6 `((t ,(org-extended-face '(:inherit outline-6))))
   "Face used for level 6 headlines."
   :group 'org-faces)
 
-(defface org-level-7 '((t :inherit outline-7))
+(defface org-level-7 `((t ,(org-extended-face '(:inherit outline-7))))
   "Face used for level 7 headlines."
   :group 'org-faces)
 
-(defface org-level-8 '((t :inherit outline-8))
+(defface org-level-8 `((t ,(org-extended-face '(:inherit outline-8))))
   "Face used for level 8 headlines."
   :group 'org-faces)
 
@@ -399,11 +401,16 @@ org-block
   :group 'org-faces
   :version "26.1")
 
-(defface org-block-begin-line '((t (:inherit org-meta-line)))
+(defface org-block-begin-line `((t ,(org-extended-face
+                                     '(:inherit org-meta-line))))
   "Face used for the line delimiting the begin of source blocks."
   :group 'org-faces)
 
-(defface org-block-end-line '((t (:inherit org-block-begin-line)))
+;; Explicitly extend this face; if a theme does not make it inherit
+;; from org-block-begin-line, the :extend attribute will remain
+;; unspecified.
+(defface org-block-end-line `((t ,(org-extended-face
+                                   '(:inherit org-block-begin-line))))
   "Face used for the line delimiting the end of source blocks."
   :group 'org-faces)
 

[Message part 3 (text/plain, inline)]

See the screenshots posted by Erik at the beginning of this thread[1]
and mine[2] for comparison.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42184#5
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42184#8

My aim was to allow you (Org maintainers) to commit this verbatim to the
org-mode repository, where you probably want to keep supporting Emacs
≤26.3.

NB: I'm far from an Elisp wizard, there may more elegant ways to solve
this than my backquotefest; suggestions welcome.

> Relatedly (but not crucial to solving this bug), should org-block and
> org-block-background also have :extend t?  It would make sense to me
> since they delimit visual "blocks".

I still think the answer to the above is "yes".  Will add to my patch if
you agree.

> Last question (that one might be answered somewhere in Org's
> documentation): how should we patch org-mode?  First on emacs-27, then
> on org-mode's maint branch?

Message #20 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sun, 05 Jul 2020 05:30:55 +0300

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: egh <at> e6h.org,  42184 <at> debbugs.gnu.org,  Nicolas Goaziou
>  <mail <at> nicolasgoaziou.fr>,  Bastien <bzg <at> gnu.org>
> Date: Sat, 04 Jul 2020 21:52:08 +0200
> 
> To make the discussion more concrete: here's a suggested patch for Org
> against the emacs-27 branch; what say you?

I don't understand why you extend all those faces: the original report
was about a much smaller set.  It is not the intent that every face
that happens to span the entire line be extended: that's why we made
':extend' by default be off for a face.

What am I missing?

Message #23 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sun, 05 Jul 2020 10:57:34 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
>> Cc: egh <at> e6h.org,  42184 <at> debbugs.gnu.org,  Nicolas Goaziou
>>  <mail <at> nicolasgoaziou.fr>,  Bastien <bzg <at> gnu.org>
>> Date: Sat, 04 Jul 2020 21:52:08 +0200
>> 
>> To make the discussion more concrete: here's a suggested patch for Org
>> against the emacs-27 branch; what say you?
>
> I don't understand why you extend all those faces: the original report
> was about a much smaller set.  It is not the intent that every face
> that happens to span the entire line be extended: that's why we made
> ':extend' by default be off for a face.
>
> What am I missing?

The original report was about the org-level-1 and org-level-2 faces, as
well as org-block-begin-line and the org-block-end-line.

The only faces I added were org-level-[3-8], because I don't see why
different heading levels should not work with
org-fontify-whole-heading-line.

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.


The long term fix might be for Org to (1) deprecate these user options
and let themes and/or users apply :extend t themselves, or (2) slap
:extend t onto the faces when setting up the major mode fontification
depending on these user options (Org already does similar on-the-fly
face tweaks; see e.g. org-hide).  Or something else.

It seems to me that this kind of change would be somewhat more involved
and breakage-prone, but if Org maintainers think this is the way forward
for emacs-27, I wouldn't mind.

Message #26 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sun, 05 Jul 2020 17:58:12 +0300

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: egh <at> e6h.org,  42184 <at> debbugs.gnu.org,  mail <at> nicolasgoaziou.fr,  bzg <at> gnu.org
> Date: Sun, 05 Jul 2020 10:57:34 +0200
> 
> > I don't understand why you extend all those faces: the original report
> > was about a much smaller set.  It is not the intent that every face
> > that happens to span the entire line be extended: that's why we made
> > ':extend' by default be off for a face.
> >
> > What am I missing?
> 
> The original report was about the org-level-1 and org-level-2 faces, as
> well as org-block-begin-line and the org-block-end-line.

Yes.  So I'd expect to see the respective faces have the :extend
attribute under each one of the 2 options cited in the original
report.

> The only faces I added were org-level-[3-8], because I don't see why
> different heading levels should not work with
> org-fontify-whole-heading-line.

The original code only affects certain heading levels, it doesn't
affect all of them.  So I see no need for any "consistency" here.

More generally, the :extend attribute is by default off because we
want most of the faces not to be extended.  Let's only extend the
minimum, not anything that could be extended in principle.  Which is
another aspect of your proposed patch I'd like to change: it seems to
cause these faces be extended unconditionally, not just under these
optional variables.  Or did I miss something?

> 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.

> The long term fix might be for Org to (1) deprecate these user options
> and let themes and/or users apply :extend t themselves, or (2) slap
> :extend t onto the faces when setting up the major mode fontification
> depending on these user options (Org already does similar on-the-fly
> face tweaks; see e.g. org-hide).  Or something else.

I don't see why these options should be deprecated, and even less why
the faces should have the :extend attribute.  It would go against the
intent behind introducing that attribute in the first place.

Thanks.

Message #29 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sun, 05 Jul 2020 18:02:04 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The only faces I added were org-level-[3-8], because I don't see why
>> different heading levels should not work with
>> org-fontify-whole-heading-line.
>
> The original code only affects certain heading levels, it doesn't
> affect all of them.

By "the original code", you mean this part in
org-set-font-lock-defaults, right?

> 	   `(,(if org-fontify-whole-heading-line
> 		  "^\\(\\**\\)\\(\\* \\)\\(.*\n?\\)"
> 		"^\\(\\**\\)\\(\\* \\)\\(.*\\)")

That seems to apply to all heading levels to me?  Group 1 captures all
but the last stars, group 2 the last star, and group 3 the heading text?

>                                                             Which is
> another aspect of your proposed patch I'd like to change: it seems to
> cause these faces be extended unconditionally, not just under these
> optional variables.  Or did I miss something?

IIUC, org-fontify-whole-heading-line (which predates :extend t) is Org's
way of letting users "opt in" to face extension, by applying the
org-level-* face to the final newline *iff* this user option is set.

Adding :extend t to the face definition thus will not cause the
backgrounds to extend unconditionally: as long as the user option is
unset, the final newline will not be fontified.

>> 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?

At this point, I should probably wait for Org maintainers to chime in…

Message #32 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sun, 05 Jul 2020 19:21:52 +0300

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: egh <at> e6h.org,  42184 <at> debbugs.gnu.org,  mail <at> nicolasgoaziou.fr,  bzg <at> gnu.org
> Date: Sun, 05 Jul 2020 18:02:04 +0200
> 
> At this point, I should probably wait for Org maintainers to chime in…

Indeed, and so would I.

Message #35 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: 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

[Message part 1 (text/plain, inline)]

Kévin Le Gouguec <kevin.legouguec <at> 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:

[Message part 2 (text/x-patch, inline)]

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)))
+
 
 ;;; 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))

[Message part 3 (text/plain, inline)]

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:

[bug#42184-org-block.png (image/png, attachment)]

[Message part 5 (text/plain, inline)]

If people agree, I can make at patch similar to bug#42184#17 for those
faces only.

Message #38 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Thu, 09 Jul 2020 16:16:33 +0200

[Message part 1 (text/plain, inline)]

Here is a variant of the previous patch, which correctly resets :extend
to nil if the user disables the relevant options (after reverting the
current buffer, or for newly opened ones).

This ends up looking similar to what Org does for org-hide; IMO this
seems like the most straightforward short-term fix.  In the long run,
these user options would probably deserve :set functions.

[0001-Fix-org-fontify-whole-line-by-setting-face-extension.patch (text/x-patch, inline)]

From 07d123c548051eb7f6bbac5c7f5a4e4b8411f976 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= <kevin.legouguec <at> gmail.com>
Date: Thu, 9 Jul 2020 16:02:49 +0200
Subject: [PATCH] Fix org-fontify-whole-*-line by setting face extension
 (bug#42184)

* lisp/org/org-compat.el (org--set-faces-extend): New function to set
face extension, for Emacs versions where this attribute exists.
* lisp/org/org.el (org-mode): Call it to set the extend attribute of
relevant faces to the correct value.
---
 lisp/org/org-compat.el | 4 ++++
 lisp/org/org.el        | 6 +++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/lisp/org/org-compat.el b/lisp/org/org-compat.el
index c1aaf17ca2..fcc325e475 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--set-faces-extend (faces extend-p)
+  (when (fboundp 'set-face-extend)
+    (mapc (lambda (f) (set-face-extend f extend-p)) faces)))
+
 
 ;;; Emacs < 26.1 compatibility
 
diff --git a/lisp/org/org.el b/lisp/org/org.el
index 568f5b9b87..fb31336ea4 100644
--- a/lisp/org/org.el
+++ b/lisp/org/org.el
@@ -4944,7 +4944,11 @@ org-mode
   ;; Try to set `org-hide' face correctly.
   (let ((foreground (org-find-invisible-foreground)))
     (when foreground
-      (set-face-foreground 'org-hide foreground))))
+      (set-face-foreground 'org-hide foreground)))
+  ;; Set face extension as requested.
+  (org--set-faces-extend '(org-block-begin-line org-block-end-line)
+                         org-fontify-whole-block-delimiter-line)
+  (org--set-faces-extend org-level-faces org-fontify-whole-heading-line))
 
 ;; Update `customize-package-emacs-version-alist'
 (add-to-list 'customize-package-emacs-version-alist
-- 
2.27.0

[Message part 3 (text/plain, inline)]

Should I post this patch to the org-mode mailing list?

Message #41 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kyle Meyer <kyle <at> kyleam.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 mail <at> nicolasgoaziou.fr, bzg <at> gnu.org
Subject: Re: bug#42184: 27.0.91;
 org-fontify-whole-heading-line does not work in emacs 27
Date: Thu, 06 Aug 2020 00:10:55 -0400

Kévin Le Gouguec writes:

> Here is a variant of the previous patch, which correctly resets :extend
> to nil if the user disables the relevant options (after reverting the
> current buffer, or for newly opened ones).
>
> This ends up looking similar to what Org does for org-hide; IMO this
> seems like the most straightforward short-term fix.  In the long run,
> these user options would probably deserve :set functions.

Thanks for working on this fix.  I of course can't speak for Bastien or
Nicolas, but this patch looks fine to me.  Assuming it's okay with Eli,
I'd suggest applying it to the emacs-27 branch.  (Once applied, I'd port
it to the Org repo, as I do with other changes in the Emacs repo that
touch Org files.)

Upstream in the thread you wrote:

> Relatedly (but not crucial to solving this bug), should org-block and
> org-block-background also have :extend t?  It would make sense to me
> since they delimit visual "blocks".

That would make sense to me as well.  (org-block-background hasn't
existed since v8.3, though.)

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#42184: 27.0.91;
 org-fontify-whole-heading-line does not work in emacs 27
Date: Thu, 06 Aug 2020 11:32:18 +0200

[Message part 1 (text/plain, inline)]

Kyle Meyer <kyle <at> kyleam.com> writes:

> Kévin Le Gouguec writes:
>
>> Here is a variant of the previous patch, which correctly resets :extend
>> to nil if the user disables the relevant options (after reverting the
>> current buffer, or for newly opened ones).
>>
>> This ends up looking similar to what Org does for org-hide; IMO this
>> seems like the most straightforward short-term fix.  In the long run,
>> these user options would probably deserve :set functions.
>
> Thanks for working on this fix.  I of course can't speak for Bastien or
> Nicolas, but this patch looks fine to me.  Assuming it's okay with Eli,
> I'd suggest applying it to the emacs-27 branch.  (Once applied, I'd port
> it to the Org repo, as I do with other changes in the Emacs repo that
> touch Org files.)

Thank you for the review.  I hope this can make it into 27.1 since this
bug seems to be getting some attention[1][2], but the (tentative?)
etc/HISTORY file on the emacs-27 branch makes me wonder if we aren't too
close to the release day…

> Upstream in the thread you wrote:
>
>> Relatedly (but not crucial to solving this bug), should org-block and
>> org-block-background also have :extend t?  It would make sense to me
>> since they delimit visual "blocks".
>
> That would make sense to me as well.

OK, here's a patch to do that for org-block:

[0001-lisp-org-org-faces.el-org-block-Set-face-extension-b.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

>                                       (org-block-background hasn't
> existed since v8.3, though.)

Huh!  I guess that calls for a further patch:

[0001-etc-themes-leuven-theme.el-class-Remove-obsolete-fac.patch (text/x-patch, attachment)]

[Message part 5 (text/plain, inline)]

(AFAICT this was the only reference to org-block-background in all Elisp
files.)

All three patches squashed together:

[0001-Fix-org-fontify-whole-line-by-setting-face-extension.patch (text/x-patch, attachment)]

[Message part 7 (text/plain, inline)]

[1] https://orgmode.org/list/87365za8yk.fsf <at> gmail.com/t/#mac68a8ca95f64cb3fe7161bb44454253aad39fd6
[2] https://old.reddit.com/r/emacs/comments/i26n46/why_does_my_orgmode_look_different_to_leuven/

Message #47 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kyle Meyer <kyle <at> kyleam.com>
Cc: egh <at> e6h.org, 42184 <at> debbugs.gnu.org, bzg <at> gnu.org, mail <at> nicolasgoaziou.fr,
 kevin.legouguec <at> gmail.com
Subject: Re: bug#42184: 27.0.91;
 org-fontify-whole-heading-line does not work in emacs 27
Date: Thu, 06 Aug 2020 16:35:13 +0300

> From: Kyle Meyer <kyle <at> kyleam.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  egh <at> e6h.org,  42184 <at> debbugs.gnu.org,  mail <at> nicolasgoaziou.fr,  bzg <at> gnu.org
> Date: Thu, 06 Aug 2020 00:10:55 -0400
> 
> Kévin Le Gouguec writes:
> 
> > Here is a variant of the previous patch, which correctly resets :extend
> > to nil if the user disables the relevant options (after reverting the
> > current buffer, or for newly opened ones).
> >
> > This ends up looking similar to what Org does for org-hide; IMO this
> > seems like the most straightforward short-term fix.  In the long run,
> > these user options would probably deserve :set functions.
> 
> Thanks for working on this fix.  I of course can't speak for Bastien or
> Nicolas, but this patch looks fine to me.  Assuming it's okay with Eli,
> I'd suggest applying it to the emacs-27 branch.

It's too late for Emacs 27.1, and in any case I'd like to hear the
blessing of Org developers before installing this.  (I'd expect this
to be first installed in Org and then in Emacs, not the other way
around, but if it's okay with the Org folks to do it otherwise, I
won't object.)

Message #52 received at 42184-done <at> debbugs.gnu.org (full text, mbox):

From: Bastien <bzg <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184-done <at> debbugs.gnu.org, Kyle Meyer <kyle <at> kyleam.com>,
 mail <at> nicolasgoaziou.fr, kevin.legouguec <at> gmail.com
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sun, 06 Sep 2020 10:12:51 +0200

Hi,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Kyle Meyer <kyle <at> kyleam.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  egh <at> e6h.org,  42184 <at> debbugs.gnu.org,  mail <at> nicolasgoaziou.fr,  bzg <at> gnu.org
>> Date: Thu, 06 Aug 2020 00:10:55 -0400
>> 
>> Kévin Le Gouguec writes:
>> 
>> > Here is a variant of the previous patch, which correctly resets :extend
>> > to nil if the user disables the relevant options (after reverting the
>> > current buffer, or for newly opened ones).
>> >
>> > This ends up looking similar to what Org does for org-hide; IMO this
>> > seems like the most straightforward short-term fix.  In the long run,
>> > these user options would probably deserve :set functions.
>> 
>> Thanks for working on this fix.  I of course can't speak for Bastien or
>> Nicolas, but this patch looks fine to me.  Assuming it's okay with Eli,
>> I'd suggest applying it to the emacs-27 branch.
>
> It's too late for Emacs 27.1, and in any case I'd like to hear the
> blessing of Org developers before installing this.

The fix has been installed in Org and will be available for Org 9.4,
which we hope to release very soon.  So I'm closing this report now,
unless this is bad policy to close the bug report before it is fixed
in Emacs.

> (I'd expect this
> to be first installed in Org and then in Emacs, not the other way
> around, but if it's okay with the Org folks to do it otherwise, I
> won't object.)

It is okay to make fixes to Emacs Org then to backport them to Org
maint branch, but since it is additional work, we prefer fixes to go
directly to the maint branch, before we merge it into Emacs.

Thanks,

-- 
 Bastien

Message #55 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 42184 <at> debbugs.gnu.org
Cc: bzg <at> gnu.org, egh <at> e6h.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not
 work in emacs 27
Date: Sun, 06 Sep 2020 16:10:01 +0200

Bastien <bzg <at> gnu.org> writes:

> It is okay to make fixes to Emacs Org then to backport them to Org
> maint branch, but since it is additional work, we prefer fixes to go
> directly to the maint branch, before we merge it into Emacs.

Speaking of Org's maint branch (where the fix has been applied), are
there plans to synchronize it with the emacs-27 branch, so that Emacs
27.2 benefits from all the fixes to the 9.3 release?

Message #58 received at 42184-done <at> debbugs.gnu.org (full text, mbox):

From: Kyle Meyer <kyle <at> kyleam.com>
To: Bastien <bzg <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184-done <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr,
 kevin.legouguec <at> gmail.com
Subject: Re: bug#42184: 27.0.91;
 org-fontify-whole-heading-line does not work in emacs 27
Date: Sun, 06 Sep 2020 10:19:23 -0400

Bastien writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> (I'd expect this
>> to be first installed in Org and then in Emacs, not the other way
>> around, but if it's okay with the Org folks to do it otherwise, I
>> won't object.)
>
> It is okay to make fixes to Emacs Org then to backport them to Org
> maint branch, but since it is additional work, we prefer fixes to go
> directly to the maint branch, before we merge it into Emacs.

As the person primarily doing that porting for quite some time now, I of
course don't disagree with that.  My suggestion was in the context of
hoping to get the change into Emacs 27 at a point when a full Org sync
was not going to happen.

Message #61 received at 42184 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>, 
 42184 <at> debbugs.gnu.org
Cc: bzg <at> gnu.org, egh <at> e6h.org
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not work
 in emacs 27
Date: Sun, 6 Sep 2020 15:06:26 +0000

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> Speaking of Org's maint branch (where the fix has been applied), are
> there plans to synchronize it with the emacs-27 branch, so that Emacs
> 27.2 benefits from all the fixes to the 9.3 release?

If the maint branch contains only bug fixes, why shouldn't we?

Eli will explain what he prefers, but I would propose to open a new bug
report to track it, and we can mark it as blocking for the Emacs 27.2
release.  That way there is less risk of forgetting about it when it's
time to make the next point release.

Message #64 received at 42184-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Bastien <bzg <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: egh <at> e6h.org, 42184-done <at> debbugs.gnu.org, Kyle Meyer <kyle <at> kyleam.com>,
 mail <at> nicolasgoaziou.fr, kevin.legouguec <at> gmail.com
Subject: Re: bug#42184: 27.0.91; org-fontify-whole-heading-line does not work
 in emacs 27
Date: Sun, 6 Sep 2020 15:06:21 +0000

Bastien <bzg <at> gnu.org> writes:

> The fix has been installed in Org and will be available for Org 9.4,
> which we hope to release very soon.  So I'm closing this report now,
> unless this is bad policy to close the bug report before it is fixed
> in Emacs.

Thank you.

IMO, it is highly preferred that you routinely close Emacs bugs related
to Org mode when you have fixed them on your end.  We only need to track
that the bug has been handled in a satisfactory manner.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.