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

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 2471 bytes --]

Hi all,

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.

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):

-----------
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAA
-----------

Is this expected?

Thanks,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eli Zaretskii]

> From: Clément Pit-Claudel <clement.pitclaudel@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?

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1613 bytes --]

On 2018-05-31 11:06, Eli Zaretskii wrote:
> …
> 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:
> …
> 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.  

That's a good point, the behavior that I dislike doesn't even require adaptive-wrap or a wrap-prefix property.  Just having a few spaces at the beginning of a line and a very long word is enough.

> ...
> 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?

Yes, I think that's correct. If I understand correctly, the purpose of visual-line-mode is to break between word to avoid having to break inside words.  If breaking before a word doesn't prevent that word from being broken, it would seem better to not break before it.  In other words, assuming 9 columns:

Here breaking at ' ' is useful:

  Input:
  123456789
  xxx aaaaaaa

  Visual-line mode (good)
  123456789
  xxx
  aaaaaaa

But not here:

  Input
  123456789
  xxx aaaaaaaaaaaaa

  Visual-line mode (bad):
  123456789
  xxx
  aaaaaaaaa
  aaaa

  What I'd expect:
  123456789
  xxx aaaaa
  aaaaaaaa

Does this make sense?
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Noam Postavsky]

Clément Pit-Claudel <clement.pitclaudel@live.com> writes:

> That's a good point, the behavior that I dislike doesn't even require
> adaptive-wrap or a wrap-prefix property.  Just having a few spaces at
> the beginning of a line and a very long word is enough.

Is it the same as Bug#11759?

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

[Stephen Berman]

On Thu, 31 May 2018 20:19:49 -0400 Noam Postavsky <npostavs@gmail.com> wrote:

> Clément Pit-Claudel <clement.pitclaudel@live.com> writes:
>
>> That's a good point, the behavior that I dislike doesn't even require
>> adaptive-wrap or a wrap-prefix property.  Just having a few spaces at
>> the beginning of a line and a very long word is enough.
>
> Is it the same as Bug#11759?

Sounds like it.  This is also an issue in todo-mode, which by default
enables visual-line-mode and indents with wrap-prefix.  For example,
here both items have no space after the date, but the second one is too
long for the window, so Visual Line mode breaks it:

1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
2 [May 31, 2018] 
   http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a0351249c1e6a9307224d
   8337ff8916f4cf138

It would be nice if the display could be like this:

1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
2 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a035124
   9c1e6a9307224d8337ff8916f4cf138

Steve Berman

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Fri, 01 Jun 2018 09:02:15 +0200
> Cc: Clément Pit-Claudel <clement.pitclaudel@live.com>,
> 	31666@debbugs.gnu.org
> 
> > Is it the same as Bug#11759?
> 
> Sounds like it.  This is also an issue in todo-mode, which by default
> enables visual-line-mode and indents with wrap-prefix.  For example,
> here both items have no space after the date, but the second one is too
> long for the window, so Visual Line mode breaks it:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] 
>    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a0351249c1e6a9307224d
>    8337ff8916f4cf138
> 
> It would be nice if the display could be like this:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a035124
>    9c1e6a9307224d8337ff8916f4cf138

I invite the interested parties to review the code which implements
word-wrap.  There are two separate implementations (similar in the
main idea, but quite different in details): one in display_line, which
actually lays out characters for display; the other in
move_it_in_display_line_to, which emulates display without displaying
anything (needed, for example, in vertical-motion).  It is quite
complex, to say the least.

The main difficulty with the above requests, as I see it, is that they
go against the basic design of the Emacs display code, which lays out
characters one screen line at a time.  The current code basically
keeps track of the last whitespace character it saw while walking the
characters to be displayed on a screen line, then backs up to that
place when it finds that the line needs to be continued, ends the
screen line there, and returns, ready to be called to lay out the next
screen line.  What you propose would require it to look ahead one more
screen line (to determine whether it will still be too long after
wrapping), which will slow down redisplay and complicate the code even
more.

It will also have a nasty (IMO) effect, whereby adding or removing a
character to the "bbb..." part will make the display change between
this:

   aaaaaaaaaaaaaaaa
   bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

and this:

   aaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

This will cause all the rest of the text below this line to scroll up
or down, which will require us to disable several redisplay
optimizations when just one character is inserted/deleted.

