bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

Hi. This issue comes from Reddit,
https://www.reddit.com/r/emacs/comments/v0i4js/extend_org_heading_background_face_past_the/.
Basically, if I fold text using text properties, the heading background
does not extend to the end of the window. To quote /u/yantar92: "This is
because the trailing newline in the folded heading gets hidden. If the
trailing newline is invisible, :extend t has no effect. It is Emacs
limitation, AFAIK." It would be great if we could make the :extend
property work with invisible text.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
 1.17.8) of 2023-09-12 built on hydrogen
Repository revision: 2b6928edb978c5aeac6f81a1b2d5f38380d5564f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Gentoo Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --datarootdir=/usr/share
 --disable-silent-rules --docdir=/usr/share/doc/emacs-30.0.9999
 --htmldir=/usr/share/doc/emacs-30.0.9999/html --libdir=/usr/lib64
 --program-suffix=-emacs-30-vcs --includedir=/usr/include/emacs-30-vcs
 --infodir=/usr/share/info/emacs-30-vcs --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --enable-xattr --with-dbus --with-modules --with-gameuser=:gamestat
 --with-libgmp --without-gpm --with-native-compilation=aot --with-json
 --without-kerberos --without-kerberos5 --with-lcms2 --with-xml2
 --with-mailutils --without-selinux --with-sqlite3 --with-gnutls
 --with-libsystemd --with-threads --with-tree-sitter --without-wide-int
 --with-sound=no --with-zlib --with-x --without-pgtk --without-ns
 --without-gconf --without-gsettings --without-toolkit-scroll-bars
 --with-xpm --with-xft --with-cairo --with-harfbuzz --with-libotf
 --with-m17n-flt --with-x-toolkit=no --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-webp --with-imagemagick
 --with-dumping=pdumper 'CFLAGS=-Ofast -fno-finite-math-only
 -fomit-frame-pointer -march=skylake -malign-data=cacheline -pipe
 -fgraphite-identity -floop-nest-optimize -fira-region=mixed
 -fira-algorithm=CB -fira-hoist-pressure -fira-loop-pressure'
 LDFLAGS=-Wl,--as-needed'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ IMAGEMAGICK JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SQLITE3 THREADS TIFF
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM ZLIB

Important settings:
  value of $LANG: C.utf8
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  parrot-mode: t
  midnight-mode: t
  pdf-occur-global-minor-mode: t
  org-ai-global-mode: t
  dirvish-override-dired-mode: t
  emms-playing-time-display-mode: t
  emms-playing-time-mode: t
  emms-mode-line-mode: t
  async-bytecomp-package-mode: t
  global-wakatime-mode: t
  wakatime-mode: t
  global-org-modern-mode: t
  org-roam-db-autosync-mode: t
  winum-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  eat-eshell-visual-command-mode: t
  eat-eshell-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  projectile-mode: t
  git-auto-commit-mode: t
  eros-mode: t
  nameless-mode: t
  highlight-quoted-mode: t
  outline-minor-faces-mode: t
  vi-tilde-fringe-mode: t
  display-line-numbers-mode: t
  copilot-mode: t
  evil-cleverparens-mode: t
  corfu-history-mode: t
  save-place-mode: t
  recentf-mode: t
  global-so-long-mode: t
  so-long-minor-mode: t
  envrc-global-mode: t
  envrc-mode: t
  beacon-mode: t
  vimish-fold-global-mode: t
  vimish-fold-mode: t
  which-key-mode: t
  savehist-mode: t
  better-jumper-mode: t
  vertico-multiform-mode: t
  vertico-mouse-mode: t
  vertico-mode: t
  all-the-icons-completion-mode: t
  marginalia-mode: t
  evil-goggles-mode: t
  evil-snipe-override-mode: t
  evil-snipe-mode: t
  evil-snipe-override-local-mode: t
  evil-snipe-local-mode: t
  evil-owl-mode: t
  repeat-mode: t
  restore-point-mode: t
  kill-ring-deindent-mode: t
  aas-global-mode: t
  aas-mode: t
  rxt-mode: t
  hl-todo-mode: t
  outline-minor-mode: t
  global-git-commit-mode: t
  gcmh-mode: t
  winner-mode: t
  smartparens-global-mode: t
  undo-fu-session-global-mode: t
  undo-fu-session-mode: t
  undo-fu-mode: t
  ws-butler-global-mode: t
  editorconfig-mode: t
  corfu-popupinfo-mode: t
  global-corfu-mode: t
  corfu-mode: t
  minions-mode: t
  breadcrumb-mode: t
  breadcrumb-local-mode: t
  global-yank-indent-mode: t
  yank-indent-mode: t
  exwm-mff-mode: t
  persp-mode: t
  server-mode: t
  +lsp-optimization-mode: t
  evil-mode: t
  evil-local-mode: t
  +popup-mode: t
  override-global-mode: t
  general-override-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  undelete-frame-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t
  hs-minor-mode: t

