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#68446: 29.1.90; Bidi right-to-left paragraphs missing text in Org mode Date: Sun, 14 Jan 2024 15:00:56 +0200 Message-ID: <8334v0f4s7.fsf@gnu.org> References: <93fcc2d3-f808-42d7-b31e-a88522986989@gmail.com> <834jfgf984.fsf@gnu.org> <87zfx8ru7c.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39547"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68446@debbugs.gnu.org, thamer.mahmoud@gmail.com To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 14 14:02:35 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 1rP08J-000A4c-FL for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Jan 2024 14:02:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rP07y-0007xB-Cj; Sun, 14 Jan 2024 08:02:14 -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 1rP07n-0007u7-N6 for bug-gnu-emacs@gnu.org; Sun, 14 Jan 2024 08:02:03 -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 1rP07n-0005qz-Eq for bug-gnu-emacs@gnu.org; Sun, 14 Jan 2024 08:02:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rP07m-0003Yx-6u for bug-gnu-emacs@gnu.org; Sun, 14 Jan 2024 08:02: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: Sun, 14 Jan 2024 13:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68446 X-GNU-PR-Package: emacs Original-Received: via spool by 68446-submit@debbugs.gnu.org id=B68446.170523728512604 (code B ref 68446); Sun, 14 Jan 2024 13:02:02 +0000 Original-Received: (at 68446) by debbugs.gnu.org; 14 Jan 2024 13:01:25 +0000 Original-Received: from localhost ([127.0.0.1]:41874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rP07A-0003Gb-G2 for submit@debbugs.gnu.org; Sun, 14 Jan 2024 08:01:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rP077-000384-SX for 68446@debbugs.gnu.org; Sun, 14 Jan 2024 08:01:22 -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 1rP072-0005II-OZ; Sun, 14 Jan 2024 08:01:16 -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=VZiv1AGbIL18rXL5N0M68zyzlLYvkBaGB/jPT3Xg+kc=; b=pQBxVzTExtvg C54XXMzF2ChWMKwd4yBHBMrKy40Dla/wWFCbbQh+UPBhwyFt0b/mMEkxYgP+s6/XJtGAVlRh29Auo Zc0HhbGBsM2f81LNLNiXgsirOhV0PT0UpgTgG+Rf4p2vCJvE8PGyQU7h6NkY/gDHfvqikfvrTfTuJ uElj4sD6uCxIUDuF2emoGaQTOBEUT3orNbTjGcvSbeZSsy3wRuykkGqm/cCvHWlE6w2RAbz6Weygu lCNGmQW3YcSVmulUgNmR/z6M4T0u4fMW14dxVl/QeviN0VBu+asFJCQzp9FCRqe4MNNp8i2eKLAe/ VMHSTlQYEb0R4KgVCN3fgA==; In-Reply-To: <87zfx8ru7c.fsf@localhost> (message from Ihor Radchenko on Sun, 14 Jan 2024 12:11:03 +0000) 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:278207 Archived-At: > From: Ihor Radchenko > Cc: Thamer Mahmoud , 68446@debbugs.gnu.org > Date: Sun, 14 Jan 2024 12:11:03 +0000 > > Eli Zaretskii writes: > > > I think it's an Org bug: it should prevent bidi reordering inside the > > "[[link]]" string. For example, wrap the "[[link]]" thing in LRO..PDF > > bidi controls. Because without that, the brackets can be mirrored by > > bidi reordering and the BPA algorithm, and the link is no longer in > > the form that Org expects. The result is that the entire text becomes > > invisible. > > May you please elaborate? I do not see anything unexpected in the text > properties that Org mode applies to the link and the letter "a". (For some value of "expected". Me, I don't understand more than half of the properties there, wrt their expected effect on the text and its display. Are you surprised?) Anyway, after performing the recipe, do this: . M-< . C-x = . C-f . C-x = . C-f . C-x = etc. IOW, move 1 buffer position forward at a time from BOB, and each time show the character at that position. Do you see something strange? Then do the same in a buffer under Fundamental mode with the same text and the same value of bidi-paragraph-direction. Can you explain what Org does to cause the difference, which makes some characters be "skipped" by C-f (due to point-adjustment feature), and probably also makes all the characters invisible as result? I can tell you what I see when stepping through the display code: it skips all the characters as invisible. I see that org-link is in the buffer-invisibility-spec, but that's probably just the tip of the iceberg, so I'm asking you below to describe what are all those faces and properties for, and how they are related to the invisibility. > In fact, after following the reproducer, and enabling visible-mode, M-x > describe-text-properties on "a" yields > > Text content at position 101: > > > There are text properties here: > fontified t > > Yet, "a" is rendered invisible. When you invoke visible-mode, the text is magically shown as expected. Can you explain why is that? If you invoke describe-text-properties on any character in the buffer, there's no character with 'invisible' face, either. And yet they are invisible. How come? If you describe in enough details how the [[link]] thing is handled by Org, maybe I could elaborate more than the general observations and questions above. To summarize, my point is simple: the Emacs bidirectional display is responsible for reordering plain text with faces, and while doing so, it more-or-less ignores invisible text. Anything fancier: overlays, images, text properties that affect display in some other ways, etc. -- all these are not guaranteed to behave in reordered text as they do in strict L2R text, and Lisp programs which create visual effects using those fancier features should look out for problems, and should use bidi formatting controls judiciously to prevent such disasters. (My guess is that the brackets in this case are reordered, and as result cause everything to become invisible. But that's just a guess, and I don't expect to understand why without a lot more background and help from Org experts.)