From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57669: 29.0.50; C-n, C-p off under long lines Date: Sat, 10 Sep 2022 11:32:49 +0300 Message-ID: <8335czbpe6.fsf@gnu.org> References: <87y1uujufi.fsf@dick> <87tu5ijcqg.fsf@dick> <2e25ca87e3d9ee13ba3e@heytings.org> <87illxka46.fsf@dick> <8335d1dr39.fsf@gnu.org> <87mtb8hezl.fsf@dick> <838rmsd4cc.fsf@gnu.org> <878rmsh9me.fsf@dick> <87zgf8fsv3.fsf@dick> <83zgf8bkmn.fsf@gnu.org> <83v8pwbjvy.fsf@gnu.org> <87a678fnnz.fsf@dick> <83r10kbex8.fsf@gnu.org> <875yhwflw7.fsf@dick> <83pmg4bcjt.fsf@gnu.org> <87wnace31g.fsf@dick> <87k06cdx8m.fsf@dick> <87fsh0dt7y.fsf@dick> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24515"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, 57669@debbugs.gnu.org To: dick Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 10 10:34:18 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWvwP-0006AB-Tk for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Sep 2022 10:34:18 +0200 Original-Received: from localhost ([::1]:45700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWvwO-0007PL-9n for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Sep 2022 04:34:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49524) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWvwB-0007PC-3T for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 04:34:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47847) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oWvwA-0005ML-Em for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 04:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oWvw9-00049r-Uu for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 04:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2022 08:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57669 X-GNU-PR-Package: emacs Original-Received: via spool by 57669-submit@debbugs.gnu.org id=B57669.166279880015927 (code B ref 57669); Sat, 10 Sep 2022 08:34:01 +0000 Original-Received: (at 57669) by debbugs.gnu.org; 10 Sep 2022 08:33:20 +0000 Original-Received: from localhost ([127.0.0.1]:36546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWvvT-00048o-KD for submit@debbugs.gnu.org; Sat, 10 Sep 2022 04:33:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWvvP-00048X-Ak for 57669@debbugs.gnu.org; Sat, 10 Sep 2022 04:33:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:32872) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWvvJ-0005Gz-Nn; Sat, 10 Sep 2022 04:33:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lONlewPBJst72/N5H2q4fCxzf5WzQScuzXOLYgWnSCM=; b=e62NaQsXUpa8 UcnxcYa90AbwSEfMvjH+Lnv2M2LmV1GNK4chGU2fu0CYylYw78/K26XMIEXKPULVphFhH2VFmHe2Q mmF1B9dWJeZNMeeoxAoCCpajjPIY5kL2KMj8zE8z2Ujrd/WEPMJbkMHAyYFseeTAHSViKA58Y1pK+ IZW7IFZyTFfB3MJX/jfuYrbTBQ3K0zpfY4xE2p5k7sYPyLP6awixrg32YQoQ8VPPdsisna3dGbjjl d12fA6GttBSSomK3Z7pp3EuVshoOz721t6p3PwUJSe5u1z6gfXwoe4zyHKSQNfo4CyfVSoNSUvUvc ZnCFs0r8RIkpTer7+4stMA==; Original-Received: from [87.69.77.57] (port=2938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWvvJ-0005tN-4Y; Sat, 10 Sep 2022 04:33:09 -0400 In-Reply-To: <87fsh0dt7y.fsf@dick> (message from dick on Fri, 09 Sep 2022 19:27:13 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242089 Archived-At: > Cc: 57669@debbugs.gnu.org > From: dick > 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)?