If someone can find a clever technique to overcome these difficulties,
I'm sure patches will be very welcome.

> This is also an issue in todo-mode, which by default
> enables visual-line-mode and indents with wrap-prefix.  For example,
> here both items have no space after the date, but the second one is too
> long for the window, so Visual Line mode breaks it:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] 
>    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a0351249c1e6a9307224d
>    8337ff8916f4cf138
> 
> It would be nice if the display could be like this:
> 
> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
> 2 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a035124
>    9c1e6a9307224d8337ff8916f4cf138

The usual way of handling these situations is to turn on
truncate-lines.  Any reasons why you don't do that in that mode?
Especially since we now have horizontal scrolling of just the current
line?

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

[Stephen Berman]

On Fri, 01 Jun 2018 10:32:08 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

> [...]  What you propose would require it to look ahead one more
> screen line (to determine whether it will still be too long after
> wrapping), which will slow down redisplay and complicate the code even
> more.
>
> It will also have a nasty (IMO) effect, whereby adding or removing a
> character to the "bbb..." part will make the display change between
> this:
>
>    aaaaaaaaaaaaaaaa
>    bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
>
> and this:
>
>    aaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
>
> This will cause all the rest of the text below this line to scroll up
> or down, 

But this is what already happens with visual-line-mode enabled...

>          which will require us to disable several redisplay
> optimizations when just one character is inserted/deleted.

...or have I misunderstood what you're referring to?

> If someone can find a clever technique to overcome these difficulties,
> I'm sure patches will be very welcome.
>
>> This is also an issue in todo-mode, which by default
>> enables visual-line-mode and indents with wrap-prefix.  For example,
>> here both items have no space after the date, but the second one is too
>> long for the window, so Visual Line mode breaks it:
>> 
>> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
>> 2 [May 31, 2018] 
>>    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a0351249c1e6a9307224d
>>    8337ff8916f4cf138
>> 
>> It would be nice if the display could be like this:
>> 
>> 1 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/log/
>> 2 [May 31, 2018] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c0a035124
>>    9c1e6a9307224d8337ff8916f4cf138
>
> The usual way of handling these situations is to turn on
> truncate-lines.  Any reasons why you don't do that in that mode?
> Especially since we now have horizontal scrolling of just the current
> line?

I would find it more inconvenient to scroll to see the whole item.  The
line-breaking is just an aesthetic issue here.

Steve Berman

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@gmail.com,  clement.pitclaudel@live.com,  31666@debbugs.gnu.org
> Date: Fri, 01 Jun 2018 10:00:52 +0200
> 
> > It will also have a nasty (IMO) effect, whereby adding or removing a
> > character to the "bbb..." part will make the display change between
> > this:
> >
> >    aaaaaaaaaaaaaaaa
> >    bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >
> > and this:
> >
> >    aaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >
> > This will cause all the rest of the text below this line to scroll up
> > or down, 
> 
> But this is what already happens with visual-line-mode enabled...
> 
> >          which will require us to disable several redisplay
> > optimizations when just one character is inserted/deleted.
> 
> ...or have I misunderstood what you're referring to?

Currently, it happens only when a line becomes continued from
non-continued.  With the above proposal, it will happen even when the
line already was continued.

> > The usual way of handling these situations is to turn on
> > truncate-lines.  Any reasons why you don't do that in that mode?
> > Especially since we now have horizontal scrolling of just the current
> > line?
> 
> I would find it more inconvenient to scroll to see the whole item.

Emacs hsrcolls automatically, as you no doubt know.

Anyway, that was only a suggestion.

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

[Eli Zaretskii]

> Cc: 31666@debbugs.gnu.org
> From: Clément Pit-Claudel <clement.pitclaudel@live.com>
> Date: Thu, 31 May 2018 19:16:12 -0400
> 
> Here breaking at ' ' is useful:
> 
>   Input:
>   123456789
>   xxx aaaaaaa
> 
>   Visual-line mode (good)
>   123456789
>   xxx
>   aaaaaaa
> 
> But not here:
> 
>   Input
>   123456789
>   xxx aaaaaaaaaaaaa
> 
>   Visual-line mode (bad):
>   123456789
>   xxx
>   aaaaaaaaa
>   aaaa
> 
>   What I'd expect:
>   123456789
>   xxx aaaaa
>   aaaaaaaa

