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

Previous Next

Full log

Message #47 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: Sat, 09 Jun 2018 11:42:39 +0300

> Cc: 31666 <at> debbugs.gnu.org
> From: Clément Pit-Claudel <clement.pitclaudel <at> 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.

Previous Next

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