Load-path shadows:
/home/st/.config/emacs/.local/straight/build-30.0.50/ef-themes/theme-loaddefs hides /home/st/.config/emacs/.local/straight/build-30.0.50/standard-themes/theme-loaddefs
/home/st/.config/emacs/.local/straight/build-30.0.50/ef-themes/theme-loaddefs hides /home/st/.config/emacs/.local/straight/build-30.0.50/modus-themes/theme-loaddefs
/home/st/.config/emacs/.local/straight/build-30.0.50/cmake-mode/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/home/st/.config/emacs/.local/straight/build-30.0.50/cmake-mode/cmake-mode hides /usr/share/emacs/site-lisp/cmake/cmake-mode
/home/st/.config/emacs/.local/straight/build-30.0.50/dash/dash hides /usr/share/emacs/site-lisp/dash/dash
/usr/share/emacs/site-lisp/desktop-entry-mode hides /usr/share/emacs/site-lisp/desktop-file-utils/desktop-entry-mode
/home/st/.config/emacs/.local/straight/build-30.0.50/epl/epl hides /usr/share/emacs/site-lisp/epl/epl
/home/st/.config/emacs/.local/straight/build-30.0.50/pkg-info/pkg-info hides /usr/share/emacs/site-lisp/pkg-info/pkg-info
/usr/share/emacs/site-lisp/ratpoison hides /usr/share/emacs/site-lisp/ratpoison/ratpoison
/home/st/.config/emacs/.local/straight/build-30.0.50/external-completion/external-completion hides /usr/share/emacs/30.0.50/lisp/external-completion
/home/st/.config/emacs/.local/straight/build-30.0.50/jsonrpc/jsonrpc hides /usr/share/emacs/30.0.50/lisp/jsonrpc
/home/st/.config/emacs/.local/straight/build-30.0.50/ef-themes/theme-loaddefs hides /usr/share/emacs/30.0.50/lisp/theme-loaddefs
/home/st/.config/emacs/.local/straight/build-30.0.50/transient/transient hides /usr/share/emacs/30.0.50/lisp/transient
/home/st/.config/emacs/.local/straight/build-30.0.50/bind-key/bind-key hides /usr/share/emacs/30.0.50/lisp/use-package/bind-key
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package-bind-key hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-bind-key
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package-core hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-core
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package-delight hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-delight
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package-diminish hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-diminish
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package-ensure hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-ensure
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package-jump hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-jump
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package-lint hides /usr/share/emacs/30.0.50/lisp/use-package/use-package-lint
/home/st/.config/emacs/.local/straight/build-30.0.50/use-package/use-package hides /usr/share/emacs/30.0.50/lisp/use-package/use-package
/home/st/.config/emacs/.local/straight/build-30.0.50/eglot/eglot hides /usr/share/emacs/30.0.50/lisp/progmodes/eglot
/home/st/.config/emacs/.local/straight/build-30.0.50/flymake/flymake hides /usr/share/emacs/30.0.50/lisp/progmodes/flymake
/home/st/.config/emacs/.local/straight/build-30.0.50/project/project hides /usr/share/emacs/30.0.50/lisp/progmodes/project
/home/st/.config/emacs/.local/straight/build-30.0.50/xref/xref hides /usr/share/emacs/30.0.50/lisp/progmodes/xref
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-C hides /usr/share/emacs/30.0.50/lisp/org/ob-C
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-awk hides /usr/share/emacs/30.0.50/lisp/org/ob-awk
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-calc hides /usr/share/emacs/30.0.50/lisp/org/ob-calc
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-clojure hides /usr/share/emacs/30.0.50/lisp/org/ob-clojure
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-core hides /usr/share/emacs/30.0.50/lisp/org/ob-core
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-ditaa hides /usr/share/emacs/30.0.50/lisp/org/ob-ditaa
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-dot hides /usr/share/emacs/30.0.50/lisp/org/ob-dot
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-emacs-lisp hides /usr/share/emacs/30.0.50/lisp/org/ob-emacs-lisp
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-eshell hides /usr/share/emacs/30.0.50/lisp/org/ob-eshell
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-exp hides /usr/share/emacs/30.0.50/lisp/org/ob-exp
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-forth hides /usr/share/emacs/30.0.50/lisp/org/ob-forth
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-gnuplot hides /usr/share/emacs/30.0.50/lisp/org/ob-gnuplot
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-haskell hides /usr/share/emacs/30.0.50/lisp/org/ob-haskell
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-julia hides /usr/share/emacs/30.0.50/lisp/org/ob-julia
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-lilypond hides /usr/share/emacs/30.0.50/lisp/org/ob-lilypond
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-lisp hides /usr/share/emacs/30.0.50/lisp/org/ob-lisp
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-lob hides /usr/share/emacs/30.0.50/lisp/org/ob-lob
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-makefile hides /usr/share/emacs/30.0.50/lisp/org/ob-makefile
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-octave hides /usr/share/emacs/30.0.50/lisp/org/ob-octave
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-perl hides /usr/share/emacs/30.0.50/lisp/org/ob-perl
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-plantuml hides /usr/share/emacs/30.0.50/lisp/org/ob-plantuml
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-processing hides /usr/share/emacs/30.0.50/lisp/org/ob-processing
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-python hides /usr/share/emacs/30.0.50/lisp/org/ob-python
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-ref hides /usr/share/emacs/30.0.50/lisp/org/ob-ref
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-ruby hides /usr/share/emacs/30.0.50/lisp/org/ob-ruby
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-R hides /usr/share/emacs/30.0.50/lisp/org/ob-R
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-comint hides /usr/share/emacs/30.0.50/lisp/org/ob-comint
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-css hides /usr/share/emacs/30.0.50/lisp/org/ob-css
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-eval hides /usr/share/emacs/30.0.50/lisp/org/ob-eval
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-fortran hides /usr/share/emacs/30.0.50/lisp/org/ob-fortran
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-groovy hides /usr/share/emacs/30.0.50/lisp/org/ob-groovy
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-java hides /usr/share/emacs/30.0.50/lisp/org/ob-java
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-latex hides /usr/share/emacs/30.0.50/lisp/org/ob-latex
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-lua hides /usr/share/emacs/30.0.50/lisp/org/ob-lua
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-matlab hides /usr/share/emacs/30.0.50/lisp/org/ob-matlab
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-maxima hides /usr/share/emacs/30.0.50/lisp/org/ob-maxima
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-ocaml hides /usr/share/emacs/30.0.50/lisp/org/ob-ocaml
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-org hides /usr/share/emacs/30.0.50/lisp/org/ob-org
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-js hides /usr/share/emacs/30.0.50/lisp/org/ob-js
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-sass hides /usr/share/emacs/30.0.50/lisp/org/ob-sass
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-scheme hides /usr/share/emacs/30.0.50/lisp/org/ob-scheme
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-screen hides /usr/share/emacs/30.0.50/lisp/org/ob-screen
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-sed hides /usr/share/emacs/30.0.50/lisp/org/ob-sed
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-shell hides /usr/share/emacs/30.0.50/lisp/org/ob-shell
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-sql hides /usr/share/emacs/30.0.50/lisp/org/ob-sql
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-sqlite hides /usr/share/emacs/30.0.50/lisp/org/ob-sqlite
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-table hides /usr/share/emacs/30.0.50/lisp/org/ob-table
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob-tangle hides /usr/share/emacs/30.0.50/lisp/org/ob-tangle
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ob hides /usr/share/emacs/30.0.50/lisp/org/ob
/home/st/.config/emacs/.local/straight/build-30.0.50/org/oc-basic hides /usr/share/emacs/30.0.50/lisp/org/oc-basic
/home/st/.config/emacs/.local/straight/build-30.0.50/org/oc-biblatex hides /usr/share/emacs/30.0.50/lisp/org/oc-biblatex
/home/st/.config/emacs/.local/straight/build-30.0.50/org/oc-bibtex hides /usr/share/emacs/30.0.50/lisp/org/oc-bibtex
/home/st/.config/emacs/.local/straight/build-30.0.50/org/oc-csl hides /usr/share/emacs/30.0.50/lisp/org/oc-csl
/home/st/.config/emacs/.local/straight/build-30.0.50/org/oc-natbib hides /usr/share/emacs/30.0.50/lisp/org/oc-natbib
/home/st/.config/emacs/.local/straight/build-30.0.50/org/oc hides /usr/share/emacs/30.0.50/lisp/org/oc
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-bbdb hides /usr/share/emacs/30.0.50/lisp/org/ol-bbdb
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-bibtex hides /usr/share/emacs/30.0.50/lisp/org/ol-bibtex
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-docview hides /usr/share/emacs/30.0.50/lisp/org/ol-docview
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-doi hides /usr/share/emacs/30.0.50/lisp/org/ol-doi
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-eshell hides /usr/share/emacs/30.0.50/lisp/org/ol-eshell
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-eww hides /usr/share/emacs/30.0.50/lisp/org/ol-eww
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-gnus hides /usr/share/emacs/30.0.50/lisp/org/ol-gnus
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-info hides /usr/share/emacs/30.0.50/lisp/org/ol-info
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-irc hides /usr/share/emacs/30.0.50/lisp/org/ol-irc
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-man hides /usr/share/emacs/30.0.50/lisp/org/ol-man
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-mhe hides /usr/share/emacs/30.0.50/lisp/org/ol-mhe
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-rmail hides /usr/share/emacs/30.0.50/lisp/org/ol-rmail
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol-w3m hides /usr/share/emacs/30.0.50/lisp/org/ol-w3m
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ol hides /usr/share/emacs/30.0.50/lisp/org/ol
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-agenda hides /usr/share/emacs/30.0.50/lisp/org/org-agenda
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-archive hides /usr/share/emacs/30.0.50/lisp/org/org-archive
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-attach-git hides /usr/share/emacs/30.0.50/lisp/org/org-attach-git
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-attach hides /usr/share/emacs/30.0.50/lisp/org/org-attach
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-capture hides /usr/share/emacs/30.0.50/lisp/org/org-capture
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-clock hides /usr/share/emacs/30.0.50/lisp/org/org-clock
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-colview hides /usr/share/emacs/30.0.50/lisp/org/org-colview
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-compat hides /usr/share/emacs/30.0.50/lisp/org/org-compat
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-crypt hides /usr/share/emacs/30.0.50/lisp/org/org-crypt
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-ctags hides /usr/share/emacs/30.0.50/lisp/org/org-ctags
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-cycle hides /usr/share/emacs/30.0.50/lisp/org/org-cycle
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-datetree hides /usr/share/emacs/30.0.50/lisp/org/org-datetree
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-duration hides /usr/share/emacs/30.0.50/lisp/org/org-duration
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-element hides /usr/share/emacs/30.0.50/lisp/org/org-element
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-entities hides /usr/share/emacs/30.0.50/lisp/org/org-entities
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-faces hides /usr/share/emacs/30.0.50/lisp/org/org-faces
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-feed hides /usr/share/emacs/30.0.50/lisp/org/org-feed
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-fold-core hides /usr/share/emacs/30.0.50/lisp/org/org-fold-core
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-fold hides /usr/share/emacs/30.0.50/lisp/org/org-fold
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-footnote hides /usr/share/emacs/30.0.50/lisp/org/org-footnote
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-goto hides /usr/share/emacs/30.0.50/lisp/org/org-goto
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-habit hides /usr/share/emacs/30.0.50/lisp/org/org-habit
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-id hides /usr/share/emacs/30.0.50/lisp/org/org-id
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-indent hides /usr/share/emacs/30.0.50/lisp/org/org-indent
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-inlinetask hides /usr/share/emacs/30.0.50/lisp/org/org-inlinetask
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-keys hides /usr/share/emacs/30.0.50/lisp/org/org-keys
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-lint hides /usr/share/emacs/30.0.50/lisp/org/org-lint
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-list hides /usr/share/emacs/30.0.50/lisp/org/org-list
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-macro hides /usr/share/emacs/30.0.50/lisp/org/org-macro
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-macs hides /usr/share/emacs/30.0.50/lisp/org/org-macs
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-mobile hides /usr/share/emacs/30.0.50/lisp/org/org-mobile
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-mouse hides /usr/share/emacs/30.0.50/lisp/org/org-mouse
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-num hides /usr/share/emacs/30.0.50/lisp/org/org-num
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-pcomplete hides /usr/share/emacs/30.0.50/lisp/org/org-pcomplete
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-persist hides /usr/share/emacs/30.0.50/lisp/org/org-persist
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-plot hides /usr/share/emacs/30.0.50/lisp/org/org-plot
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-protocol hides /usr/share/emacs/30.0.50/lisp/org/org-protocol
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-refile hides /usr/share/emacs/30.0.50/lisp/org/org-refile
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-src hides /usr/share/emacs/30.0.50/lisp/org/org-src
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-table hides /usr/share/emacs/30.0.50/lisp/org/org-table
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-tempo hides /usr/share/emacs/30.0.50/lisp/org/org-tempo
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-timer hides /usr/share/emacs/30.0.50/lisp/org/org-timer
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-version hides /usr/share/emacs/30.0.50/lisp/org/org-version
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org hides /usr/share/emacs/30.0.50/lisp/org/org
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-ascii hides /usr/share/emacs/30.0.50/lisp/org/ox-ascii
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-beamer hides /usr/share/emacs/30.0.50/lisp/org/ox-beamer
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-html hides /usr/share/emacs/30.0.50/lisp/org/ox-html
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-icalendar hides /usr/share/emacs/30.0.50/lisp/org/ox-icalendar
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-koma-letter hides /usr/share/emacs/30.0.50/lisp/org/ox-koma-letter
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-latex hides /usr/share/emacs/30.0.50/lisp/org/ox-latex
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-man hides /usr/share/emacs/30.0.50/lisp/org/ox-man
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-md hides /usr/share/emacs/30.0.50/lisp/org/ox-md
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-odt hides /usr/share/emacs/30.0.50/lisp/org/ox-odt
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-org hides /usr/share/emacs/30.0.50/lisp/org/ox-org
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-publish hides /usr/share/emacs/30.0.50/lisp/org/ox-publish
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox-texinfo hides /usr/share/emacs/30.0.50/lisp/org/ox-texinfo
/home/st/.config/emacs/.local/straight/build-30.0.50/org/ox hides /usr/share/emacs/30.0.50/lisp/org/ox
/home/st/.config/emacs/.local/straight/build-30.0.50/org/org-loaddefs hides /usr/share/emacs/30.0.50/lisp/org/org-loaddefs
/home/st/.config/emacs/.local/straight/build-30.0.50/eldoc/eldoc hides /usr/share/emacs/30.0.50/lisp/emacs-lisp/eldoc