What about this case:

  Input
  123456789
  xxxxxxx aaaaaaaaaaaaa

?  Would you rather see this:

  123456789
  xxxxxxx
  aaaaaaaaa
  aaaa

or this:

  123456789
  xxxxxxx a
  aaaaaaaaa
  aaa

?

See also the fundamental problem with what you'd like Emacs to do,
which I described in another message.

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1477 bytes --]

On 2018-06-01 03:36, Eli Zaretskii wrote:
> What about this case:
> 
>   Input
>   123456789
>   xxxxxxx aaaaaaaaaaaaa
> 
> ?  Would you rather see this:
> 
>   123456789
>   xxxxxxx
>   aaaaaaaaa
>   aaaa
> 
> or this:
> 
>   123456789
>   xxxxxxx a
>   aaaaaaaaa
>   aaa
> 
> ?
I think I'd be fine with both, with a preference for the second one, especially if it's cheaper to compute that way.

> See also the fundamental problem with what you'd like Emacs to do,
which I described in another message.

Yes, this is a good point, and I don't have a great idea to overcome it.

That does suggest a more restricted improvement, though.  The specific case in which I notice this issue is org-mode:

    **** http://...very-long-string...
    - Item 1
    - http://…very-long-string…

I never want a break after leading '*' characters or bullets, or at the beginning of a line.  In other words, changing this (| is the left margin):

    |asdasd http://
    |*** xyz http://…

to this:

    |asdasd 
    |http://…
    |*** xyz
    |    http://…

is OK, but changing this:

    |  http://…
    |*** http://…

to this:

    |  
    |http://…
    |*** 
    |    http://…

is confusing.

How hard would it be to introduce a no-break text property?  Then I could wire org-mode to put no-break properties on leading spaces and on spaces following '*' markers and everything would be good.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eli Zaretskii]

> Cc: 31666@debbugs.gnu.org
> From: Clément Pit-Claudel <clement.pitclaudel@live.com>
> Date: Fri, 8 Jun 2018 14:04:16 -0400
> 
> How hard would it be to introduce a no-break text property?

The problem is not in introduction of the property, the problem is in
implementing property look up where we decide whether to break a line
on a whitespace character.  That look up might be costly, especially
if, as usual, we are required to support both text and overlay
properties.

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

[Eli Zaretskii]

> Date: Fri, 08 Jun 2018 21:32:03 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 31666@debbugs.gnu.org
> 
> > Cc: 31666@debbugs.gnu.org
> > From: Clément Pit-Claudel <clement.pitclaudel@live.com>
> > Date: Fri, 8 Jun 2018 14:04:16 -0400
> > 
> > How hard would it be to introduce a no-break text property?

Btw, would it be OK to use some non-ASCII whitespace character in
these situations?  For example, you could use u+2002 (or even NBSP,
u+0A0, if you reset nobreak-char-display to nil).

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1310 bytes --]



On 2018-06-08 15:24, Eli Zaretskii wrote:
>> Date: Fri, 08 Jun 2018 21:32:03 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 31666@debbugs.gnu.org
>>
>>> Cc: 31666@debbugs.gnu.org
>>> From: Clément Pit-Claudel <clement.pitclaudel@live.com>
>>> Date: Fri, 8 Jun 2018 14:04:16 -0400
>>>
>>> How hard would it be to introduce a no-break text property?
> 
> Btw, would it be OK to use some non-ASCII whitespace character in
> these situations?  For example, you could use u+2002 (or even NBSP,
> u+0A0, if you reset nobreak-char-display to nil).

Maybe! Org-mode doesn't currently support it (it's fontification rules don't consider that case), but they could be changed.

One additional remark, which may explain why originally I attributed the issue to wrap-prefix.  The case in which the issue tends to be the most perceptible is when using org-mode with long URLs as titles and with adaptive-wrap-prefix-mode.  In that case, starting from

  |***** https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31666

shrinking the window wraps like this:

  |***** 
  |      https://debbugs.gnu.org/cgi/bugre
  |      port.cgi?bug=31666

In that case, wrapping around the first space doesn't help, because the wrap prefix causes us to resume at exactly the same column on the next line.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1443 bytes --]

