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#69611: 30.0.50; Long bidi line with control characters freezes Emacs Date: Thu, 07 Mar 2024 21:19:31 +0200 Message-ID: <86r0gl26kc.fsf@gnu.org> References: <87plw66tv6.fsf@gmx.net> <86v85y1217.fsf@gnu.org> <87h6hi6iaz.fsf@gmx.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23720"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69611@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 07 20:20:54 2024 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 1riJIU-00060W-DL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Mar 2024 20:20:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1riJID-0000LE-HP; Thu, 07 Mar 2024 14:20:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riJIB-0000Ku-Mj for bug-gnu-emacs@gnu.org; Thu, 07 Mar 2024 14:20:35 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1riJI6-0007Fr-SN for bug-gnu-emacs@gnu.org; Thu, 07 Mar 2024 14:20:31 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1riJIc-0000Nz-B6 for bug-gnu-emacs@gnu.org; Thu, 07 Mar 2024 14:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Mar 2024 19:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69611 X-GNU-PR-Package: emacs Original-Received: via spool by 69611-submit@debbugs.gnu.org id=B69611.17098392151391 (code B ref 69611); Thu, 07 Mar 2024 19:21:02 +0000 Original-Received: (at 69611) by debbugs.gnu.org; 7 Mar 2024 19:20:15 +0000 Original-Received: from localhost ([127.0.0.1]:54982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riJHq-0000MM-Rb for submit@debbugs.gnu.org; Thu, 07 Mar 2024 14:20:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riJHn-0000M2-01 for 69611@debbugs.gnu.org; Thu, 07 Mar 2024 14:20:13 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riJHB-0005oX-TB; Thu, 07 Mar 2024 14:19:33 -0500 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=lXStJ/+U+fzFmAZOlQurcx+WugpSZDIPCFVs5XHaR1k=; b=kA3VTTrNirWD tM7VsKIcrTG1jGwl+JaTcTP6bkw56zVLDD2UEhNBAFJLOfcCQgZdGtaYMZJyrf5K+Yr7JNuytO41U CzaLc+wtaM14sdfmvG1lbdLjXNQ+bA3qP4nDFI7OVL5OE/JLhBnPqwezyzULi5I1f0x+Q0xNjF/kf 2FYqQuT+ov3mBGI89qobEdXVK8Ewlu/0ec2FoMiwVGDNxwH7sh6lY0YRZy9Z16u7iTrtvdyG75gxd Wb7CF7ZvdYCqFnUYtw1yuv1DGR6k5pTihzS9T8Lv++Ex2CplCxI5OOQM9T7nA/0t84Ub65UOCMAsF oVnUrcbO5N7BwNTvVPDx4A==; In-Reply-To: <87h6hi6iaz.fsf@gmx.net> (message from Stephen Berman on Thu, 07 Mar 2024 18:52:20 +0100) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:281186 Archived-At: > From: Stephen Berman > Cc: 69611@debbugs.gnu.org > Date: Thu, 07 Mar 2024 18:52:20 +0100 > > In the case of the file I sent you, I may be to blame for the unbalanced > control characters: after yanking the Arabic into Emacs, I did some > editing of it and may well have unintentionally deleted some of the > control characters. At the time I wasn't even aware of these; only > after (re)reading the section on bidirectional display in the Elisp > manual did I enable glyphless-display-mode and saw the characters, but I > didn't bother to check if they paired up properly. In that case, it could be that the original file wouldn't be so expensive, if each short Arabic string was included in a right-to-left embedding, i.e. RLE before it and PDF after it. Then we wouldn't have nested embeddings, and each embedding would be quite short. This should produce quite "normal" display speed, not different from when displaying bidirectional text without the control characters at all. IOW, it could be that by deleting some of the controls you created the nested embeddings that were not there in the first place. > > The extremely deep nesting of embeddings in the file, coupled with the > > fact that the first embedding starts near the beginning of the file, > > but ends very near its end, causes the algorithm that finds where to > > position the cursor to fail, because it cannot cope with the situation > > where, after C-f or C-b, the position of point is very far outside of > > the window. I guess this causes some infloop (even though I don't see > > it here, I just see that the cursor doesn't move although point does > > move). It could also be just a very long calculation, not an infloop, > > because finding where to place the window-start point in this case is > > also very expensive. > > Ok. But this is only an issue in conjunction with long lines, right? Yes, because all the embedding levels are reset at the newline. So having a newline not far away guarantees that the reordering code doesn't need to look too far for where the embedding ends. > > This file is an interesting curiosity, as far as I'm concerned, but I > > doubt whether I will find enough time and motivation to try to speed > > up Emacs when such crazy files are visited. > > Given the special circumstances of this file's creation I think there's > no need to spend any more time it, so unless you decide you do want to, > as far as I'm concerned this bug can be closed. It might be beneficial > to others to document the issue briefly, either in the Elisp manual > under Bidirectional Display or just in etc/PROBLEMS, but maybe this is > such an unusual case that even that isn't worth the effort. I doubt it's worth describing, since even explaining what happens needs a long treatise on what are bidirectional embedding levels, how they affect reordering, and how Emacs implements that reordering in a way that fits into the general structure of the Emacs display code (which examines characters in their visual order). We'd basically need to copy into PROBLEMS or the manual large portions of the commentary at the beginning of bidi.c, which includes a lot of technical details.