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: Sat, 9 Jun 2018 08:45:17 -0400 [thread overview]
Message-ID: <ecccdc8f-92e7-5bda-6139-8beedc76e0b5@live.com> (raw)
In-Reply-To: <83602stkow.fsf@gnu.org>
[-- 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 --]
prev parent reply other threads:[~2018-06-09 12:45 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
2018-06-09 8:42 ` Eli Zaretskii
2018-06-09 12:45 ` Clément Pit-Claudel [this message]
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=ecccdc8f-92e7-5bda-6139-8beedc76e0b5@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).