On 2018-06-08 14:32, Eli Zaretskii wrote:>> Cc: 31666@debbugs.gnu.org
>> From: Clément Pit-Claudel <clement.pitclaudel@live.com>
>> Date: Fri, 8 Jun 2018 14:04:16 -0400
>>
>> How hard would it be to introduce a no-break text property?
> 
> The problem is not in introduction of the property, the problem is in
> implementing property look up where we decide whether to break a line
> on a whitespace character.  That look up might be costly, especially
> if, as usual, we are required to support both text and overlay
> properties.
I see, thanks.  If I understand correctly, at the moment, the check is done in the IT_DISPLAYING_WHITESPACE macro, and indeed that macro only checks for spaces and tabs.

Would it help to restrict that property to spaces and tabs, since we only break lines on these at the moment?  Or is the cost of accessing text properties from IT_DISPLAYING_WHITESPACE too high in any case?

I tried to see how often text properties were accessed after calling IT_DISPLAYING_WHITESPACE, but without too much success.  In one of the 4 calls, it seems that a subsequent call to PRODUCE_GLYPHS will check specified-space properties like QCalign_to.  For the other three calls, I'm not sure.  Would these other three calls sufer from additional property checks?

(I can see how overlay properties would further complicate matters.  Maybe we could restrict support to char properties, at first)

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Eli Zaretskii]

> Cc: 31666@debbugs.gnu.org
> From: Clément Pit-Claudel <clement.pitclaudel@live.com>
> Date: Fri, 8 Jun 2018 17:19:23 -0400
> 
> > The problem is not in introduction of the property, the problem is in
> > implementing property look up where we decide whether to break a line
> > on a whitespace character.  That look up might be costly, especially
> > if, as usual, we are required to support both text and overlay
> > properties.
> I see, thanks.  If I understand correctly, at the moment, the check is done in the IT_DISPLAYING_WHITESPACE macro, and indeed that macro only checks for spaces and tabs.

Yes.

> Would it help to restrict that property to spaces and tabs, since we only break lines on these at the moment?  Or is the cost of accessing text properties from IT_DISPLAYING_WHITESPACE too high in any case?

I didn't say it would be too expensive.  But it will definitely be
more expensive than it is today, which is why I'm trying to suggest
other solutions first.

> I tried to see how often text properties were accessed after calling IT_DISPLAYING_WHITESPACE, but without too much success.  In one of the 4 calls, it seems that a subsequent call to PRODUCE_GLYPHS will check specified-space properties like QCalign_to.  For the other three calls, I'm not sure.  Would these other three calls sufer from additional property checks?

The IT_DISPLAYING_WHITESPACE macro itself will have to lookup text
properties at the location where it attempts to decide whether a space
or a tab can be used as wrap point.

> (I can see how overlay properties would further complicate matters.  Maybe we could restrict support to char properties, at first)

That'd be most probably frowned upon by the community, since we
generally handle them the same elsewhere in Emacs.

Once again, the implementation shouldn't be hard, but if alternative
solutions exist, I'd prefer not to make the display engine slower than
it is already.

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

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1486 bytes --]



On 2018-06-09 04:42, Eli Zaretskii wrote:
>> Would it help to restrict that property to spaces and tabs, since we only break lines on these at the moment?  Or is the cost of accessing text properties from IT_DISPLAYING_WHITESPACE too high in any case?
> 
> I didn't say it would be too expensive.  But it will definitely be
> more expensive than it is today, which is why I'm trying to suggest
> other solutions first.

Makes sense. Thanks.

>> I tried to see how often text properties were accessed after calling IT_DISPLAYING_WHITESPACE, but without too much success.  In one of the 4 calls, it seems that a subsequent call to PRODUCE_GLYPHS will check specified-space properties like QCalign_to.  For the other three calls, I'm not sure.  Would these other three calls sufer from additional property checks?
> 
> The IT_DISPLAYING_WHITESPACE macro itself will have to lookup text
> properties at the location where it attempts to decide whether a space
> or a tab can be used as wrap point.
> 
>> (I can see how overlay properties would further complicate matters.  Maybe we could restrict support to char properties, at first)
> 
> That'd be most probably frowned upon by the community, since we
> generally handle them the same elsewhere in Emacs.

OK, that makes sense.

> Once again, the implementation shouldn't be hard, but if alternative
> solutions exist, I'd prefer not to make the display engine slower than
> it is already.

Understood.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]