unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Clément Pit-Claudel" <clement.pitclaudel@live.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 31666@debbugs.gnu.org
Subject: bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines
Date: Fri, 8 Jun 2018 17:19:23 -0400	[thread overview]
Message-ID: <edcea4d2-991e-68a5-ca7e-3a53a85f88be@live.com> (raw)
In-Reply-To: <83o9glt9i4.fsf@gnu.org>


[-- 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 --]

  parent reply	other threads:[~2018-06-08 21:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-31 12:27 bug#31666: Bad interaction between visual-line-mode and wrap-prefix on long lines Clément Pit-Claudel
2018-05-31 15:06 ` Eli Zaretskii
2018-05-31 23:16   ` Clément Pit-Claudel
2018-06-01  0:19     ` Noam Postavsky
2018-06-01  7:02       ` Stephen Berman
2018-06-01  7:32         ` Eli Zaretskii
2018-06-01  8:00           ` Stephen Berman
2018-06-01  8:44             ` Eli Zaretskii
2018-06-01  7:36     ` Eli Zaretskii
2018-06-08 18:04       ` Clément Pit-Claudel
2018-06-08 18:32         ` Eli Zaretskii
2018-06-08 19:24           ` Eli Zaretskii
2018-06-08 19:32             ` Clément Pit-Claudel
2018-06-08 21:19           ` Clément Pit-Claudel [this message]
2018-06-09  8:42             ` Eli Zaretskii
2018-06-09 12:45               ` Clément Pit-Claudel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=edcea4d2-991e-68a5-ca7e-3a53a85f88be@live.com \
    --to=clement.pitclaudel@live.com \
    --cc=31666@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).