Features:
(shadow bbdb-message mailalias mail-extr emacsbug modus-operandi-theme
modus-vivendi-theme evil-vimish-fold hideshow moe-theme moe-dark-theme
evil-collection-help descr-text elisp-demos parrot parrot-progress
parrot-rotate evil-collection-helpful helpful cc-langs trace
evil-collection-edebug edebug info-look evil-collection-info info
help-fns evil-collection-elisp-refs elisp-refs moe-light-theme
moe-theme-autoloads loaddefs-gen radix-tree try mm-archive
network-stream url-cache finder-inf evil-collection-proced proced
cl-print evil-collection-tabulated-list evil-collection-timer-list
timer-list vertico-grid consult-imenu rng-xsd xsd-regexp rng-cmpct
nxml-mode-expansions rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap smartparens-html html-mode-expansions sgml-mode
facemenu nxml-util nxml-enc xmltok dirvish-extras org-indent image-file
image-converter oc-basic ol-bibtex bibtex vertico-buffer midnight
evil-collection-leetcode leetcode log4e spinner graphql mm-url
password-generator lorem-ipsum zone-nyan esxml zone-rainbow zone-matrix
snow flames-of-freedom fireplace dunnet bubbles evil-collection-tetris
tetris speed-type evil-collection-snake snake gamegrid neato-graph-bar
evil-collection-daemons daemons evil-collection-disk-usage disk-usage
pulseaudio-control evil-collection-trashed trashed helm-rage helm-utils
helm-help helm-linux-disks linux-disk helm-system-packages char-fold
consult-gh-embark consult-gh pdf-occur evil-collection-tablist tablist
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch
pdf-misc evil-collection-pdf pdf-history pdf-tools saveplace-pdf-view
pdf-view pdf-cache pdf-info cus-start pdf-util pdf-macs image-mode exif
gnus-srvr shell-maker evil-collection-view view goto-addr ielm greader
greader-espeak whisper org-ai org-ai-oobabooga websocket org-ai-sd
org-ai-talk org-ai-on-project org-ai-useful org-ai-openai-image
org-ai-openai org-ai-block eff vc-backup vc-hg vc-svn diff-hl-dired
dired-x diredfl gnus-dired tramp-cmds dirvish-yank dirvish-subtree
dirvish-collapse dirvish-icons dirvish-vc dirvish-widgets dirvish
helm-emms helm-adaptive emms-player-vlc emms-player-mpv
emms-player-mplayer emms-setup emms-mpris emms-librefm-stream
emms-librefm-scrobbler emms-playlist-limit emms-i18n emms-history
emms-score emms-stream-info emms-metaplaylist-mode emms-bookmarks
emms-cue emms-mode-line-icon emms-browser sort emms-volume
emms-volume-sndioctl emms-volume-mixerctl emms-volume-pulse
emms-volume-amixer emms-playlist-sort emms-last-played emms-player-xine
emms-player-mpd tq emms-playing-time emms-lyrics emms-url
emms-player-simple emms-streams emms-show-all emms-tag-editor
emms-tag-tracktag emms-mark emms-mode-line emms-cache emms-info-native
emms-info-spc emms-info-exiftool emms-info-tinytag emms-info-metaflac
emms-info-opusinfo emms-info-ogginfo emms-info-mp3info emms-info
emms-later-do emms-playlist-mode emms-source-playlist emms-source-file
locate evil-collection-emms emms emms-compat somafm request
evil-collection-mpc mpc elfeed-tube elfeed-tube-utils aio elfeed-org
evil-collection-elfeed elfeed-show elfeed-search elfeed-csv elfeed
elfeed-curl elfeed-log elfeed-db elfeed-lib url-queue xml-query empv
helm-posframe helm helm-global-bindings helm-easymenu helm-core
async-bytecomp helm-source helm-multi-match helm-lib wakatime-mode
cae-cheatsheets cal-julian circadian solar cal-dst evil-collection-vterm
vterm face-remap vterm-module term/xterm xterm zone em-rebind org-agenda
embark-org the-org-mode-expansions org-modern evil-collection-org
evil-collection-org-roam org-roam-migrate org-roam-log org-roam-mode
org-roam-capture org-roam-id org-roam-node org-roam-db
emacsql-sqlite-builtin sqlite org-roam-utils org-roam-compat org-roam
org-capture org-attach smartparens-org org-yt org-element org-persist
org-id org-refile avl-tree org org-element-ast inline ob-emacs-lisp
org-table org-loaddefs hippie-exp eshell-syntax-highlighting
fish-completion eshell-bookmark eshell-prompt-extras em-term
evil-collection-term term ehelp em-script em-pred em-ls em-hist em-glob
em-alias em-elecslash evil-collection-indent vertico-directory winum
delsel hide-mode-line gdb-mi bindat gud hydra lv flymake-cc
diff-hl-flydiff evil-textobj-tree-sitter
evil-textobj-tree-sitter-thing-at-point evil-textobj-tree-sitter-core
tree-sitter-langs tree-sitter-langs-build tree-sitter-hl ts-fold
ts-fold-summary ts-fold-parsers ts-fold-util tree-sitter
tree-sitter-load tree-sitter-cli tsc tsc-dyn tsc-dyn-get dired-aux
tsc-obsolete evil-collection-eglot eglot external-completion
evil-collection-xref xref ert evil-collection-debug debug backtrace
evil-embrace evil-surround modern-cpp-font-lock subword-mode-expansions
cap-words superword subword smart-semicolon smartparens-c
cc-mode-expansions cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs hl-line mb-depth vertico-repeat
vertico-indexed vertico-posframe posframe tramp-cache time-stamp
em-extpipe ob ob-tangle ol ob-ref ob-lob ob-table ob-exp em-cmpl
org-macro em-basic org-src org-keys oc ob-comint em-banner org-pcomplete
em-smart org-list org-footnote em-tramp org-entities eshell-did-you-mean
esh-help evil-collection-man man em-unix eshell-z em-dirs
evil-collection-eshell em-prompt eshell esh-mode esh-var eat org-faces
esh-cmd generator esh-ext esh-opt find-func esh-proc esh-io esh-arg
evil-collection-calendar cal-menu calendar cal-loaddefs esh-module
esh-groups emacsql-sqlite esh-util doom-snippets doom-snippets-lib
yasnippet projectile ibuffer-vc ibuf-ext evil-collection-ibuffer ibuffer
ibuffer-loaddefs checkdoc mule-util evil-collection-vc-git vc-git
ebuild-mode skeleton evil-collection-sh-script sh-script smie treesit
executable evil-collection-diff-hl diff-hl evil-collection-log-view
log-view evil-collection-vc-dir vc-dir ewoc vc vc-dispatcher jka-compr
auto-minor-mode disp-table whitespace git-auto-commit-mode embrace eros
nameless lisp-mnt highlight-quoted outline-minor-faces vi-tilde-fringe
display-line-numbers evil-collection-flymake flymake-proc flymake
copilot copilot-balancer jsonrpc evil-cleverparens
evil-cleverparens-text-objects evil-cleverparens-util paredit
evil-collection-elisp-mode elisp-mode corfu-history saveplace
auto-sudoedit recentf tree-widget tramp-sh tramp trampver
tramp-integration tramp-message tramp-compat xdg tramp-loaddefs
evil-collection-so-long so-long envrc inheritenv beacon vimish-fold
evil-collection-which-key which-key savehist better-jumper
vertico-multiform vertico-mouse evil-collection-vertico vertico
orderless all-the-icons-completion marginalia evil-goggles
evil-easymotion evil-snipe evil-owl repeat restore-point indent-aux aas
embark-vc evil-collection-magit-todos magit-todos pcre2el rxt re-builder
hl-todo f f-shortdoc s async evil-collection-grep grep
evil-collection-compile compile code-review code-review-actions
code-review-comment code-review-section code-review-bitbucket
code-review-faces emojify evil-collection-apropos apropos
evil-collection-tar-mode tar-mode evil-collection-arc-mode arc-mode
archive-mode ht code-review-gitlab code-review-utils
evil-collection-forge forge-list forge-commands forge-semi
forge-bitbucket buck forge-gogs gogs forge-gitea gtea forge-gitlab glab
forge-github forge-notify forge-revnote forge-pullreq forge-issue
forge-topic yaml bug-reference forge-post smartparens-markdown
evil-collection-markdown-mode markdown-mode noutline outline forge-repo
forge forge-core forge-db code-review-parse-hunk code-review-github
code-review-db uuidgen calc-misc calc-ext calc calc-loaddefs calc-macs a
code-review-interfaces deferred ghub-graphql treepy gsexp ghub url-http
url-gw nsm url-auth closql emacsql-sqlite-common emacsql
emacsql-compiler magit-bookmark magit-autoloads evil-collection-magit
magit-submodule magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
files-x magit-repos magit-apply magit-wip magit-log which-func
magit-diff smerge-mode diff evil-collection-diff-mode diff-mode
git-commit evil-collection-log-edit log-edit nice-citation gnus-cite
bbdb-gnus bbdb-mua spam spam-stat bbdb-com bbdb bbdb-site timezone
gnus-uu yenc gnus-msg gnus-registry registry eieio-base gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill
kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus
xml gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time iso8601
gnus-spec gnus-win gnus-int gnus-range evil-collection-gnus gnus
nnheader range message sendmail yank-media puny evil-collection-dired
dired dired-loaddefs rfc822 mml mml-sec evil-collection-epa epa epg
rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev
mail-utils gmm-utils mailheader pcvs-util add-log magit-core
magit-autorevert magit-margin magit-transient magit-process with-editor
shell pcomplete evil-collection-comint comint ansi-osc magit-mode
transient magit-git magit-base evil-collection-magit-section
magit-section cursor-sensor crm evil-collection-embark embark-consult
evil-collection-consult consult evil-collection-bookmark bookmark
text-property-search embark ffap gcmh winner smartparens-config
smartparens-text smartparens loadhist dash undo-fu-session undo-fu
ws-butler editorconfig evil-collection-package-menu doom-packages
ansi-color package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util mailcap url-handlers url-parse auth-source password-cache json
map url-vars editorconfig-core editorconfig-core-handle
editorconfig-fnmatch corfu-popupinfo evil-collection-corfu corfu minions
breadcrumb pulse color project evil-collection-imenu imenu yank-indent
exwm-mff autorevert filenotify time-date all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons persp-mode dtrt-indent
modus-operandi-deuteranopia-theme modus-themes define-repeat-map
expand-region-improved expand-region text-mode-expansions
er-basic-expansions expand-region-core expand-region-custom cape compat
exwm-firefox-evil exwm-firefox-core exwm-evil exwm-evil-core exwm-config
ido exwm-systemtray xcb-systemtray xcb-xembed exwm-randr xcb-randr exwm
exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor
xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb
xcb-xproto xcb-types xcb-debug eieio eieio-core server smartparens-lua
let-alist ob-core org-cycle org-fold org-fold-core org-compat ob-eval
org-version org-macs format-spec ibuf-macs evil-collection-tab-bar
evil-collection-custom cus-edit cus-load wid-edit evil-collection
annalist evil evil-integration evil-maps evil-commands reveal evil-jumps
evil-command-window evil-types evil-search evil-macros evil-repeat
evil-states evil-core advice evil-common thingatpt rect evil-vars ring
derived edmacro kmacro byte-opt use-package-bind-key bind-key easy-mmode
comp comp-cstr warnings icons rx doom-editor doom-projects doom-ui
doom-keybinds pp cl-extra help-mode use-package-core bytecomp
byte-compile general site-gentoo doom-start doom-modules cl-seq doom
doom-lib cl-macs cl-loaddefs cl-lib pcase gv harfbuzz jansson
dynamic-modules subr-x rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting font-render-setting cairo
xinput2 x multi-tty move-toolbar make-network-process native-compile
emacs)

