bug#65990: 29.1; show-paren-mode should not highlight line-prefix area

bug#65990: 29.1; show-paren-mode should not highlight line-prefix area

[awrhygty]

Evaluate the form below,
the blank area on the left of the open parensis is highlighted,
while the blank area on the left of the close parensis is not.
Then type 'C-l C-l' to make the close parensis placed at the window
start, the area on the left of the close parensis is highlighted.

(let ((buf (generate-new-buffer "*temp*")))
  (switch-to-buffer buf)
  (insert (propertize "(x\n)" 'line-prefix '(space :width 8))))


In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3448)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils term/bobcat japan-util rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win 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 w32notify w32 lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 51665 10284)
 (symbols 48 5198 0)
 (strings 32 15235 1629)
 (string-bytes 1 410090)
 (vectors 16 10774)
 (vector-slots 8 335087 17984)
 (floats 8 35 38)
 (intervals 56 225 9)
 (buffers 984 10))

bug#65990: 29.1; show-paren-mode should not highlight line-prefix area

[Eli Zaretskii]

> From: awrhygty@outlook.com
> Date: Fri, 15 Sep 2023 18:26:12 +0900
> 
> 
> Evaluate the form below,
> the blank area on the left of the open parensis is highlighted,
> while the blank area on the left of the close parensis is not.
> Then type 'C-l C-l' to make the close parensis placed at the window
> start, the area on the left of the close parensis is highlighted.
> 
> (let ((buf (generate-new-buffer "*temp*")))
>   (switch-to-buffer buf)
>   (insert (propertize "(x\n)" 'line-prefix '(space :width 8))))

Normally, none of the line-prefix should be highlighted.  And that is
what happens when the show-paren face is anywhere but at the first
visible character in the window.  When the face _is_ on the first
visible character in the window, it is not clear whether the face
should be considered as starting before the window or not; the current
display code considers it to start before the window-start.

I tend to close this bug as wontfix, since it seems to happen in rare
situations, and fixing it will likely be messy.  If you can show that
it happens in more than just these rare cases, or if you have any
suggestions for how to fix that or even can just point to the code
which causes this, I might change my mind.

Thanks.

bug#65990: 29.1; show-paren-mode should not highlight line-prefix area

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: awrhygty@outlook.com
>> Date: Fri, 15 Sep 2023 18:26:12 +0900
>>
>>
>> Evaluate the form below,
>> the blank area on the left of the open parensis is highlighted,
>> while the blank area on the left of the close parensis is not.
>> Then type 'C-l C-l' to make the close parensis placed at the window
>> start, the area on the left of the close parensis is highlighted.
>>
>> (let ((buf (generate-new-buffer "*temp*")))
>>   (switch-to-buffer buf)
>>   (insert (propertize "(x\n)" 'line-prefix '(space :width 8))))
>
> Normally, none of the line-prefix should be highlighted.  And that is
> what happens when the show-paren face is anywhere but at the first
> visible character in the window.  When the face _is_ on the first
> visible character in the window, it is not clear whether the face
> should be considered as starting before the window or not; the current
> display code considers it to start before the window-start.
>
> I tend to close this bug as wontfix, since it seems to happen in rare
> situations, and fixing it will likely be messy.  If you can show that
> it happens in more than just these rare cases, or if you have any
> suggestions for how to fix that or even can just point to the code
> which causes this, I might change my mind.
>
> Thanks.

No further comments within 3 months, so I'm closing this bug.