GNU bug report logs - #31666
Bad interaction between visual-line-mode and wrap-prefix on long lines

Previous Next

Package: emacs;

Reported by: Clément Pit-Claudel <clement.pitclaudel <at> live.com>

Date: Thu, 31 May 2018 12:29:02 UTC

Severity: minor

Merged with 11759

Found in version 24.1.50

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit-Claudel <clement.pitclaudel <at> live.com>
Cc: 31666 <at> debbugs.gnu.org
Subject: Re: bug#31666: Bad interaction between visual-line-mode and
 wrap-prefix on long lines
Date: Thu, 31 May 2018 18:06:15 +0300
> From: Clément Pit-Claudel <clement.pitclaudel <at> live.com>
> Date: Thu, 31 May 2018 08:27:43 -0400
> 
> I use adaptive-wrap-prefix-mode from ELPA to get nice looking line-wrapping, and I also usually have visual-line-mode enabled.  Using the two together causes a rendering issue for long lines with no spaces in them: they are displayed with a preceding blank line added.

I'm not sure I understand/agree that the above describes the same
issue as your example.  But let's deal with the example first:

> The following snippet demonstrates the problem:
> 
> (with-current-buffer (get-buffer-create "wrap")
>   (text-mode)
>   (visual-line-mode)
>   (erase-buffer)
>   (let* ((prefix (make-string 16 ?\s))
>          (aaa (make-string 260 ?A)))
>     (insert prefix (propertize aaa 'wrap-prefix prefix) "\n")
>     (insert (propertize (concat prefix aaa) 'wrap-prefix prefix) "\n"))
>   (display-buffer (current-buffer)))
> 
> Here's what the output looks like:
> 
> -----------
>                
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAA
>                
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>                 AAAA
> -----------
> 
> Notice how each line of AAA is preceded with a blank line (containing just 15 spaces).  I was expecting that code to produce this rendering instead (This is what you get if you turn off visual-line-mode):

> Is this expected?

I don't see why you shouldn't expect that.  Visual Line mode breaks
long lines on whitespace characters, and the 15 spaces with which you
start each line provide ample opportunity for that.  Compare with the
following modified example, where I replaced 15 of the 16 spaces with
another character:

  (with-current-buffer (get-buffer-create "wrap1")
    (text-mode)
    (visual-line-mode)
    (erase-buffer)
    (let* ((prefix (make-string 16 ?\s))
	   (aaa (make-string 260 ?A))
	   (prefix1 "xxxxxxxxxxxxxxx "))
      (insert prefix1 (propertize aaa 'wrap-prefix prefix) "\n")
      (insert (propertize (concat prefix1 aaa) 'wrap-prefix prefix) "\n"))
    (display-buffer (current-buffer)))

This produces:

xxxxxxxxxxxxxxx
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

etc, and you clearly see that Visual Line mode broke the first line on
the single SPC character there.  Are you saying that you expected this
instead:

xxxxxxxxxxxxxxx AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

?  That would be Visual Line mode missing an opportunity to break a
long line on whitespace characters, no?

Am I missing something?




This bug report was last modified 5 years and 65 days ago.

Previous Next


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