Memory information:
((conses 16 4336492 627496) (symbols 48 130970 52) (strings 32 703427 51764)
 (string-bytes 1 24142546) (vectors 16 210228) (vector-slots 8 5200225 507435)
 (floats 8 5040 8876) (intervals 56 235148 17605) (buffers 992 57))

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

tags 65896 wishlist
thanks

> From: StrawberryTea <look@strawberrytea.xyz>
> Date: Tue, 12 Sep 2023 13:00:45 -0500
> 
> 
> Hi. This issue comes from Reddit,
> https://www.reddit.com/r/emacs/comments/v0i4js/extend_org_heading_background_face_past_the/.
> Basically, if I fold text using text properties, the heading background
> does not extend to the end of the window. To quote /u/yantar92: "This is
> because the trailing newline in the folded heading gets hidden. If the
> trailing newline is invisible, :extend t has no effect. It is Emacs
> limitation, AFAIK." It would be great if we could make the :extend
> property work with invisible text.

It cannot.  Text properties of invisible text are ignored because the
display engine skips invisible text and doesn't consider it and its
properties at all.

I'm not closing this bug in the hope that someone will have a clever
idea for how to work around this, or maybe (gasp!) even submits a
patch.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 65896 wishlist
> thanks

This seems related to bug#52587, maybe so much so that it might make
sense to merge them?  IIUC, given this Org buffer…

--8<---------------cut here---------------start------------->8---
* foo
#+begin_stuff
bar
#+end_stuff
* baz
--8<---------------cut here---------------end--------------->8---

… and folding "* foo",

* bug#52587 is about "#+end_stuff"'s :extended background "bleeding
  into" the header line,

* bug#65896 (this report) is about the header line's :extended
  background getting "cut short" once folded.

AFAIU those are two aspects of the same problem people have with
outlines: the effective :extended background comes from the last line of
the folded content (because that's the newline that is actually
displayed) whereas one might expect it to come from the header line (but
it can't, because the header line's newline is invisible).

So I'd expect addressing one report will also address the other.

>> From: StrawberryTea <look@strawberrytea.xyz>
>> Date: Tue, 12 Sep 2023 13:00:45 -0500
>> 
>> 
>> Hi. This issue comes from Reddit,
>> https://www.reddit.com/r/emacs/comments/v0i4js/extend_org_heading_background_face_past_the/.
>> Basically, if I fold text using text properties, the heading background
>> does not extend to the end of the window. To quote /u/yantar92: "This is
>> because the trailing newline in the folded heading gets hidden. If the
>> trailing newline is invisible, :extend t has no effect. It is Emacs
>> limitation, AFAIK." It would be great if we could make the :extend
>> property work with invisible text.
>
> It cannot.  Text properties of invisible text are ignored because the
> display engine skips invisible text and doesn't consider it and its
> properties at all.
>
> I'm not closing this bug in the hope that someone will have a clever
> idea for how to work around this, or maybe (gasp!) even submits a
> patch.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[LemonBreezes]

