From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Berman via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69611: 30.0.50; Long bidi line with control characters freezes Emacs Date: Thu, 07 Mar 2024 22:21:54 +0100 Message-ID: <87cys57n65.fsf@gmx.net> References: <87plw66tv6.fsf@gmx.net> <86v85y1217.fsf@gnu.org> <87h6hi6iaz.fsf@gmx.net> <86r0gl26kc.fsf@gnu.org> Reply-To: Stephen Berman Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20451"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 69611-done@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 07 22:23:18 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 1riLCw-00054m-AX for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Mar 2024 22:23:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1riLCD-0004dq-9h; Thu, 07 Mar 2024 16:22:33 -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 1riLCB-0004dH-Gn for bug-gnu-emacs@gnu.org; Thu, 07 Mar 2024 16:22:31 -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 1riLCB-0004Xy-8k for bug-gnu-emacs@gnu.org; Thu, 07 Mar 2024 16:22:31 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1riLCg-0000wo-SP for bug-gnu-emacs@gnu.org; Thu, 07 Mar 2024 16:23:02 -0500 Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Mar 2024 21:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 69611 X-GNU-PR-Package: emacs Mail-Followup-To: 69611@debbugs.gnu.org, stephen.berman@gmx.net, stephen.berman@gmx.net Original-Received: via spool by 69611-done@debbugs.gnu.org id=D69611.17098465593587 (code D ref 69611); Thu, 07 Mar 2024 21:23:02 +0000 Original-Received: (at 69611-done) by debbugs.gnu.org; 7 Mar 2024 21:22:39 +0000 Original-Received: from localhost ([127.0.0.1]:55154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riLCJ-0000vm-88 for submit@debbugs.gnu.org; Thu, 07 Mar 2024 16:22:39 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:44737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1riLCD-0000vU-Ag for 69611-done@debbugs.gnu.org; Thu, 07 Mar 2024 16:22:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1709846515; x=1710451315; i=stephen.berman@gmx.net; bh=olzHHcig6S7yiKPb+JaN7koFvTPZUuA+OLt/TBEUGBE=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References: Date; b=GfCTYlRDVT1G2dTurRzx37WOMzPlRA/3IbO72vd+HHhocbjSs8C43IOnciSaZrWd bbpGNYbNByuODejmTZZVxthNWAC5UwGLIsHGX3Ck1gi6/lCdYUkYpYPh8w3a5gdPL 29EtaqKl3AVenyE83tUUpPGbNp3hXReX4D8EC4RyI5TcdBSnePYf2q8akd0UlnJQa LM4/7IvWNTJflDVqAuvUhyYTLMHtLJqjcVbNOtDpZm2w6E1t9ynMPvJ5cH/gcA6Lg e9asxyxAD4pqmTgbioAqGSY7EpIsGzWPvur7pdn7Y7TvHKcSNdJfUVqd+d+Z6x08L zzGk3EPK8WQYTA1Q3w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from strobelfs2 ([94.134.94.231]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mqb1W-1r4rYZ1R9U-00mbHE; Thu, 07 Mar 2024 22:21:55 +0100 In-Reply-To: <86r0gl26kc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 07 Mar 2024 21:19:31 +0200") X-Provags-ID: V03:K1:Hfy+1oXolD6mK4lc5fTAv/F74jnOoVCcV+WG7e9mmVfPrssF7zI r6NgIrT3UfNR6MAj+/Pmgs02lvOCAA6wspb5F951jibedLc+hdSTNI7XDuiWyDMAZAK+kfE yMqvPkz6hfg2sQpInCaI0PY89kek50GzRG4Bs18QIXYYk2bgvnnoJrxux85x/NUivlUuae3 GaOloPEEofIXtENdGGEYA== UI-OutboundReport: notjunk:1;M01:P0:zsM6FH8cHYA=;OyJUVUVtFyWZCDE51lwz0ZmYN8X gJccAUIkgJ44pq0Ty3AQkZB9yeOYaQtUc2JEtDI/zOmC5WLKB1xDnKzhdQh8AVeOm+gHTcQdm 1UibuVI6IYezw8EYzCzrej2GfzbBdsL/vVgPVTK8o5LFOMFB0qrPlUk9Y+HTdV5yTPhW9bRpe OMC//9HVtTr+h8t8fWo4A0+3dj5+UuMN6XOE/dEJJZhiW6u36bmnzl0UwncuGFlieFBikVnZD PPAJ0aE9EYLBvP85pX3F3aSP9nicvogkakWbyBTDhKtdp+o+ag7PlFnPEcx55UYPeObWfbI8u o8BArLCq9uEa1PWqaDB+sqdsAo+RICmNSYz0gVFG3NcbqYjS41DmgeAXa0yRiiVHuiM84XVmn 281yLrK4+OL4E6a0KBJxIliXP5c29CAot189NiuiWoSHTcsbvD0roQiafCBNZXw7xQUmL8zqb oU4KKF+DMRGYU+fWJ3lRpwetKUmPx6WxUSK4kvqUPVOxBXsT35ou3mz/eR6H4Orl+6TaAE9C0 Ri/PctE6WOIInoaEq15gBqIXL7qLYw+ymO/KX4PaXhrit6VCrCq8RYKncwNE5wk2ojr5s4Z1g wuvY7SZdNaQF+eBzRmrvPngf76jGVWDO1S6fJssmjk2i6/apjVhCL23rYhBkVIDMBFuyECJU2 klggBrPbSNaOrwaUG2WULnZh/jdrqmCgEmEjjHJKZAjyRjNGZKNeTKPGnEa/UXu83WqiL6520 JzmyHfhWLzn68wm3XnqEYySmtefBnM6QBKTCTOWZLn66PW/xk9plvI1EZUICxJsMsJNsHKfz 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:281193 Archived-At: On Thu, 07 Mar 2024 21:19:31 +0200 Eli Zaretskii wrote: >> 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 unbalance= d >> 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. It would be interesting to test this; perhaps I can without too much effort add the missing controls to make them balanced. I'll take a look. >> > The extremely deep nesting of embeddings in the file, coupled with th= e >> > 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 situatio= n >> > 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 se= e >> > 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. Ah, ok, then that explains it. >> > 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. Yeah, that would be going overboard. I'm more than satisfied with the explanations you've provided, so I'm going ahead and closing this bug. Thanks again. Steve Berman