all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: dick <dick.r.chiang@gmail.com>
Cc: gregory@heytings.org, 57669@debbugs.gnu.org
Subject: bug#57669: 29.0.50; C-n, C-p off under long lines
Date: Sat, 10 Sep 2022 11:32:49 +0300	[thread overview]
Message-ID: <8335czbpe6.fsf@gnu.org> (raw)
In-Reply-To: <87fsh0dt7y.fsf@dick> (message from dick on Fri, 09 Sep 2022 19:27:13 -0400)

> Cc: 57669@debbugs.gnu.org
> From: dick <dick.r.chiang@gmail.com>
> Date: Fri, 09 Sep 2022 19:27:13 -0400
> 
> First you would need to construct a pathological case, like lots of Urdu
> and Hindi

There's nothing pathological about Hindi text.  In fact, the JSON and
XML files with very long lines, which we are using for this work,
quite frequently have non-ASCII text from various scripts, including
R2L scripts.  At least one of them I think went as far as showing
strings in every supported script.

> I would add that unless you're seriously considering replacing narrowing
> with my first-principles scheme (doubtful given how many hours you've
> invested in narrowing), this is all an academic exercise in
> oneupsmanship, which mind you, I am definitely game for.  If that
> suggests I believe I dealt with long lines better than you, you'd be
> correct.

This is not a pissing contest, at least not on our part.  We are
keenly interested in using any ideas that are correct, can be
implemented without too many complications, and provide significant
speedups, especially for very long lines.

For example, if the behaved_p idea, when implemented correctly
(i.e. when it takes into considerations _all_ the factors that violate
the monospace-ness assumption), can significantly speed up redisplay
in some situations, we would like to use it, at least when the
long_line_optimizations_p flag is set, if not always.  However, both
the correct conditions for behaved_p and the actual speedups still
need to be coded and measured, before we can make that decision.

One fundamental problem with the behaved_p idea is that the conditions
it should test, when implemented correctly, can change at any buffer
position, and at least for some of them (e.g., when a character is
displayed by glyphs from a display-table), we don't have any way of
knowing that in advance, except by examining every character, which
basically annuls any advantages of this idea.  So I'm not sure if this
idea is usable in a way that doesn't introduce subtle bugs.  But maybe
such bugs could be tolerable when lines are very long (which means the
relevant optimizations should only be taken when the
long_line_optimizations_p flag is set)?





  reply	other threads:[~2022-09-10  8:32 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08  5:40 bug#57669: 29.0.50; C-n, C-p off under long lines dick.r.chiang
2022-09-08  7:38 ` Gregory Heytings
2022-09-08  8:17 ` Eli Zaretskii
2022-09-08 12:02   ` dick
2022-09-08 17:12     ` Gregory Heytings
2022-09-08 18:13       ` dick
2022-09-08 18:26         ` Gregory Heytings
2022-09-09  6:00         ` Eli Zaretskii
2022-09-09 13:08           ` dick
2022-09-09 13:38             ` Gregory Heytings
2022-09-09 14:34               ` dick
2022-09-09 14:39                 ` Gregory Heytings
2022-09-09 15:06                   ` dick
2022-09-09 15:41                     ` Gregory Heytings
2022-09-09 16:30                       ` dick
2022-09-09 16:42                         ` Gregory Heytings
2022-09-09 17:11                           ` dick
2022-09-09 18:09                             ` Gregory Heytings
2022-09-09 15:49                 ` Eli Zaretskii
2022-09-09 15:58                   ` Gregory Heytings
2022-09-09 16:04                     ` Eli Zaretskii
2022-09-09 14:12             ` Eli Zaretskii
2022-09-09 15:04               ` dick
2022-09-09 15:19                 ` Gregory Heytings
2022-09-09 15:52                   ` dick
2022-09-09 16:03                     ` Eli Zaretskii
2022-09-09 16:06                       ` Gregory Heytings
2022-09-09 16:19                         ` Eli Zaretskii
2022-09-09 16:25                           ` Gregory Heytings
2022-09-09 17:44                           ` dick
2022-09-09 18:06                             ` Eli Zaretskii
2022-09-09 18:22                               ` dick
2022-09-09 18:57                                 ` Eli Zaretskii
2022-09-09 19:28                                   ` dick
2022-09-09 19:38                                     ` Eli Zaretskii
2022-09-09 19:55                                   ` dick
2022-09-09 21:28                                     ` Gregory Heytings
2022-09-09 22:00                                       ` dick
2022-09-09 22:44                                         ` Gregory Heytings
2022-09-09 23:27                                           ` dick
2022-09-10  8:32                                             ` Eli Zaretskii [this message]
2022-09-10 12:51                                               ` dick
2022-09-10 13:09                                                 ` Eli Zaretskii
2022-09-10 13:29                                                   ` Eli Zaretskii
2022-09-10 13:22                                                 ` Eli Zaretskii
2022-09-10 14:03                                                   ` dick
2022-09-10 14:20                                                     ` Eli Zaretskii
2022-09-10 14:52                                                       ` dick
2022-09-10 10:26                                             ` Gregory Heytings
2022-09-10  7:45                                     ` Eli Zaretskii
2022-09-10 12:07                                       ` dick
2022-09-10 12:20                                         ` dick
2022-09-10 12:24                                         ` Eli Zaretskii
2022-09-10 16:55                                       ` Gregory Heytings

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

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

  git send-email \
    --in-reply-to=8335czbpe6.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=57669@debbugs.gnu.org \
    --cc=dick.r.chiang@gmail.com \
    --cc=gregory@heytings.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.