[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

This might not sound too clever, but why don't we just make the extend
property be determined by the first character in the line rather than
the last character / newline character? 

On Tue, Sep 12, 2023, at 3:51 PM, Kévin Le Gouguec wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > tags 65896 wishlist
> > thanks
> 
> This seems related to bug#52587, maybe so much so that it might make
> sense to merge them?  IIUC, given this Org buffer…
> 
> --8<---------------cut here---------------start------------->8---
> * foo
> #+begin_stuff
> bar
> #+end_stuff
> * baz
> --8<---------------cut here---------------end--------------->8---
> 
> … and folding "* foo",
> 
> * bug#52587 is about "#+end_stuff"'s :extended background "bleeding
>   into" the header line,
> 
> * bug#65896 (this report) is about the header line's :extended
>   background getting "cut short" once folded.
> 
> AFAIU those are two aspects of the same problem people have with
> outlines: the effective :extended background comes from the last line of
> the folded content (because that's the newline that is actually
> displayed) whereas one might expect it to come from the header line (but
> it can't, because the header line's newline is invisible).
> 
> So I'd expect addressing one report will also address the other.
> 
> >> From: StrawberryTea <look@strawberrytea.xyz>
> >> Date: Tue, 12 Sep 2023 13:00:45 -0500
> >> 
> >> 
> >> Hi. This issue comes from Reddit,
> >> https://www.reddit.com/r/emacs/comments/v0i4js/extend_org_heading_background_face_past_the/.
> >> Basically, if I fold text using text properties, the heading background
> >> does not extend to the end of the window. To quote /u/yantar92: "This is
> >> because the trailing newline in the folded heading gets hidden. If the
> >> trailing newline is invisible, :extend t has no effect. It is Emacs
> >> limitation, AFAIK." It would be great if we could make the :extend
> >> property work with invisible text.
> >
> > It cannot.  Text properties of invisible text are ignored because the
> > display engine skips invisible text and doesn't consider it and its
> > properties at all.
> >
> > I'm not closing this bug in the hope that someone will have a clever
> > idea for how to work around this, or maybe (gasp!) even submits a
> > patch.
> 

[-- Attachment #2: Type: text/html, Size: 3558 bytes --]

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

merge 
> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: StrawberryTea <look@strawberrytea.xyz>,  65896@debbugs.gnu.org
> Date: Tue, 12 Sep 2023 22:51:53 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > tags 65896 wishlist
> > thanks
> 
> This seems related to bug#52587, maybe so much so that it might make
> sense to merge them?

Probably, but I'll leave this to debbugs gurus, as the two bugs have
different attributes.

> AFAIU those are two aspects of the same problem people have with
> outlines: the effective :extended background comes from the last line of
> the folded content (because that's the newline that is actually
> displayed) whereas one might expect it to come from the header line (but
> it can't, because the header line's newline is invisible).

More accurately, if the last character displayed on a line has a face
with :extend attribute non-nil, that face is extended to the edge of
the window.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> Date: Tue, 12 Sep 2023 16:35:16 -0500
> From: LemonBreezes <look@strawberrytea.xyz>
> Cc: 65896@debbugs.gnu.org
> 
> This might not sound too clever, but why don't we just make the extend
> property be determined by the first character in the line rather than
> the last character / newline character? 

How can Emacs know, when it processes the first character on a line,
whether the last character on that line will have the same face?

You seem to assume that the Emacs display engine has "global" view of
the line it is processing for display.  But that's not what happens:
the Emacs display is basically a one-pass layout engine whose view of
the text is a peephole whose size is a single character.  The display
engine processes a character, makes all the decisions regarding its
display and layout, then proceeds to the next one, and so on.  When it
gets to the newline that ends a line, it makes the decision whether
the last face it saw needs to be extended, and if so, extends it.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> This might not sound too clever, but why don't we just make the extend
>> property be determined by the first character in the line rather than
>> the last character / newline character? 
>
> How can Emacs know, when it processes the first character on a line,
> whether the last character on that line will have the same face?
>
> You seem to assume that the Emacs display engine has "global" view of
> the line it is processing for display.  But that's not what happens:
> the Emacs display is basically a one-pass layout engine whose view of
> the text is a peephole whose size is a single character.  The display
> engine processes a character, makes all the decisions regarding its
> display and layout, then proceeds to the next one, and so on.  When it
> gets to the newline that ends a line, it makes the decision whether
> the last face it saw needs to be extended, and if so, extends it.

Are you sure? I am looking at `extend_face_to_end_of_line' and it looks
like there is nothing preventing it from accessing it->glyph_row->glyphs
array to look backwards into preceding glyphs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: LemonBreezes <look@strawberrytea.xyz>, 65896@debbugs.gnu.org,
>  kevin.legouguec@gmail.com
> Date: Wed, 20 Sep 2023 12:50:08 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This might not sound too clever, but why don't we just make the extend
> >> property be determined by the first character in the line rather than
> >> the last character / newline character? 
> >
> > How can Emacs know, when it processes the first character on a line,
> > whether the last character on that line will have the same face?
> >
> > You seem to assume that the Emacs display engine has "global" view of
> > the line it is processing for display.  But that's not what happens:
> > the Emacs display is basically a one-pass layout engine whose view of
> > the text is a peephole whose size is a single character.  The display
> > engine processes a character, makes all the decisions regarding its
> > display and layout, then proceeds to the next one, and so on.  When it
> > gets to the newline that ends a line, it makes the decision whether
> > the last face it saw needs to be extended, and if so, extends it.
> 
> Are you sure? I am looking at `extend_face_to_end_of_line' and it looks
> like there is nothing preventing it from accessing it->glyph_row->glyphs
> array to look backwards into preceding glyphs.

First, glyphs have only partial information about the original face
properties.  IOW, the produced glyph row doesn't have all the info
that the original text had.

And second, I don't see how the accessibility to the glyphs is
relevant to the issue at hand.  Suppose the visible text of a line is:

   aaabbbbxxx

where each letter represents some character with different face -- you
want Emacs to extend face 'a' after the end of the line, not the face
'x', just because the line started with characters whose face was
'a'?? that's what the OP said, AFAIU.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: LemonBreezes <look@strawberrytea.xyz>, 65896@debbugs.gnu.org,
>  kevin.legouguec@gmail.com
> Date: Wed, 20 Sep 2023 12:50:08 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This might not sound too clever, but why don't we just make the extend
> >> property be determined by the first character in the line rather than
> >> the last character / newline character? 
> >
> > How can Emacs know, when it processes the first character on a line,
> > whether the last character on that line will have the same face?
> >
> > You seem to assume that the Emacs display engine has "global" view of
> > the line it is processing for display.  But that's not what happens:
> > the Emacs display is basically a one-pass layout engine whose view of
> > the text is a peephole whose size is a single character.  The display
> > engine processes a character, makes all the decisions regarding its
> > display and layout, then proceeds to the next one, and so on.  When it
> > gets to the newline that ends a line, it makes the decision whether
> > the last face it saw needs to be extended, and if so, extends it.
> 
> Are you sure? I am looking at `extend_face_to_end_of_line' and it looks
> like there is nothing preventing it from accessing it->glyph_row->glyphs
> array to look backwards into preceding glyphs.

First, glyphs have only partial information about the original face
properties.  IOW, the produced glyph row doesn't have all the info
that the original text had.

And second, I don't see how the accessibility to the glyphs is
relevant to the issue at hand.  Suppose the visible text of a line is:

   aaabbbbxxx

where each letter represents some character with different face -- you
want Emacs to extend face 'a' after the end of the line, not the face
'x', just because the line started with characters whose face was
'a'?? that's what the OP said, AFAIU.  I cannot see how this proposal
could be TRT.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>                                        I cannot see how this proposal
> could be TRT.

Yeah, I believe there should be ways to scratch that itch without going
all the way down to the display engine.

FWIW, I would invite motivated hackers to check out magit-section and
see if outline-mode could be taught a new "folding style" that would use
the same folding principles.  My own wandering through the EIEIO maze
has been too brief to yield anything useful, but AFAICT the salient
points are:

* setting the 'invisible overlay's BEG at the start of the "section
body" (after the heading's newline),

* storing bookkeeping information (such as this beginning position) in a
'magit-section property applied to the heading, so that
magit-section-show can retrieve that information when invoked by the
user with point on that heading.

I would imagine outline.el could grow a user option to adjust overlay
boundaries this way, so the heading's newline would remain visible, and
so would any :extend property on that newline… although perhaps I'm
missing some key differences between outline-mode and magit-section-mode
that may derail this train of thought.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Juri Linkov]

>> I cannot see how this proposal could be TRT.
>
> Yeah, I believe there should be ways to scratch that itch without going
> all the way down to the display engine.
>
> FWIW, I would invite motivated hackers to check out magit-section and
> see if outline-mode could be taught a new "folding style" that would use
> the same folding principles.  My own wandering through the EIEIO maze
> has been too brief to yield anything useful, but AFAICT the salient
> points are:
>
> * setting the 'invisible overlay's BEG at the start of the "section
> body" (after the heading's newline),
>
> * storing bookkeeping information (such as this beginning position) in a
> 'magit-section property applied to the heading, so that
> magit-section-show can retrieve that information when invoked by the
> user with point on that heading.
>
> I would imagine outline.el could grow a user option to adjust overlay
> boundaries this way, so the heading's newline would remain visible, and
> so would any :extend property on that newline… although perhaps I'm
> missing some key differences between outline-mode and magit-section-mode
> that may derail this train of thought.

I tried, but the conclusion was that this requires changes in the display engine.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Ihor Radchenko <yantar92@posteo.net>,
>   65896@debbugs.gnu.org,  look@strawberrytea.xyz
> Date: Fri, 22 Sep 2023 09:40:42 +0300
> 
> > I would imagine outline.el could grow a user option to adjust overlay
> > boundaries this way, so the heading's newline would remain visible, and
> > so would any :extend property on that newline… although perhaps I'm
> > missing some key differences between outline-mode and magit-section-mode
> > that may derail this train of thought.
> 
> I tried, but the conclusion was that this requires changes in the display engine.

For any changes in this area to be done in the display engine, someone
will have to come up with a coherent proposal that will:

  . make sense from the Lisp programmer's POV
  . support well both the case of invisible text and the case of no
    invisible text, without asking the display code to jump through
    too many hoops in any of these cases
  . be consistent with the current handling of faces in the display
    code, which basically decides on the face where it changes, and
    then keeps using that face until the next face change

Ideas and suggestions that satisfy the above conditions are welcome.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Are you sure? I am looking at `extend_face_to_end_of_line' and it looks
>> like there is nothing preventing it from accessing it->glyph_row->glyphs
>> array to look backwards into preceding glyphs.
>
> First, glyphs have only partial information about the original face
> properties.  IOW, the produced glyph row doesn't have all the info
> that the original text had.
>
> And second, I don't see how the accessibility to the glyphs is
> relevant to the issue at hand.  Suppose the visible text of a line is:
>
>    aaabbbbxxx
>
> where each letter represents some character with different face -- you
> want Emacs to extend face 'a' after the end of the line, not the face
> 'x', just because the line started with characters whose face was
> 'a'?? that's what the OP said, AFAIU.

I am also not a big fan of using the first glyph/letter in the line.

What about not extending the face unless the last 2 glyphs have eq face
or we have a single glyph in a row?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: look@strawberrytea.xyz, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
> Date: Fri, 22 Sep 2023 10:12:57 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Are you sure? I am looking at `extend_face_to_end_of_line' and it looks
> >> like there is nothing preventing it from accessing it->glyph_row->glyphs
> >> array to look backwards into preceding glyphs.
> >
> > First, glyphs have only partial information about the original face
> > properties.  IOW, the produced glyph row doesn't have all the info
> > that the original text had.
> >
> > And second, I don't see how the accessibility to the glyphs is
> > relevant to the issue at hand.  Suppose the visible text of a line is:
> >
> >    aaabbbbxxx
> >
> > where each letter represents some character with different face -- you
> > want Emacs to extend face 'a' after the end of the line, not the face
> > 'x', just because the line started with characters whose face was
> > 'a'?? that's what the OP said, AFAIU.
> 
> I am also not a big fan of using the first glyph/letter in the line.
> 
> What about not extending the face unless the last 2 glyphs have eq face
> or we have a single glyph in a row?

That's a backward-incompatible change, so we cannot do that.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> What about not extending the face unless the last 2 glyphs have eq face
>> or we have a single glyph in a row?
>
> That's a backward-incompatible change, so we cannot do that.

Then, what about doing this only when :extend attribute is set to number
2?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: look@strawberrytea.xyz, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
> Date: Fri, 22 Sep 2023 12:00:14 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> What about not extending the face unless the last 2 glyphs have eq face
> >> or we have a single glyph in a row?
> >
> > That's a backward-incompatible change, so we cannot do that.
> 
> Then, what about doing this only when :extend attribute is set to number
> 2?

That'd mean quite a few changes (since currently :extend is a boolean
attribute), but okay.

However, what is the detailed description of the behavior under this
proposal?  I mean, which 2 glyphs to consider? the last two shown on
the screen line?  If so, this will cause the same problems when these
two glyphs come from different buffer lines (due to invisibility), no?
IOW, won't that cause the same surprising effects, just in other
situations?

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> However, what is the detailed description of the behavior under this
> proposal?  I mean, which 2 glyphs to consider? the last two shown on
> the screen line?  If so, this will cause the same problems when these
> two glyphs come from different buffer lines (due to invisibility), no?
> IOW, won't that cause the same surprising effects, just in other
> situations?

You are right. If the visible part of the line has :extend already, it
would make more sense to extend the face:

<visible text :extend t><ellipsis><newline :extend t>

The discussed issue corresponds to the following line structure:

<visible text :extend nil><ellipsis :extend nil><newline :extend t>

IMHO, <newline> after invisible text should simply inherit the face of
previous glyph (from ellipsis, if ellipsis is visible; or from visible
text, if invisible text is completely hidden) to get the expected look.

Does it make more sense.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: look@strawberrytea.xyz, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
> Date: Sat, 23 Sep 2023 10:51:22 +0000
> 
> You are right. If the visible part of the line has :extend already, it
> would make more sense to extend the face:
> 
> <visible text :extend t><ellipsis><newline :extend t>
> 
> The discussed issue corresponds to the following line structure:
> 
> <visible text :extend nil><ellipsis :extend nil><newline :extend t>
> 
> IMHO, <newline> after invisible text should simply inherit the face of
> previous glyph (from ellipsis, if ellipsis is visible; or from visible
> text, if invisible text is completely hidden) to get the expected look.

AFAICT, this should already happen.

I think I need a simple recipe to reproduce the problem and see more
closely what is going on in that recipe.  I tried the one at the
beginning of this bug, but couldn't reproduce, probably because I'm
missing something.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: look@strawberrytea.xyz, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
> Date: Sat, 23 Sep 2023 11:19:32 +0000
> 
> 1. emacs -Q
> 2. M-x org-mode
> 3. M-: (set-face-background 'org-block-end-line "lightblue")
> 4. Insert
> * Heading
> #+begin_src emacs-lisp
> 1
> #+end_src
> * Another heading
> 5. S-<TAB>
> 6. Observe * Heading...<blue background>

It's because the invisible text does not include the newline of the
#+end_src line, and that newline has the face you don't want to see.

If we ignore the face of the newline itself, we will change the
behavior when the last glyph before the newline has a different face.
The most notable use case is:

  . C-e
  . C-SPC
  . C-f

This is expected to paint with the region face the part between the
last glyph of the current line and the first glyph of the next line,
but with your proposal will not.  IOW, the region face will
effectively not be extended in this case.

Why cannot Org include in the invisible text the newline of the last
line that is being hidden?  That is, in the above scenario, make the
invisible text begin with the first character of "#+begin_src" and end
after the newline following "#+end_src".

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 1. emacs -Q
> ...
> It's because the invisible text does not include the newline of the
> #+end_src line, and that newline has the face you don't want to see.
>
> If we ignore the face of the newline itself, we will change the
> behavior when the last glyph before the newline has a different face.
> The most notable use case is:
>
>   . C-e
>   . C-SPC
>   . C-f
>
> This is expected to paint with the region face the part between the
> last glyph of the current line and the first glyph of the next line,
> but with your proposal will not.  IOW, the region face will
> effectively not be extended in this case.

I see. Note that there is a similar case when the region is not
displayed at all:

* Folded heading<point>...

. C-SPC
. C-f
(observe ellipsis not being highlighted)

> Why cannot Org include in the invisible text the newline of the last
> line that is being hidden?  That is, in the above scenario, make the
> invisible text begin with the first character of "#+begin_src" and end
> after the newline following "#+end_src".

That will make ellipsis displayed on the same line with the next heading:

* Heading
...* Another heading

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: look@strawberrytea.xyz, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
> Date: Sat, 23 Sep 2023 12:59:32 +0000
> 
> Note that there is a similar case when the region is not
> displayed at all:
> 
> * Folded heading<point>...
> 
> . C-SPC
> . C-f
> (observe ellipsis not being highlighted)

That's a feature: we ignore faces of invisible text, which I think is
the expected behavior

> > Why cannot Org include in the invisible text the newline of the last
> > line that is being hidden?  That is, in the above scenario, make the
> > invisible text begin with the first character of "#+begin_src" and end
> > after the newline following "#+end_src".
> 
> That will make ellipsis displayed on the same line with the next heading:
> 
> * Heading
> ...* Another heading

And "* Another heading" cannot have an extra newline before it?

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Note that there is a similar case when the region is not
>> displayed at all:
>> 
>> * Folded heading<point>...
>> 
>> . C-SPC
>> . C-f
>> (observe ellipsis not being highlighted)
>
> That's a feature: we ignore faces of invisible text, which I think is
> the expected behavior

I do not agree that it is expected. There is basically no way to
distinguish between

* Heading<region beginning><folded text>
<region end>

and

* Heading<folded text><region-beginning>
<region-end>

That said, your example indeed demonstrated that my suggestion would
cause feature regression. Although, IMHO, not severe one, as
demonstrated by the above example.

>> > Why cannot Org include in the invisible text the newline of the last
>> > line that is being hidden?  That is, in the above scenario, make the
>> > invisible text begin with the first character of "#+begin_src" and end
>> > after the newline following "#+end_src".
>> 
>> That will make ellipsis displayed on the same line with the next heading:
>> 
>> * Heading
>> ...* Another heading
>
> And "* Another heading" cannot have an extra newline before it?

It can, but does not have to. And the problem with face :extend Org
users experience usually happens when there is no extra newline.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

I’m using this (<https://0x0.st/HViT.txt>) init.el to debug redisplay with:
cgdb –args ./emacs -q -l ./init.el

I still haven’t figured out how to fix this but that init works fine. It doesn’t
matter that it loads all of Org mode since we’re just looking at the display.

Ihor Radchenko <yantar92@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Note that there is a similar case when the region is not
>>> displayed at all:
>>>
>>> * Folded heading<point>…
>>>
>>> . C-SPC
>>> . C-f
>>> (observe ellipsis not being highlighted)
>>
>> That’s a feature: we ignore faces of invisible text, which I think is
>> the expected behavior
>
> I do not agree that it is expected. There is basically no way to
> distinguish between
>
> * Heading<region beginning><folded text>
> <region end>
>
> and
>
> * Heading<folded text><region-beginning>
> <region-end>
>
> That said, your example indeed demonstrated that my suggestion would
> cause feature regression. Although, IMHO, not severe one, as
> demonstrated by the above example.
>
>>> > Why cannot Org include in the invisible text the newline of the last
>>> > line that is being hidden?  That is, in the above scenario, make the
>>> > invisible text begin with the first character of “#+begin_src” and end
>>> > after the newline following “#+end_src”.
>>>
>>> That will make ellipsis displayed on the same line with the next heading:
>>>
>>> * Heading
>>> …* Another heading
>>
>> And “* Another heading” cannot have an extra newline before it?
>
> It can, but does not have to. And the problem with face :extend Org
> users experience usually happens when there is no extra newline.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: StrawberryTea <look@strawberrytea.xyz>
> Cc: Eli Zaretskii <eliz@gnu.org>, 65896@debbugs.gnu.org,
>  kevin.legouguec@gmail.com
> Date: Sat, 23 Sep 2023 13:33:05 -0500
> 
> I’m using this (<https://0x0.st/HViT.txt>) init.el to debug redisplay with:
> cgdb –args ./emacs -q -l ./init.el
> 
> I still haven’t figured out how to fix this but that init works fine. It doesn’t
> matter that it loads all of Org mode since we’re just looking at the display.

Thanks, but I don't think I understand what you are saying.  If the
init file works fine, then what do you need to fix?  And how is the
init file related to the issue at hand?

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

What I’m saying is that, I start up GDB and I set a breakpoint on Frecenter and
step into display_line, I can see the glyph row and how all the characters in
the folded heading have the heading except the newline character at the end. And
I would like for in this specific scenario, the face on the ellipsis to be used
(since it has extend) instead of the face on the newline which is the default
face. But I don’t know how to make that modification to the code yet.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: StrawberryTea <look@strawberrytea.xyz>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 65896@debbugs.gnu.org,
>>  kevin.legouguec@gmail.com
>> Date: Sat, 23 Sep 2023 13:33:05 -0500
>>
>> I’m using this (<https://0x0.st/HViT.txt>) init.el to debug redisplay with:
>> cgdb –args ./emacs -q -l ./init.el
>>
>> I still haven’t figured out how to fix this but that init works fine. It doesn’t
>> matter that it loads all of Org mode since we’re just looking at the display.
>
> Thanks, but I don’t think I understand what you are saying.  If the
> init file works fine, then what do you need to fix?  And how is the
> init file related to the issue at hand?

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: StrawberryTea <look@strawberrytea.xyz>
> Cc: yantar92@posteo.net, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
> Date: Sat, 23 Sep 2023 14:05:53 -0500
> 
> What I’m saying is that, I start up GDB and I set a breakpoint on Frecenter and
> step into display_line, I can see the glyph row and how all the characters in
> the folded heading have the heading except the newline character at the end. And
> I would like for in this specific scenario, the face on the ellipsis to be used
> (since it has extend) instead of the face on the newline which is the default
> face. But I don’t know how to make that modification to the code yet.

How will this behavior be limited to the case of folded text?  Because
when the text between the ellipsis and the newline is not invisible,
the face of the newline should still be used, otherwise we will have
an unacceptable change in behavior in the "normal" cases, when there's
no invisible folded text.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

I finally figured it out. This can be resolved with a small Elisp advice:

(advice-add #’org-fold-core-region :around #’cae-org-fold-region-a)
(defun cae-org-fold-region-a (oldfun from to flag &optional spec-or-alias)
  (if (and (eq to (point-max)) flag)
      (setq to (1- to)))
  (funcall oldfun from to flag spec-or-alias)
  (remove-overlays from (1+ to) ’cae-org-fold-heading t)
  (when flag
    (let ((o (make-overlay to (1+ to) nil ’front-advance)))
      (overlay-put o ’evaporate t)
      (overlay-put o ’cae-org-fold-heading t)
      (overlay-put o ’face
                   (save-excursion (goto-char from)
                                   (face-at-point)))
      (overlay-put o ’display “\n”))))

I modeled the code after the Backline package which does the same thing for
Outline, which uses overlays. I’m thinking now that we should not patch the
display engine.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: StrawberryTea <look@strawberrytea.xyz>
>> Cc: yantar92@posteo.net, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
>> Date: Sat, 23 Sep 2023 14:05:53 -0500
>>
>> What I’m saying is that, I start up GDB and I set a breakpoint on Frecenter and
>> step into display_line, I can see the glyph row and how all the characters in
>> the folded heading have the heading except the newline character at the end. And
>> I would like for in this specific scenario, the face on the ellipsis to be used
>> (since it has extend) instead of the face on the newline which is the default
>> face. But I don’t know how to make that modification to the code yet.
>
> How will this behavior be limited to the case of folded text?  Because
> when the text between the ellipsis and the newline is not invisible,
> the face of the newline should still be used, otherwise we will have
> an unacceptable change in behavior in the “normal” cases, when there’s
> no invisible folded text.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

StrawberryTea <look@strawberrytea.xyz> writes:

>       (overlay-put o ’evaporate t)
>       (overlay-put o ’cae-org-fold-heading t)
>       (overlay-put o ’face
>                    (save-excursion (goto-char from)
>                                    (face-at-point)))
>       (overlay-put o ’display “\n”))))

This has a potential to break a number of things, because the text under
the fold will no longer be considered invisible.

Also, ellipsis will not be obeyed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 65896@debbugs.gnu.org,
>  kevin.legouguec@gmail.com
> Date: Sun, 24 Sep 2023 10:19:11 +0000
> 
> StrawberryTea <look@strawberrytea.xyz> writes:
> 
> >       (overlay-put o ’evaporate t)
> >       (overlay-put o ’cae-org-fold-heading t)
> >       (overlay-put o ’face
> >                    (save-excursion (goto-char from)
> >                                    (face-at-point)))
> >       (overlay-put o ’display “\n”))))
> 
> This has a potential to break a number of things, because the text under
> the fold will no longer be considered invisible.
> 
> Also, ellipsis will not be obeyed.

But the idea to use a display string which is "\n" could still be
useful, to help with the problem you pointed out in response to my
previous suggestion, no?

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

Exactly. It turns out my code breaks when there are nested headings so an Elisp
solution would have to be more complicated. Currently, if the extension property
is on a non-newline character, it does nothing. So a first approach would be
face_at_buffer_position look back one character if the current character does
not have the extend property.

But I’m thinking that we should be able to fontify the ellipsis without extend
and the heading with the extend property should override the background of the
other faces on the same line (even the ellipsis).

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 65896@debbugs.gnu.org,
>>  kevin.legouguec@gmail.com
>> Date: Sun, 24 Sep 2023 10:19:11 +0000
>>
>> StrawberryTea <look@strawberrytea.xyz> writes:
>>
>> >       (overlay-put o ’evaporate t)
>> >       (overlay-put o ’cae-org-fold-heading t)
>> >       (overlay-put o ’face
>> >                    (save-excursion (goto-char from)
>> >                                    (face-at-point)))
>> >       (overlay-put o ’display “\n”))))
>>
>> This has a potential to break a number of things, because the text under
>> the fold will no longer be considered invisible.
>>
>> Also, ellipsis will not be obeyed.
>
> But the idea to use a display string which is “\n” could still be
> useful, to help with the problem you pointed out in response to my
> previous suggestion, no?

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: StrawberryTea <look@strawberrytea.xyz>
> Cc: Ihor Radchenko <yantar92@posteo.net>, 65896@debbugs.gnu.org,
>  kevin.legouguec@gmail.com
> Date: Sun, 24 Sep 2023 13:30:33 -0500
> 
> But I’m thinking that we should be able to fontify the ellipsis without extend
> and the heading with the extend property should override the background of the
> other faces on the same line (even the ellipsis).

Please keep in mind that AFAIR the way the display engine is
implemented, the ellipsis is displayed with the face of the preceding
visible text, ignoring the face of the invisible text for which it
stands.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> >       (overlay-put o ’display “\n”))))
>> 
>> This has a potential to break a number of things, because the text under
>> the fold will no longer be considered invisible.
>> 
>> Also, ellipsis will not be obeyed.
>
> But the idea to use a display string which is "\n" could still be
> useful, to help with the problem you pointed out in response to my
> previous suggestion, no?

As a workaround, maybe. However, the amount of code changes to support
folding/unfolding not only of invisible text, but also extra 'display
overlays will not be worth it just to address this issue.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: look@strawberrytea.xyz, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
> Date: Tue, 26 Sep 2023 08:18:50 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >       (overlay-put o ’display “\n”))))
> >> 
> >> This has a potential to break a number of things, because the text under
> >> the fold will no longer be considered invisible.
> >> 
> >> Also, ellipsis will not be obeyed.
> >
> > But the idea to use a display string which is "\n" could still be
> > useful, to help with the problem you pointed out in response to my
> > previous suggestion, no?
> 
> As a workaround, maybe. However, the amount of code changes to support
> folding/unfolding not only of invisible text, but also extra 'display
> overlays will not be worth it just to address this issue.

Given the amount of discussions of this issue, I would have thought it
was important enough to go out of our way to solve it, but maybe I'm
missing something.  It's your call, obviously.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Kévin Le Gouguec]

Juri Linkov <juri@linkov.net> writes:

>> FWIW, I would invite motivated hackers to check out magit-section and
>> see if outline-mode could be taught a new "folding style" that would use
>> the same folding principles.  My own wandering through the EIEIO maze
>> has been too brief to yield anything useful, but AFAICT the salient
>> points are:
>>
>> * setting the 'invisible overlay's BEG at the start of the "section
>> body" (after the heading's newline),
>>
>> * storing bookkeeping information (such as this beginning position) in a
>> 'magit-section property applied to the heading, so that
>> magit-section-show can retrieve that information when invoked by the
>> user with point on that heading.
>>
>> I would imagine outline.el could grow a user option to adjust overlay
>> boundaries this way, so the heading's newline would remain visible, and
>> so would any :extend property on that newline… although perhaps I'm
>> missing some key differences between outline-mode and magit-section-mode
>> that may derail this train of thought.
>
> I tried, but the conclusion was that this requires changes in the display engine.

Could you expand on what exactly you tried, and what limitations you
faced?  (Apologies if you went over this somewhere else and I missed it)

My point was that magit-section exists right now, with no changes to the
display engine, with the exact feature set of outline.el *and* the
ability to keep heading faces extended after folding sections.  So,
unless I've missed a crucial difference between the two libraries, I
don't see why outline.el could not "learn new tricks".

(FWIW magit-section advertises itself as "sections for read-only
buffers", but if there's something in there that could not be made to
work for writable buffers, I have not found it yet)

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Juri Linkov]

>> I tried, but the conclusion was that this requires changes in the display engine.
>
> Could you expand on what exactly you tried, and what limitations you
> faced?  (Apologies if you went over this somewhere else and I missed it)

Sorry, I don't remember the details, have to reread previous threads,
maybe this is already possible without changes in the display engine.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Basically, it’s always possible to overlay the newline after a fold or shorten
the fold by one character and overlay a newline for the last character then set
a face and extend property for that newline. But even with this, when the last
character in the buffer is not a newline and has the extend property, its face
is not extended and there is no character after to coerce into a newline.

What I think could be an alternative to adding all these overlays is a change on
the display engine side so that the extend property on a character extends its
face background regardless of whether it’s a newline character.

Juri Linkov <juri@linkov.net> writes:

>>> I tried, but the conclusion was that this requires changes in the display engine.
>>
>> Could you expand on what exactly you tried, and what limitations you
>> faced?  (Apologies if you went over this somewhere else and I missed it)
>
> Sorry, I don’t remember the details, have to reread previous threads,
> maybe this is already possible without changes in the display engine.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: StrawberryTea <look@strawberrytea.xyz>
> Cc: Kévin Le Gouguec <kevin.legouguec@gmail.com>, Eli
>  Zaretskii
>  <eliz@gnu.org>, 65896@debbugs.gnu.org, Ihor Radchenko
>  <yantar92@posteo.net>
> Date: Fri, 29 Sep 2023 14:07:17 -0500
> 
> Basically, it’s always possible to overlay the newline after a fold or shorten
> the fold by one character and overlay a newline for the last character then set
> a face and extend property for that newline.

Sorry, I don't think I follow.  Could you please show some example of
this, perhaps with "ASCII art"?  What do you mean by "overlay the
newline", and what is "the fold" in this context?

> What I think could be an alternative to adding all these overlays is a change on
> the display engine side so that the extend property on a character extends its
> face background regardless of whether it’s a newline character.

That is a non-starter, since there's no text in that part.  We don't
show any parts of the text area with any face unless that part is "in
the middle of text", and the part after EOB isn't.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 2574 bytes --]

Basically, I want to be able to do this in Org mode:
<https://pasteboard.co/E17ioBts7HTl.png>

So I want a way to extend the heading background even when the heading is
folded. Currently this works when there are no nested headings:

(advice-add #’org-fold-core-region :around #’cae-org-fold-region-a)
(defun cae-org-fold-region-a (oldfun from to flag &optional spec-or-alias)
  (let ((shift-fold-p (and (eq to (point-max)) (not (eq from to)) flag)))
    (when shift-fold-p
      (setq to (1- to)))
    (funcall oldfun from to flag spec-or-alias)
    (remove-overlays from (1+ to) ’cae-org-fold-heading t)
    (when flag
      (let ((o (make-overlay to (1+ to) nil ’front-advance)))
        (overlay-put o ’evaporate t)
        (overlay-put o ’cae-org-fold-heading t)
        (overlay-put o ’face (save-excursion (goto-char from) (face-at-point)))
        (when shift-fold-p
          (overlay-put o ’display “\n”))))))

Basically, when the text is folded, it uses the face of the first visible
newline after the fold to determine the background.

The elisp approach is to maintain overlays at the end of each folded region and
it becomes complicated with nested headings. I was thinking that instead, we
could have the extend property (or an extra option on :extend) be used within
the line to colorize the background of the newline at the end.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: StrawberryTea <look@strawberrytea.xyz>
>> Cc: Kévin Le Gouguec <kevin.legouguec@gmail.com>, Eli
>>  Zaretskii
>>  <eliz@gnu.org>, 65896@debbugs.gnu.org, Ihor Radchenko
>>  <yantar92@posteo.net>
>> Date: Fri, 29 Sep 2023 14:07:17 -0500
>>
>> Basically, it’s always possible to overlay the newline after a fold or shorten
>> the fold by one character and overlay a newline for the last character then set
>> a face and extend property for that newline.
>
> Sorry, I don’t think I follow.  Could you please show some example of
> this, perhaps with “ASCII art”?  What do you mean by “overlay the
> newline”, and what is “the fold” in this context?
>
>> What I think could be an alternative to adding all these overlays is a change on
>> the display engine side so that the extend property on a character extends its
>> face background regardless of whether it’s a newline character.
>
> That is a non-starter, since there’s no text in that part.  We don’t
> show any parts of the text area with any face unless that part is “in
> the middle of text”, and the part after EOB isn’t.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: StrawberryTea <look@strawberrytea.xyz>
> Cc: juri@linkov.net, kevin.legouguec@gmail.com, 65896@debbugs.gnu.org,
>  yantar92@posteo.net
> Date: Sat, 30 Sep 2023 17:55:27 -0500
> 
> Basically, when the text is folded, it uses the face of the first visible
> newline after the fold to determine the background.
> 
> The elisp approach is to maintain overlays at the end of each folded region and
> it becomes complicated with nested headings. I was thinking that instead, we
> could have the extend property (or an extra option on :extend) be used within
> the line to colorize the background of the newline at the end.

Sorry, I still don't understand what you mean by the last sentence.
(All the rest is understood, but it describes the current situation,
which I understand well enough to not need any explanations.)

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

Sure. Basically, I want :extend to apply to a line with a folded region even
though the newline at the end itself does not have the :extend property. So I
want the extend property to somehow propagate across a line to the newline at
the end, even if it does not have the :extend property. This would allow for
:extend to work as expected when we have a a folded region that extends across
multiple lines but the end of the folded region does not have the :extend
property.

I don’t think this would cause unexpected behavior since :extend on non-newline
characters is currently a no-op.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: StrawberryTea <look@strawberrytea.xyz>
>> Cc: juri@linkov.net, kevin.legouguec@gmail.com, 65896@debbugs.gnu.org,
>>  yantar92@posteo.net
>> Date: Sat, 30 Sep 2023 17:55:27 -0500
>>
>> Basically, when the text is folded, it uses the face of the first visible
>> newline after the fold to determine the background.
>>
>> The elisp approach is to maintain overlays at the end of each folded region and
>> it becomes complicated with nested headings. I was thinking that instead, we
>> could have the extend property (or an extra option on :extend) be used within
>> the line to colorize the background of the newline at the end.
>
> Sorry, I still don’t understand what you mean by the last sentence.
> (All the rest is understood, but it describes the current situation,
> which I understand well enough to not need any explanations.)

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Eli Zaretskii]

> From: StrawberryTea <look@strawberrytea.xyz>
> Cc: juri@linkov.net, kevin.legouguec@gmail.com, 65896@debbugs.gnu.org,
>  yantar92@posteo.net
> Date: Sun, 01 Oct 2023 23:28:55 -0500
> 
> Sure. Basically, I want :extend to apply to a line with a folded region even
> though the newline at the end itself does not have the :extend property. So I
> want the extend property to somehow propagate across a line to the newline at
> the end, even if it does not have the :extend property. This would allow for
> :extend to work as expected when we have a a folded region that extends across
> multiple lines but the end of the folded region does not have the :extend
> property.

You say "propagate the :extend property", but you really mean
"propagate the face", right?  Because propagating :extend alone might
then show the wrong face extended, as the newline might have a
different face.

Anyway, this kind of thing can be easily done by the command that
folds the text: it could place a face with a suitably computed :extend
attribute on that newline.  Right?

Changing the display engine to do something like that will be much
harder, or even impossible, since the display engine currently
basically ignores the faces of invisible text, and the case of folded
text is not special in any way from the POV of the display engine.  So
making such a change will likely produce incompatible behavior changes
in other cases.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[StrawberryTea]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

Okay. I have posted the code from earlier in the Backline package’s issue
tracker so hopefully I or someone else will pick up on this Elisp solution and
improve it down the road and get it into Backline, then eventually Org and/or
Outline.
Eli Zaretskii <eliz@gnu.org> writes:

>> From: StrawberryTea <look@strawberrytea.xyz>
>> Cc: juri@linkov.net, kevin.legouguec@gmail.com, 65896@debbugs.gnu.org,
>>  yantar92@posteo.net
>> Date: Sun, 01 Oct 2023 23:28:55 -0500
>>
>> Sure. Basically, I want :extend to apply to a line with a folded region even
>> though the newline at the end itself does not have the :extend property. So I
>> want the extend property to somehow propagate across a line to the newline at
>> the end, even if it does not have the :extend property. This would allow for
>> :extend to work as expected when we have a a folded region that extends across
>> multiple lines but the end of the folded region does not have the :extend
>> property.
>
> You say “propagate the :extend property”, but you really mean
> “propagate the face”, right?  Because propagating :extend alone might
> then show the wrong face extended, as the newline might have a
> different face.
>
> Anyway, this kind of thing can be easily done by the command that
> folds the text: it could place a face with a suitably computed :extend
> attribute on that newline.  Right?
>
> Changing the display engine to do something like that will be much
> harder, or even impossible, since the display engine currently
> basically ignores the faces of invisible text, and the case of folded
> text is not special in any way from the POV of the display engine.  So
> making such a change will likely produce incompatible behavior changes
> in other cases.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

>> But the idea to use a display string which is "\n" could still be
>> useful, to help with the problem you pointed out in response to my
>> previous suggestion, no?
>
> As a workaround, maybe. However, the amount of code changes to support
> folding/unfolding not only of invisible text, but also extra 'display
> overlays will not be worth it just to address this issue.

After several attempts, I found a way to handle faces in the trailing
newlines after folds without excessive changes in Org mode.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2ade16bbc

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Kévin Le Gouguec]

Ihor Radchenko <yantar92@posteo.net> writes:

> After several attempts, I found a way to handle faces in the trailing
> newlines after folds without excessive changes in Org mode.
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2ade16bbc

Neat.  At first glance (including the subsequent fixup), it looks like
outline.el could be taught the same trick, right?  It would """just"""
be a matter of finding the spot(s) that map to org-fold-core-region, and
implementing equivalents to the org-fold-core helpers you leveraged
(get-regions, get-folding-spec, get-region-at-point) if they don't exist
already?

Not lobbying for it (and certainly not requesting you tackle that);
asking in case your experience with Org taught you anything that might
come in handy for generalizing to outline.el.  There already exist
non-Org uses of that package that could benefit from that feature
(e.g. diff-mode when the diff-context face has a non-default background,
or when diff switches include -U0), so I could see value in adding a
user option to enable that.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

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

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> After several attempts, I found a way to handle faces in the trailing
>> newlines after folds without excessive changes in Org mode.
>> Fixed, on main.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2ade16bbc
>
> Neat.  At first glance (including the subsequent fixup), it looks like
> outline.el could be taught the same trick, right?  It would """just"""
> be a matter of finding the spot(s) that map to org-fold-core-region, and
> implementing equivalents to the org-fold-core helpers you leveraged
> (get-regions, get-folding-spec, get-region-at-point) if they don't exist
> already?

Yes, it should be doable.
The equivalents would be overlay* functions.
Or outline.el can use org-fold-core to fold staff :)
org-fold-core has no major dependencies from Org libraries.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Kévin Le Gouguec]

Ihor Radchenko <yantar92@posteo.net> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> Ihor Radchenko <yantar92@posteo.net> writes:
>>
>>> After several attempts, I found a way to handle faces in the trailing
>>> newlines after folds without excessive changes in Org mode.
>>> Fixed, on main.
>>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2ade16bbc
>>
>> Neat.  At first glance (including the subsequent fixup), it looks like
>> outline.el could be taught the same trick, right?  It would """just"""
>> be a matter of finding the spot(s) that map to org-fold-core-region, and
>> implementing equivalents to the org-fold-core helpers you leveraged
>> (get-regions, get-folding-spec, get-region-at-point) if they don't exist
>> already?
>
> Yes, it should be doable.
> The equivalents would be overlay* functions.
> Or outline.el can use org-fold-core to fold staff :)
> org-fold-core has no major dependencies from Org libraries.

Taking notes.  That prompts further thoughts, but emacs-devel and/or
emacs-orgmode would be better venues for them.

For the purposes of this report, all that comes to mind is

* You might have solved bug#52587?  At least I can no longer reproduce
  using the recipe there (NB: the OP needs adjustments¹) after pulling
  your changes, 'make all', and 'emacs -Q -L lisp' from the Org repo².

  (Which means I could finally dispense with newlines between "#+end_"
  lines and headings 🥹)

* Thank you so much for looking into this! 🙏


¹ As noted in the comments, the issue only comes up if you remove the
newline between "#+end_quote" and "* baz"; also AFAICT modus-operandi no
longer adds a background to org-block-*-line by default?  So I had to
theme that in manually to reproduce & test the fix.

² Don't know if there is a "blessed" way to interactively test changes
in the Org repo; thinking of e.g. magit's 'emacs-Q' target which reduces
the chance of forgetting a step.  FWIW I went in guns blazing with 'make
-j8' and got screenfuls of version-mismatch warnings, so elected to take
-j8 off; that seemed to make things quieter.

bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[Ihor Radchenko]

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

> * You might have solved bug#52587?  At least I can no longer reproduce
>   using the recipe there (NB: the OP needs adjustments¹) after pulling
>   your changes, 'make all', and 'emacs -Q -L lisp' from the Org repo².

Yes, I think. And bug#59141.

> ² Don't know if there is a "blessed" way to interactively test changes
> in the Org repo; thinking of e.g. magit's 'emacs-Q' target which reduces
> the chance of forgetting a step.

make repro

> ... FWIW I went in guns blazing with 'make
> -j8' and got screenfuls of version-mismatch warnings, so elected to take
> -j8 off; that seemed to make things quieter.

You may need to clear stale .elc files in lisp/org before re-compiling.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>