Subject: bug#76018: closed (Re: bug#76018: 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 11 Jun 2025 05:21:03 +0000

Your bug report

#76018: 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
76018: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76018
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#76018: 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate
From: Jim Porter <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 10 Jun 2025 22:19:52 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On 6/7/2025 2:34 AM, Eli Zaretskii wrote:
> LGTM, thanks.

Thanks for taking a look. Since I believe all the open issues are now 
addressed, I've merged my patch series to the master branch as 
38c57855ae2. Closing this bug now.

Of course, if I've missed anything, just let me know and I'll try to 
handle it.

>> For patch 0002, I debated changing the various function names to
>> 'get-display-specification' and 'add-display-specification', but I left
>> them as-is for now. If you think we should change them so the wording is
>> more consistent, let me know (of course, I'd add aliases from the old
>> names to the new ones too).
> 
> No need to rename the functions, I think.

Fine by me either way. I have a (very!) slight preference for renaming 
them to make the terminology clearer, but so long as documentation uses 
consistent naming, I'm happy. We can always rename the functions later 
if we change our minds.

Subject: 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate
From: Kévin Le Gouguec <[email-masked]>
To: [email-masked]
Date: Sun, 02 Feb 2025 18:50:40 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Heya!

To reproduce from emacs -Q:

    C-x b repro
    M-x visual-wrap-prefix-mode
    - first line of [words…]
    RET
    RET
    second line of [words…]
    C-o

Expectation: continuation lines for the "second line of [words…]" should
not have any indentation.
Observation: text on that second line has these properties:

    There are text properties here:
      fontified            t
      wrap-prefix          (space :align-to (2 . width))

(NB: "C-o" in the recipe ensures there is a character at point,
otherwise "C-u C-x =" shows nothing on account of being at EOB)

Denoting "hard spaces" (buffer text) with "·" and "visual spaces"
(visual-wrap-prefix-mode decoration) with " ", text thus wraps like
this:

    -·first·line·of·
      words·words

    second·line·of
      words·words

Not sure what the right fix is; having just learned about text property
"stickiness", I can at least work around the issue with…

    (push '(wrap-prefix . t) text-property-default-nonsticky)

… but I have not dogfooded this much yet.

Thanks for your time!

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.2) of 2025-01-18 built on amdahl30
Repository revision: 840057bb1bfc05a52519793c620d729688ea1d8f
Repository branch: master
Windowing system distributor 'SUSE LINUX', version 11.0.12401004
System Description: openSUSE Tumbleweed

Configured using:
 'configure --prefix=/home/peniblec/apps/.emacs.2025-01-18 --with-cairo
 --with-native-compilation=no --with-sqlite3 --with-xinput2'

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

Important settings:
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix