GNU bug report logs - #76018
31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#76018: closed (31.0.50; wrap-prefix properties from
 visual-wrap-prefix-mode proliferate)
Date: Wed, 11 Jun 2025 05:21:02 +0000

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

Your message dated Tue, 10 Jun 2025 22:19:52 -0700
with message-id <b3b9fcc4-a316-4f1a-672b-2797d9c9a165 <at> gmail.com>
and subject line Re: bug#76018: 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate
has caused the debbugs.gnu.org bug report #76018,
regarding 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
76018: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76018
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode
 proliferate
Date: Sun, 02 Feb 2025 18:50:40 +0100

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

[Message part 3 (message/rfc822, inline)]

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 76018-done <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 kevin.legouguec <at> gmail.com
Subject: Re: bug#76018: 31.0.50; wrap-prefix properties from
 visual-wrap-prefix-mode proliferate
Date: Tue, 10 Jun 2025 22:19:52 -0700

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.

Previous Next

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