From unknown Mon Jun 23 11:28:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Resent-From: Thamer Mahmoud Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Sep 2010 11:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 6998 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 6998@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.12839447604233 (code B ref -1); Wed, 08 Sep 2010 11:20:02 +0000 Received: (at submit) by debbugs.gnu.org; 8 Sep 2010 11:19:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtIgS-00016E-3k for submit@debbugs.gnu.org; Wed, 08 Sep 2010 07:19:20 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGAG-0008MO-MM for submit@debbugs.gnu.org; Wed, 08 Sep 2010 04:37:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtGCA-0003Ym-K0 for submit@debbugs.gnu.org; Wed, 08 Sep 2010 04:39:55 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:39004) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGCA-0003Yg-Hx for submit@debbugs.gnu.org; Wed, 08 Sep 2010 04:39:54 -0400 Received: from [140.186.70.92] (port=35418 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtGC9-0007k2-8r for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 04:39:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtGC7-0003Xw-V1 for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 04:39:53 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:34348) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGC7-0003XT-Pe for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 04:39:51 -0400 Received: by wwb24 with SMTP id 24so8156884wwb.30 for ; Wed, 08 Sep 2010 01:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :mime-version:content-type:content-transfer-encoding:message-id:date :from:to:subject; bh=FFwPkdh1kYvz2VeTXsHTrdhdD5JFXavW5+/1ko++H78=; b=dvWUBEN4BlaDBcN7wrpe/cE3248BT+AEuHB30yiaVzFb7j6bpMkBY+B2icD/lsmuFh joFJAf/IhGCiaNCfK5/A/lq90X+es7cf8h6EhMDb43MDe+x/WReZKFizKXGjAj7gcA7E iF4Y663AFHzDRMjCaeaJyZ8T44K6eG+Kkb00k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:content-transfer-encoding:message-id:date :from:to:subject; b=dIHh5wZq0qwl6K+ybP8GvmLCJmlLQbKhM+SU9ZDmPrxUv9IEmdgG8sWtW2SciMNyyI H/5zI6hbDK7flhX0H0DSwT80kER8TD/f1lbXG0ijTUvTQvebwqyPwuD6d6L54ifOQ9xI A+Lwb6+VHih7tw0z/uv7x/QQv/RVWIi5TclUg= Received: by 10.216.35.75 with SMTP id t53mr447074wea.95.1283935162385; Wed, 08 Sep 2010 01:39:22 -0700 (PDT) Received: from matara.newkuwait.org ([89.203.6.209]) by mx.google.com with ESMTPS id k83sm4814890weq.38.2010.09.08.01.39.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 01:39:22 -0700 (PDT) Received: from zemblan.newkuwait.org ([192.168.1.3]) by matara.newkuwait.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGBb-0000WY-H1 for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 11:39:19 +0300 Received: from thamer by zemblan.newkuwait.org with local (Exim 4.72) (envelope-from ) id 1OtGBb-0000Pc-2c for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 11:39:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19591.19370.918828.700534@zemblan.newkuwait.org> Date: Wed, 8 Sep 2010 11:39:06 +0300 From: Thamer Mahmoud X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -5.9 (-----) X-Mailman-Approved-At: Wed, 08 Sep 2010 07:19:17 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) While investigating a crash I came across this problem. By default in Emacs, lines starting with Other Neutral types (in this case `*') seem to be following the direction of the line before them, and perhaps not being considered as separate paragraphs. This makes Emacs display files differently than the output of fribidi (gedit, etc). For example, I have a file with the following content: * ARABIC * abcdef I'd expect to see: CIBARA * * abcdef But in Emacs it's shown as: CIBARA * abcdef * Another example is: * First [BLANK_LINE] ARABIC * Second What I expect: * First [BLANK_LINE] CIBARA * Second What is shown in Emacs: * First [BLANK_LINE] CIBARA Second * This seems like a bug to me. Tests were done using -Q --eval "(setq-default bidi-display-reordering t)". In GNU Emacs 24.0.50.6 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-09-07 Thanks. -- Thamer From unknown Mon Jun 23 11:28:04 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Thamer Mahmoud Subject: bug#6998: closed (Re: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?) Message-ID: References: <19594.45400.927788.599350@zemblan.newkuwait.org> <19591.19370.918828.700534@zemblan.newkuwait.org> X-Gnu-PR-Message: they-closed 6998 X-Gnu-PR-Package: emacs Reply-To: 6998@debbugs.gnu.org Date: Fri, 10 Sep 2010 22:34:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1284158042-20214-1" This is a multi-part message in MIME format... ------------=_1284158042-20214-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #6998: 24.0.50; bidi: lines starting with neutral types have the wrong base= direction? which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 6998@debbugs.gnu.org. --=20 6998: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D6998 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1284158042-20214-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 6998-done) by debbugs.gnu.org; 10 Sep 2010 22:33:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OuC9f-0005Fj-Ah for submit@debbugs.gnu.org; Fri, 10 Sep 2010 18:33:11 -0400 Received: from mail-wy0-f172.google.com ([74.125.82.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OuC4W-0005D8-LD for 6998-done@debbugs.gnu.org; Fri, 10 Sep 2010 18:27:53 -0400 Received: by wyi11 with SMTP id 11so3241708wyi.3 for <6998-done@debbugs.gnu.org>; Fri, 10 Sep 2010 15:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :mime-version:content-type:content-transfer-encoding:message-id:date :from:to:subject; bh=zDvT7ywh6ZrkttxuprGqUx4of/oetm6Jaq6yDbYhkZ8=; b=EsKoJ09Z2PdatBXiP1e1Jz7RfE90+Rzi7ap3/XUE4LwKzSNCd/PuvO/pH0XL6Hj3mX MwJRr6p7TXkeJY0+KCD3c+Aen1EaDKC7LKHbpTcHIuMBGPh2VnxntyIWFjnXbX++BE6j 44M2D6ImaLRWCUakL7hoWBqaIzBU2R7L/RD4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:content-transfer-encoding:message-id:date :from:to:subject; b=npHmB0mo8DvFFOoEvgJXjX13uzzb5/n1A+F3qwLabsQAlvFnTXJ8xdoPthpC/lmf5/ 4UYQsSY3g6ItlwRFZ7Dz0jBPj+0aGQCGZ6cZg2/u363Rdejbbp0MBExnXJScMRW9foq4 cY9Mb7td5/GFZDz4zeD0uwmGRaxrUO4Lw5r08= Received: by 10.216.38.84 with SMTP id z62mr39757wea.70.1284157797083; Fri, 10 Sep 2010 15:29:57 -0700 (PDT) Received: from matara.newkuwait.org ([89.203.6.209]) by mx.google.com with ESMTPS id r18sm2076881weo.0.2010.09.10.15.29.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 15:29:56 -0700 (PDT) Received: from zemblan.newkuwait.org ([192.168.1.3]) by matara.newkuwait.org with esmtp (Exim 4.69) (envelope-from ) id 1OuC6Q-0002y2-HG for 6998-done@debbugs.gnu.org; Sat, 11 Sep 2010 01:29:50 +0300 Received: from thamer by zemblan.newkuwait.org with local (Exim 4.72) (envelope-from ) id 1OuC6Q-0005kQ-66 for 6998-done@debbugs.gnu.org; Sat, 11 Sep 2010 01:29:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19594.45400.927788.599350@zemblan.newkuwait.org> Date: Sat, 11 Sep 2010 01:29:44 +0300 From: Thamer Mahmoud To: 6998-done@debbugs.gnu.org Subject: Re: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: 6998-done X-Mailman-Approved-At: Fri, 10 Sep 2010 18:33:09 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.7 (---) I did some testing, and I found out that the differences between Emacs and other apps (fribidi, gedit, kwrite, etc) are explained by the other apps' use of "line-based reordering", while Emacs uses "paragraph-based reordering" (perhaps to avoid filled paragraphs having more than one direction). So I guess this is not a bug per se. However, I still see inconsistent rendering of the second example given above. But I'll file a more specific bug for that. Closing. -- Thamer ------------=_1284158042-20214-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 8 Sep 2010 11:19:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtIgS-00016E-3k for submit@debbugs.gnu.org; Wed, 08 Sep 2010 07:19:20 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGAG-0008MO-MM for submit@debbugs.gnu.org; Wed, 08 Sep 2010 04:37:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtGCA-0003Ym-K0 for submit@debbugs.gnu.org; Wed, 08 Sep 2010 04:39:55 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:39004) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGCA-0003Yg-Hx for submit@debbugs.gnu.org; Wed, 08 Sep 2010 04:39:54 -0400 Received: from [140.186.70.92] (port=35418 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtGC9-0007k2-8r for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 04:39:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtGC7-0003Xw-V1 for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 04:39:53 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:34348) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGC7-0003XT-Pe for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 04:39:51 -0400 Received: by wwb24 with SMTP id 24so8156884wwb.30 for ; Wed, 08 Sep 2010 01:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :mime-version:content-type:content-transfer-encoding:message-id:date :from:to:subject; bh=FFwPkdh1kYvz2VeTXsHTrdhdD5JFXavW5+/1ko++H78=; b=dvWUBEN4BlaDBcN7wrpe/cE3248BT+AEuHB30yiaVzFb7j6bpMkBY+B2icD/lsmuFh joFJAf/IhGCiaNCfK5/A/lq90X+es7cf8h6EhMDb43MDe+x/WReZKFizKXGjAj7gcA7E iF4Y663AFHzDRMjCaeaJyZ8T44K6eG+Kkb00k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:content-transfer-encoding:message-id:date :from:to:subject; b=dIHh5wZq0qwl6K+ybP8GvmLCJmlLQbKhM+SU9ZDmPrxUv9IEmdgG8sWtW2SciMNyyI H/5zI6hbDK7flhX0H0DSwT80kER8TD/f1lbXG0ijTUvTQvebwqyPwuD6d6L54ifOQ9xI A+Lwb6+VHih7tw0z/uv7x/QQv/RVWIi5TclUg= Received: by 10.216.35.75 with SMTP id t53mr447074wea.95.1283935162385; Wed, 08 Sep 2010 01:39:22 -0700 (PDT) Received: from matara.newkuwait.org ([89.203.6.209]) by mx.google.com with ESMTPS id k83sm4814890weq.38.2010.09.08.01.39.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 01:39:22 -0700 (PDT) Received: from zemblan.newkuwait.org ([192.168.1.3]) by matara.newkuwait.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGBb-0000WY-H1 for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 11:39:19 +0300 Received: from thamer by zemblan.newkuwait.org with local (Exim 4.72) (envelope-from ) id 1OtGBb-0000Pc-2c for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2010 11:39:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19591.19370.918828.700534@zemblan.newkuwait.org> Date: Wed, 8 Sep 2010 11:39:06 +0300 From: Thamer Mahmoud To: bug-gnu-emacs@gnu.org Subject: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 08 Sep 2010 07:19:17 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) While investigating a crash I came across this problem. By default in Emacs, lines starting with Other Neutral types (in this case `*') seem to be following the direction of the line before them, and perhaps not being considered as separate paragraphs. This makes Emacs display files differently than the output of fribidi (gedit, etc). For example, I have a file with the following content: * ARABIC * abcdef I'd expect to see: CIBARA * * abcdef But in Emacs it's shown as: CIBARA * abcdef * Another example is: * First [BLANK_LINE] ARABIC * Second What I expect: * First [BLANK_LINE] CIBARA * Second What is shown in Emacs: * First [BLANK_LINE] CIBARA Second * This seems like a bug to me. Tests were done using -Q --eval "(setq-default bidi-display-reordering t)". In GNU Emacs 24.0.50.6 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-09-07 Thanks. -- Thamer ------------=_1284158042-20214-1-- From unknown Mon Jun 23 11:28:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Sep 2010 12:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6998 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Thamer Mahmoud Cc: 6998@debbugs.gnu.org, thamer.mahmoud@gmail.com Reply-To: Eli Zaretskii Received: via spool by 6998-submit@debbugs.gnu.org id=B6998.128437936712961 (code B ref 6998); Mon, 13 Sep 2010 12:03:01 +0000 Received: (at 6998) by debbugs.gnu.org; 13 Sep 2010 12:02:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ov7kF-0003N0-Hw for submit@debbugs.gnu.org; Mon, 13 Sep 2010 08:02:47 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ov7kD-0003Mv-5W for 6998@debbugs.gnu.org; Mon, 13 Sep 2010 08:02:46 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0L8O00000PE2TG00@a-mtaout23.012.net.il> for 6998@debbugs.gnu.org; Mon, 13 Sep 2010 14:04:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.81.53]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L8O000OQPK4TM00@a-mtaout23.012.net.il>; Mon, 13 Sep 2010 14:04:54 +0200 (IST) Date: Mon, 13 Sep 2010 14:04:53 +0200 From: Eli Zaretskii In-reply-to: <19594.45400.927788.599350@zemblan.newkuwait.org> X-012-Sender: halo1@inter.net.il Message-id: <83tylt4zoa.fsf@gnu.org> References: <19591.19370.918828.700534@zemblan.newkuwait.org> <19594.45400.927788.599350@zemblan.newkuwait.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) > Date: Sat, 11 Sep 2010 01:29:44 +0300 > From: Thamer Mahmoud > Cc: > > I did some testing, and I found out that the differences between Emacs > and other apps (fribidi, gedit, kwrite, etc) are explained by the other > apps' use of "line-based reordering", while Emacs uses > "paragraph-based reordering" (perhaps to avoid filled paragraphs > having more than one direction). More accurately, the "paragraph" in fribidi etc. is a single line, because a linefeed is one of the paragraph separators. Since this would produce non-sensical display in any human-readable text that uses hard newlines, and because Emacs uses hard newlines in just about every derivative of Text mode, the Emacs implementation of the Unicode Bidirectional Algorithm uses what UAX#9 calls ``higher-level protocols'' to define what is the base embedding level of a paragraph. In Emacs, a paragraph is delimited by lines that are entirely whitespace or empty. This is explained in the "Bidirectional Editing" node of the Emacs manual. > So I guess this is not a bug per se. Right, not a bug; a feature. > However, I still see inconsistent rendering of the second example > given above. But I'll file a more specific bug for that. If you mean this example: > * First > [BLANK_LINE] > ARABIC > * Second > > What I expect: > > * First > [BLANK_LINE] > CIBARA > * Second > > What is shown in Emacs: > > * First > [BLANK_LINE] > CIBARA > Second * Then it is also expected behavior: since there's no blank line between "ARABIC" and "* Second", the latter is considered to belong to a right-to-left paragraph, and rendered accordingly. OTOH, "* First" and "ARABIC" _are_ separated by a blank line, so they belong to different paragraphs. You can control the paragraph direction by inserting the LRM and RLM characters in front of each paragraph. Alternatively, you can force a specific base direction on the entire buffer by setting the per-buffer variable bidi-paragraph-direction. This is also described in the manual. From unknown Mon Jun 23 11:28:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Resent-From: Thamer Mahmoud Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Sep 2010 14:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6998 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 6998@debbugs.gnu.org Received: via spool by 6998-submit@debbugs.gnu.org id=B6998.128499379219305 (code B ref 6998); Mon, 20 Sep 2010 14:44:01 +0000 Received: (at 6998) by debbugs.gnu.org; 20 Sep 2010 14:43:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxhaK-00051K-0x for submit@debbugs.gnu.org; Mon, 20 Sep 2010 10:43:12 -0400 Received: from mail-wy0-f172.google.com ([74.125.82.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxhaH-00051E-TO for 6998@debbugs.gnu.org; Mon, 20 Sep 2010 10:43:10 -0400 Received: by wyi11 with SMTP id 11so4327040wyi.3 for <6998@debbugs.gnu.org>; Mon, 20 Sep 2010 07:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :mime-version:content-type:content-transfer-encoding:message-id:date :from:to:cc:in-reply-to:references:subject; bh=XjVnALSspyqZiKj0Vx5WlV7uBuYHNKhcngzKCxXHkcI=; b=LtzxHzEeccso3J9uMBRWsWVXME4FbTlCMr0HIfGr70hsChM7JA0hb89DXzrlurH/w9 z4LcBJmEtgNO1hSIuqD42VRMl7OrCWgED7Yxrie/txjX2xBU1LK0SnCpx3wikRqLE7z+ 1FZE9gdBhsHUduH7TIkAVILpyfPw0KYKLy2SA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:content-transfer-encoding:message-id:date :from:to:cc:in-reply-to:references:subject; b=LEmfwZGciudxcMO5VtFPtdZ3+n5njI9MmuYQFs1vM8Q/0neV7eeZUG9fWm6UIWCSRe V71SSYv5Rwz6eyCnTYsfCsE/XTaNxd6XXqUgg395BFCc0DEuVM/f0CjtBa+gEhTIxOYt IOA5+m23mYmI4UiyX+sFOSQxjVYo0/Q+IjC70= Received: by 10.227.145.149 with SMTP id d21mr2009315wbv.149.1284993938842; Mon, 20 Sep 2010 07:45:38 -0700 (PDT) Received: from matara.newkuwait.org ([89.203.6.209]) by mx.google.com with ESMTPS id e31sm6056626wbe.11.2010.09.20.07.45.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Sep 2010 07:45:36 -0700 (PDT) Received: from zemblan.newkuwait.org ([192.168.1.3]) by matara.newkuwait.org with esmtp (Exim 4.69) (envelope-from ) id 1Oxhcb-0004XS-8H; Mon, 20 Sep 2010 17:45:33 +0300 Received: from thamer by zemblan.newkuwait.org with local (Exim 4.72) (envelope-from ) id 1Oxhca-0008H1-Vv; Mon, 20 Sep 2010 17:45:32 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19607.29548.870306.576702@zemblan.newkuwait.org> Date: Mon, 20 Sep 2010 17:45:00 +0300 From: Thamer Mahmoud In-Reply-To: <83tylt4zoa.fsf@gnu.org> References: <19591.19370.918828.700534@zemblan.newkuwait.org> <19594.45400.927788.599350@zemblan.newkuwait.org> <83tylt4zoa.fsf@gnu.org> X-Spam-Score: -3.1 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) Eli Zaretskii writes: > > If you mean this example: > > > * First > > [BLANK_LINE] > > ARABIC > > * Second > > > > What I expect: > > > > * First > > [BLANK_LINE] > > CIBARA > > * Second > > > > What is shown in Emacs: > > > > * First > > [BLANK_LINE] > > CIBARA > > Second * > > Then it is also expected behavior: since there's no blank line between > "ARABIC" and "* Second", the latter is considered to belong to a > right-to-left paragraph, and rendered accordingly. Thanks for your comments, Eli. I do mean the above example, as I can see some inconsistent behavior when using org-mode. It seems that Emacs _sometimes_ renders the above example in org-mode as, * First... * Second While in other invocations the same file is rendered as: * First... Second * This behavior is not always reproducible. In X11, I have used the following command to start 5 Emacs sessions with some having the first rendering and others the second rendering: i=5; while [ $i -gt 0 ] ; do ./emacs -Q --eval "(setq-default bidi-display-reordering t)" example2.org & let i=i-1; done; I can also see a bug and a crash with the second rendering (and it got me confused about how Emacs handles neutral types), so I wonder which rendering should be considered as "correct"? -- Thamer From unknown Mon Jun 23 11:28:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Sep 2010 19:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6998 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Thamer Mahmoud Cc: 6998@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 6998-submit@debbugs.gnu.org id=B6998.128500952529109 (code B ref 6998); Mon, 20 Sep 2010 19:06:02 +0000 Received: (at 6998) by debbugs.gnu.org; 20 Sep 2010 19:05:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oxlg4-0007ZS-Um for submit@debbugs.gnu.org; Mon, 20 Sep 2010 15:05:25 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oxlg1-0007ZN-HT for 6998@debbugs.gnu.org; Mon, 20 Sep 2010 15:05:22 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L92007007DL6100@a-mtaout20.012.net.il> for 6998@debbugs.gnu.org; Mon, 20 Sep 2010 21:07:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.210.149]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L92006AW7T064E0@a-mtaout20.012.net.il>; Mon, 20 Sep 2010 21:07:49 +0200 (IST) Date: Mon, 20 Sep 2010 21:07:49 +0200 From: Eli Zaretskii In-reply-to: <19607.29548.870306.576702@zemblan.newkuwait.org> X-012-Sender: halo1@inter.net.il Message-id: <83hbhkxmgq.fsf@gnu.org> References: <19591.19370.918828.700534@zemblan.newkuwait.org> <19594.45400.927788.599350@zemblan.newkuwait.org> <83tylt4zoa.fsf@gnu.org> <19607.29548.870306.576702@zemblan.newkuwait.org> X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Mon, 20 Sep 2010 17:45:00 +0300 > From: Thamer Mahmoud > Cc: 6998@debbugs.gnu.org > > Thanks for your comments, Eli. I do mean the above example, as I can > see some inconsistent behavior when using org-mode. A reproducible test case, preferably starting with "emacs -Q", would be greatly appreciated. > It seems that Emacs _sometimes_ renders the above example in org-mode > as, > > * First... > * Second > > While in other invocations the same file is rendered as: > > * First... > Second * Sorry, I don't understand. Your original example included a line in ARABIC and an empty line, in addition to "First" and "second" lines. Are we talking about a different example now? If not, please show how the example is rendered in its entirety, in the two different behaviors you observe. > I can also see a bug and a crash with the second rendering (and it got > me confused about how Emacs handles neutral types) Could you pots a backtrace when in crashes? > so I wonder which rendering should be considered as "correct"? For your original example: * First [BLANK_LINE] ARABIC * Second the correct rendering is this: * First [BLANK_LINE] CIBARA Second * For the example you show now: * First * Second the correct rendering is what you'd expect: * First * Second From unknown Mon Jun 23 11:28:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Resent-From: Thamer Mahmoud Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Sep 2010 02:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6998 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 6998@debbugs.gnu.org Received: via spool by 6998-submit@debbugs.gnu.org id=B6998.128512417018712 (code B ref 6998); Wed, 22 Sep 2010 02:57:02 +0000 Received: (at 6998) by debbugs.gnu.org; 22 Sep 2010 02:56:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OyFVA-0004rl-Mg for submit@debbugs.gnu.org; Tue, 21 Sep 2010 22:56:10 -0400 Received: from mail-fx0-f44.google.com ([209.85.161.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OyFV7-0004rO-Vo for 6998@debbugs.gnu.org; Tue, 21 Sep 2010 22:56:07 -0400 Received: by fxm6 with SMTP id 6so58535fxm.3 for <6998@debbugs.gnu.org>; Tue, 21 Sep 2010 19:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :mime-version:content-type:content-transfer-encoding:message-id:date :from:to:cc:in-reply-to:references:subject; bh=K9a9dYo/dkBBeJ4k6MqJQ+WEUCaZKl7KaLFiEj4P1Hk=; b=hDwM/l9F7brxGWla0ghaaYGPwz7WCHoMHQ6ypUGalERBqYURusBxj5Bn0DsNqCexjf 0XkyothjvCGQVkhVcbLFrWsO2LJy167zaITaSWHO2MeztgZlx+7ZaFT8GixJRwwII2fp +D/dCyPT89js3IPCFsrCMEkhF9FFDiE10BMtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:content-transfer-encoding:message-id:date :from:to:cc:in-reply-to:references:subject; b=YChMMDZMVDIuy7E2YO37pNj5HK2Vx+AeYdMySIEoQFwdHCk/9wfOSMgD3HDPjP9tMI SY9L9w0D03/QAgnMiEpNw04ygzSQJxlP3SzL8SqsN7LxlRJE9B74lrVRcwn9Qfz53RGs Iuy92BGRSYDjbUD4kvIOc7roJ0EQ1QX7w2ULU= Received: by 10.223.124.4 with SMTP id s4mr7217905far.31.1285124319552; Tue, 21 Sep 2010 19:58:39 -0700 (PDT) Received: from matara.newkuwait.org ([89.203.6.209]) by mx.google.com with ESMTPS id e17sm3992553faa.15.2010.09.21.19.58.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Sep 2010 19:58:36 -0700 (PDT) Received: from zemblan.newkuwait.org ([192.168.1.3]) by matara.newkuwait.org with esmtp (Exim 4.69) (envelope-from ) id 1OyFXV-00060F-EY; Wed, 22 Sep 2010 05:58:33 +0300 Received: from thamer by zemblan.newkuwait.org with local (Exim 4.72) (envelope-from ) id 1OyFXV-0008HK-8G; Wed, 22 Sep 2010 05:58:33 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NjcPelWKZ5" Content-Transfer-Encoding: 7bit Message-ID: <19609.28881.213914.115083@zemblan.newkuwait.org> Date: Wed, 22 Sep 2010 05:58:25 +0300 From: Thamer Mahmoud In-Reply-To: <83hbhkxmgq.fsf@gnu.org> References: <19591.19370.918828.700534@zemblan.newkuwait.org> <19594.45400.927788.599350@zemblan.newkuwait.org> <83tylt4zoa.fsf@gnu.org> <19607.29548.870306.576702@zemblan.newkuwait.org> <83hbhkxmgq.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) --NjcPelWKZ5 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Eli Zaretskii writes: > A reproducible test case, preferably starting with "emacs -Q", would > be greatly appreciated. > Note that both the crash and the bug (mentioned further below) were not reproducible on a virtual Windows XP. To reproduce this crash: 1. Open attached test case with: emacs -Q --eval "(setq-default bidi-display-reordering t)" wrap_crash.org It should open in org-mode by default. 2. Emacs _sometimes_ would render it like this: * First... ...Second * If not, repeat step one until it does, or use something similar to the command I provided in my last message, etc. 3. Once you see the above, do: M-x visual-line-mode [ENTER] C-n C-n > > It seems that Emacs _sometimes_ renders the above example in org-mode > > as, > > > > * First... > > * Second > > > > While in other invocations the same file is rendered as: > > > > * First... > > Second * > > Sorry, I don't understand. Your original example included a line in > ARABIC and an empty line, in addition to "First" and "second" lines. > Are we talking about a different example now? No, it's the same example just viewed using org-mode (which considers lines that start with `*' as headers, and does some folding). > For the example you show now: > > * First > * Second > > the correct rendering is what you'd expect: > > * First > * Second Would this apply to org-mode wrt to the attached testcase? As a side bug, if you position cursor on "* First" in the testcase then press [TAB] you will see that "* Second" gets deformed to: d *... Testcase and backtrace attached. Thanks. --NjcPelWKZ5 Content-Type: text/plain; name="wrap_crash.org"; charset=utf-8 Content-Description: testcase Content-Disposition: inline; filename="wrap_crash.org" Content-Transfer-Encoding: quoted-printable * First =D8=B9=D8=B1=D8=A8=D9=8A * Second =D8=B9=D8=B1=D8=A8=D9=8A --NjcPelWKZ5 Content-Type: text/plain; name="wrap_crash_backtrace.txt" Content-Description: backtrace Content-Disposition: inline; filename="wrap_crash_backtrace.txt" Content-Transfer-Encoding: quoted-printable bt full #0 abort () at emacs.c:427 No locals. #1 0x080f4aa0 in bidi_level_of_next_char (bidi_it=3D0xbfffdd3c) at bidi.c:= 1492 type =3D UNKNOWN_BT level =3D 0 prev_level =3D -1 next_for_neutral =3D { bytepos =3D 21,=20 charpos =3D 17,=20 type =3D UNKNOWN_BT,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L } #2 0x080f5079 in bidi_move_to_visually_next (bidi_it=3D0xbfffdd3c) at bidi= .c:1689 old_level =3D 2 new_level =3D 0 next_level =3D 0 sentinel =3D { bytepos =3D 0,=20 charpos =3D 0,=20 ch =3D 0,=20 ch_len =3D 0,=20 type =3D UNKNOWN_BT,=20 type_after_w1 =3D STRONG_R,=20 orig_type =3D UNKNOWN_BT,=20 resolved_level =3D 0,=20 invalid_levels =3D 0,=20 invalid_rl_levels =3D 1,=20 prev_was_pdf =3D 26,=20 prev =3D { bytepos =3D 22,=20 charpos =3D 100,=20 type =3D STRONG_L,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 last_strong =3D { bytepos =3D 1,=20 charpos =3D 2,=20 type =3D UNKNOWN_BT,=20 type_after_w1 =3D 4294967295,=20 orig_type =3D UNKNOWN_BT },=20 next_for_neutral =3D { bytepos =3D 25,=20 charpos =3D 21,=20 type =3D STRONG_L,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 prev_for_neutral =3D { bytepos =3D 25,=20 charpos =3D 21,=20 type =3D STRONG_L,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 next_for_ws =3D { bytepos =3D 21,=20 charpos =3D 17,=20 type =3D UNKNOWN_BT,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 next_en_pos =3D 25,=20 ignore_bn_limit =3D 21,=20 sor =3D L2R,=20 scan_dir =3D 1,=20 stack_idx =3D 1,=20 level_stack =3D {{ level =3D 0,=20 override =3D NEUTRAL_DIR }, { level =3D 0,=20 override =3D NEUTRAL_DIR }, { level =3D 0,=20 override =3D 4294967295 }, { level =3D 0,=20 override =3D R2L }, { level =3D -1,=20 override =3D NEUTRAL_DIR }, { level =3D 1,=20 override =3D NEUTRAL_DIR }, { level =3D 0,=20 override =3D NEUTRAL_DIR } },=20 first_elt =3D 0,=20 paragraph_dir =3D NEUTRAL_DIR,=20 new_paragraph =3D 0,=20 separator_limit =3D 0 } #3 0x0807990c in set_iterator_to_next (it=3D0xbfffd79c, reseat_p=3D1) at x= disp.c:6206 prev_scan_dir =3D -1 #4 0x0807cb7a in move_it_to (it=3D0xbfffd79c, to_charpos=3D22, to_x=3D-1, = to_y=3D-1, to_vpos=3D-1, op=3D8) at xdisp.c:7568 skip =3D MOVE_NEWLINE_OR_CR skip2 =3D MOVE_X_REACHED line_height =3D -1073749936 line_start_x =3D 0 reached =3D 0 #5 0x0807258b in start_display (it=3D0xbfffd79c, w=3D0x86f29b8, pos=3D...)= at xdisp.c:2851 new_x =3D -1213421424 start_at_line_beg_p =3D 0 first_y =3D 0 row =3D 0x8ade608 first_vpos =3D 0 #6 0x081ad97f in Fvertical_motion (lines=3D4, window=3D141502909) at inden= t.c:2044 it_start =3D -1073749976 first_x =3D 134923737 it_overshoot_expected =3D 138805418 it =3D { window =3D 141502909,=20 w =3D 0x86f29b8,=20 f =3D 0x86f2830,=20 method =3D GET_FROM_BUFFER,=20 stop_charpos =3D 23,=20 prev_stop =3D 0,=20 base_level_stop =3D 0,=20 end_charpos =3D 29,=20 s =3D 0x0,=20 string_nchars =3D 0,=20 region_beg_charpos =3D -1,=20 region_end_charpos =3D -1,=20 redisplay_end_trigger_charpos =3D 0,=20 multibyte_p =3D 1,=20 header_line_p =3D 0,=20 string_from_display_prop_p =3D 0,=20 ellipsis_p =3D 0,=20 avoid_cursor_p =3D 0,=20 dp =3D 0x0,=20 dpvec =3D 0x0,=20 dpend =3D 0x0,=20 dpvec_char_len =3D 0,=20 dpvec_face_id =3D 0,=20 saved_face_id =3D 13,=20 ctl_chars =3D {0 },=20 start =3D { pos =3D { charpos =3D 22,=20 bytepos =3D 26 },=20 overlay_string_index =3D -1,=20 string_pos =3D { charpos =3D -1,=20 bytepos =3D -1 },=20 dpvec_index =3D -1 },=20 current =3D { pos =3D { charpos =3D 22,=20 bytepos =3D 26 },=20 overlay_string_index =3D -1,=20 string_pos =3D { charpos =3D -1,=20 bytepos =3D -1 },=20 dpvec_index =3D -1 },=20 n_overlay_strings =3D 0,=20 overlay_strings =3D {0 },=20 string_overlays =3D {0 },=20 string =3D 138805418,=20 from_overlay =3D 0,=20 stack =3D {{ string =3D 0,=20 string_nchars =3D 0,=20 end_charpos =3D 0,=20 stop_charpos =3D 0,=20 prev_stop =3D 0,=20 base_level_stop =3D 0,=20 cmp_it =3D { stop_pos =3D 0,=20 id =3D 0,=20 ch =3D 0,=20 rule_idx =3D 0,=20 lookback =3D 0,=20 nglyphs =3D 0,=20 reversed_p =3D 0,=20 charpos =3D 0,=20 nchars =3D 0,=20 nbytes =3D 0,=20 from =3D 0,=20 to =3D 0,=20 width =3D 0 },=20 face_id =3D 0,=20 u =3D { image =3D { object =3D 0,=20 slice =3D { x =3D 0,=20 y =3D 0,=20 width =3D 0,=20 height =3D 0 },=20 image_id =3D 0 },=20 comp =3D { object =3D 0 },=20 stretch =3D { object =3D 0 } },=20 position =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 current =3D { pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 overlay_string_index =3D 0,=20 string_pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 dpvec_index =3D 0 },=20 from_overlay =3D 0,=20 area =3D LEFT_MARGIN_AREA,=20 method =3D GET_FROM_BUFFER,=20 multibyte_p =3D 0,=20 string_from_display_prop_p =3D 0,=20 display_ellipsis_p =3D 0,=20 avoid_cursor_p =3D 0,=20 line_wrap =3D TRUNCATE,=20 voffset =3D 0,=20 space_width =3D 0,=20 font_height =3D 0 }, { string =3D 0,=20 string_nchars =3D 0,=20 end_charpos =3D 0,=20 stop_charpos =3D 0,=20 prev_stop =3D 0,=20 base_level_stop =3D 0,=20 cmp_it =3D { stop_pos =3D 0,=20 id =3D 0,=20 ch =3D 0,=20 rule_idx =3D 0,=20 lookback =3D 0,=20 nglyphs =3D 0,=20 reversed_p =3D 0,=20 charpos =3D 0,=20 nchars =3D 0,=20 nbytes =3D 0,=20 from =3D 0,=20 to =3D 0,=20 width =3D 0 },=20 face_id =3D 0,=20 u =3D { image =3D { object =3D 0,=20 slice =3D { x =3D 0,=20 y =3D 0,=20 width =3D 0,=20 height =3D 0 },=20 image_id =3D 0 },=20 comp =3D { object =3D 0 },=20 stretch =3D { object =3D 0 } },=20 position =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 current =3D { pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 overlay_string_index =3D 0,=20 string_pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 dpvec_index =3D 0 },=20 from_overlay =3D 0,=20 area =3D LEFT_MARGIN_AREA,=20 method =3D GET_FROM_BUFFER,=20 multibyte_p =3D 0,=20 string_from_display_prop_p =3D 0,=20 display_ellipsis_p =3D 0,=20 avoid_cursor_p =3D 0,=20 line_wrap =3D TRUNCATE,=20 voffset =3D 0,=20 space_width =3D 0,=20 font_height =3D 0 }, { string =3D 0,=20 string_nchars =3D 0,=20 end_charpos =3D 0,=20 stop_charpos =3D 0,=20 prev_stop =3D 0,=20 base_level_stop =3D 0,=20 cmp_it =3D { stop_pos =3D 0,=20 id =3D 0,=20 ch =3D 0,=20 rule_idx =3D 0,=20 lookback =3D 0,=20 nglyphs =3D 0,=20 reversed_p =3D 0,=20 charpos =3D 0,=20 nchars =3D 0,=20 nbytes =3D 0,=20 from =3D 0,=20 to =3D 0,=20 width =3D 0 },=20 face_id =3D 0,=20 u =3D { image =3D { object =3D 0,=20 slice =3D { x =3D 0,=20 y =3D 0,=20 width =3D 0,=20 height =3D 0 },=20 image_id =3D 0 },=20 comp =3D { object =3D 0 },=20 stretch =3D { object =3D 0 } },=20 position =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 current =3D { pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 overlay_string_index =3D 0,=20 string_pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 dpvec_index =3D 0 },=20 from_overlay =3D 0,=20 area =3D LEFT_MARGIN_AREA,=20 method =3D GET_FROM_BUFFER,=20 multibyte_p =3D 0,=20 string_from_display_prop_p =3D 0,=20 display_ellipsis_p =3D 0,=20 avoid_cursor_p =3D 0,=20 line_wrap =3D TRUNCATE,=20 voffset =3D 0,=20 space_width =3D 0,=20 font_height =3D 0 }, { string =3D 0,=20 string_nchars =3D 0,=20 end_charpos =3D 0,=20 stop_charpos =3D 0,=20 prev_stop =3D 0,=20 base_level_stop =3D 0,=20 cmp_it =3D { stop_pos =3D 0,=20 id =3D 0,=20 ch =3D 0,=20 rule_idx =3D 0,=20 lookback =3D 0,=20 nglyphs =3D 0,=20 reversed_p =3D 0,=20 charpos =3D 0,=20 nchars =3D 0,=20 nbytes =3D 0,=20 from =3D 0,=20 to =3D 0,=20 width =3D 0 },=20 face_id =3D 0,=20 u =3D { image =3D { object =3D 0,=20 slice =3D { x =3D 0,=20 y =3D 0,=20 width =3D 0,=20 height =3D 0 },=20 image_id =3D 0 },=20 comp =3D { object =3D 0 },=20 stretch =3D { object =3D 0 } },=20 position =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 current =3D { pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 overlay_string_index =3D 0,=20 string_pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 dpvec_index =3D 0 },=20 from_overlay =3D 0,=20 area =3D LEFT_MARGIN_AREA,=20 method =3D GET_FROM_BUFFER,=20 multibyte_p =3D 0,=20 string_from_display_prop_p =3D 0,=20 display_ellipsis_p =3D 0,=20 avoid_cursor_p =3D 0,=20 line_wrap =3D TRUNCATE,=20 voffset =3D 0,=20 space_width =3D 0,=20 font_height =3D 0 }, { string =3D 0,=20 string_nchars =3D 0,=20 end_charpos =3D 0,=20 stop_charpos =3D 0,=20 prev_stop =3D 0,=20 base_level_stop =3D 0,=20 cmp_it =3D { stop_pos =3D 0,=20 id =3D 0,=20 ch =3D 0,=20 rule_idx =3D 0,=20 lookback =3D 0,=20 nglyphs =3D 0,=20 reversed_p =3D 0,=20 charpos =3D 0,=20 nchars =3D 0,=20 nbytes =3D 0,=20 from =3D 0,=20 to =3D 0,=20 width =3D 0 },=20 face_id =3D 0,=20 u =3D { image =3D { object =3D 0,=20 slice =3D { x =3D 0,=20 y =3D 0,=20 width =3D 0,=20 height =3D 0 },=20 image_id =3D 0 },=20 comp =3D { object =3D 0 },=20 stretch =3D { object =3D 0 } },=20 position =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 current =3D { pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 overlay_string_index =3D 0,=20 string_pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 dpvec_index =3D 0 },=20 from_overlay =3D 0,=20 area =3D LEFT_MARGIN_AREA,=20 method =3D GET_FROM_BUFFER,=20 multibyte_p =3D 0,=20 string_from_display_prop_p =3D 0,=20 display_ellipsis_p =3D 0,=20 avoid_cursor_p =3D 0,=20 line_wrap =3D TRUNCATE,=20 voffset =3D 0,=20 space_width =3D 0,=20 font_height =3D 0 }},=20 sp =3D 0,=20 selective =3D 0,=20 what =3D IT_CHARACTER,=20 face_id =3D 13,=20 selective_display_ellipsis_p =3D 1,=20 ctl_arrow_p =3D 1,=20 face_box_p =3D 0,=20 start_of_box_run_p =3D 0,=20 end_of_box_run_p =3D 0,=20 overlay_strings_at_end_processed_p =3D 0,=20 ignore_overlay_strings_at_pos_p =3D 0,=20 glyph_not_available_p =3D 0,=20 starts_in_middle_of_char_p =3D 0,=20 face_before_selective_p =3D 0,=20 constrain_row_ascent_descent_p =3D 0,=20 line_wrap =3D WORD_WRAP,=20 base_face_id =3D 0,=20 c =3D 100,=20 len =3D 1,=20 cmp_it =3D { stop_pos =3D 15,=20 id =3D -1,=20 ch =3D -2,=20 rule_idx =3D 0,=20 lookback =3D 0,=20 nglyphs =3D 0,=20 reversed_p =3D 0,=20 charpos =3D 0,=20 nchars =3D 0,=20 nbytes =3D 0,=20 from =3D 0,=20 to =3D 0,=20 width =3D 0 },=20 char_to_display =3D 100,=20 image_id =3D 0,=20 slice =3D { x =3D 138805418,=20 y =3D 138805418,=20 width =3D 138805418,=20 height =3D 138805418 },=20 space_width =3D 138805418,=20 voffset =3D 0,=20 tab_width =3D 8,=20 font_height =3D 138805418,=20 object =3D 143782445,=20 position =3D { charpos =3D 22,=20 bytepos =3D 26 },=20 truncation_pixel_width =3D 0,=20 continuation_pixel_width =3D 0,=20 first_visible_x =3D 0,=20 last_visible_x =3D 984,=20 last_visible_y =3D 646,=20 extra_line_spacing =3D 0,=20 max_extra_line_spacing =3D 0,=20 override_ascent =3D -1,=20 override_descent =3D 0,=20 override_boff =3D 0,=20 glyph_row =3D 0x8ade608,=20 area =3D TEXT_AREA,=20 nglyphs =3D 1,=20 pixel_width =3D 8,=20 ascent =3D 13,=20 descent =3D 4,=20 max_ascent =3D 13,=20 max_descent =3D 4,=20 phys_ascent =3D 11,=20 phys_descent =3D 0,=20 max_phys_ascent =3D 11,=20 max_phys_descent =3D 0,=20 current_x =3D 16,=20 continuation_lines_width =3D 0,=20 eol_pos =3D { charpos =3D 0,=20 bytepos =3D 0 },=20 current_y =3D 0,=20 first_vpos =3D 0,=20 vpos =3D 0,=20 hpos =3D 2,=20 left_user_fringe_bitmap =3D 0,=20 right_user_fringe_bitmap =3D 0,=20 left_user_fringe_face_id =3D 0,=20 right_user_fringe_face_id =3D 0,=20 bidi_p =3D 1,=20 bidi_it =3D { bytepos =3D 26,=20 charpos =3D 22,=20 ch =3D 100,=20 ch_len =3D 1,=20 type =3D STRONG_L,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L,=20 resolved_level =3D 2,=20 invalid_levels =3D 0,=20 invalid_rl_levels =3D -1,=20 prev_was_pdf =3D 0,=20 prev =3D { bytepos =3D 25,=20 charpos =3D 21,=20 type =3D STRONG_L,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 last_strong =3D { bytepos =3D 25,=20 charpos =3D 21,=20 type =3D STRONG_L,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 next_for_neutral =3D { bytepos =3D 21,=20 charpos =3D 17,=20 type =3D UNKNOWN_BT,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 prev_for_neutral =3D { bytepos =3D 25,=20 charpos =3D 21,=20 type =3D STRONG_L,=20 type_after_w1 =3D STRONG_L,=20 orig_type =3D STRONG_L },=20 next_for_ws =3D { bytepos =3D 0,=20 charpos =3D 0,=20 type =3D UNKNOWN_BT,=20 type_after_w1 =3D UNKNOWN_BT,=20 orig_type =3D UNKNOWN_BT },=20 next_en_pos =3D -1,=20 ignore_bn_limit =3D 0,=20 sor =3D R2L,=20 scan_dir =3D -1,=20 stack_idx =3D 0,=20 level_stack =3D {{ level =3D 1,=20 override =3D NEUTRAL_DIR }, { level =3D 0,=20 override =3D NEUTRAL_DIR } },=20 first_elt =3D 0,=20 paragraph_dir =3D R2L,=20 new_paragraph =3D 0,=20 separator_limit =3D -1 },=20 paragraph_embedding =3D NEUTRAL_DIR } pt =3D { charpos =3D 22,=20 bytepos =3D 26 } w =3D 0x86f29b8 old_buffer =3D 138805418 gcpro1 =3D { next =3D 0x8ba1208,=20 var =3D 0xb7aca470,=20 nvars =3D -1213422480 } lcols =3D 139263071 cols =3D 0 #7 0x081e739f in Ffuncall (nargs=3D2, args=3D0xbfffe100) at eval.c:2993 fun =3D 136848109 original_fun =3D 138942282 funcar =3D 136119380 numargs =3D 1 lisp_numargs =3D 146769790 val =3D -1073749784 backtrace =3D { next =3D 0xbfffe360,=20 function =3D 0xbfffe100,=20 args =3D 0xbfffe104,=20 nargs =3D 1,=20 evalargs =3D 0 '\000',=20 debug_on_exit =3D 0 '\000' } internal_args =3D 0xbfffe050 i =3D 2 #8 0x082265cf in Fbyte_code (bytestr=3D137280161, vector=3D137280181, maxd= epth=3D20) at bytecode.c:679 count =3D 13 op =3D 1 vectorp =3D 0x82ebab8 bytestr_length =3D 178 stack =3D { pc =3D 0x83d14ce "\016\032U\203\233",=20 top =3D 0xbfffe104,=20 bottom =3D 0xbfffe100,=20 byte_string =3D 137280161,=20 byte_string_start =3D 0x83d1451 "`\306 \307\030\031\032\v:\203)",= =20 constants =3D 137280181,=20 next =3D 0xbfffe3f0 } top =3D 0xbfffe100 result =3D 138805418 #9 0x081e7b74 in funcall_lambda (fun=3D137280125, nargs=3D2, arg_vector=3D= 0xbfffe3c4) at eval.c:3174 val =3D 138805418 syms_left =3D 138805418 next =3D 139163650 count =3D 11 i =3D 2 optional =3D 1 rest =3D 0 #10 0x081e759e in Ffuncall (nargs=3D3, args=3D0xbfffe3c0) at eval.c:3036 fun =3D 137280125 original_fun =3D 139924906 funcar =3D 136119380 numargs =3D 2 lisp_numargs =3D 141033928 val =3D 0 backtrace =3D { next =3D 0xbfffe610,=20 function =3D 0xbfffe3c0,=20 args =3D 0xbfffe3c4,=20 nargs =3D 2,=20 evalargs =3D 0 '\000',=20 debug_on_exit =3D 0 '\000' } internal_args =3D 0x2 i =3D -1073748364 #11 0x082265cf in Fbyte_code (bytestr=3D137280017, vector=3D137280037, maxd= epth=3D16) at bytecode.c:679 count =3D 11 op =3D 2 vectorp =3D 0x82eba28 bytestr_length =3D 59 stack =3D { pc =3D 0x83d1546 "\207\316\n\r\016\017#\207",=20 top =3D 0xbfffe3c8,=20 bottom =3D 0xbfffe3c0,=20 byte_string =3D 137280017,=20 byte_string_start =3D 0x83d1513 "\b\205 ",=20 constants =3D 137280037,=20 next =3D 0xbfffe6b0 } top =3D 0xbfffe3c0 result =3D -1217735736 #12 0x081e7b74 in funcall_lambda (fun=3D137279965, nargs=3D4, arg_vector=3D= 0xbfffe674) at eval.c:3174 val =3D 139065208 syms_left =3D 138805418 next =3D 139924762 count =3D 7 i =3D 4 optional =3D 1 rest =3D 0 #13 0x081e759e in Ffuncall (nargs=3D5, args=3D0xbfffe670) at eval.c:3036 fun =3D 137279965 original_fun =3D 139924786 funcar =3D -1215831512 numargs =3D 4 lisp_numargs =3D 0 val =3D -1073748296 backtrace =3D { next =3D 0xbfffe8c8,=20 function =3D 0xbfffe670,=20 args =3D 0xbfffe674,=20 nargs =3D 4,=20 evalargs =3D 0 '\000',=20 debug_on_exit =3D 0 '\000' } internal_args =3D 0x2 i =3D 136469991 #14 0x082265cf in Fbyte_code (bytestr=3D137279217, vector=3D137279245, maxd= epth=3D20) at bytecode.c:679 count =3D 7 op =3D 4 vectorp =3D 0x82eb710 bytestr_length =3D 7 stack =3D { pc =3D 0x83d170c "\207",=20 top =3D 0xbfffe680,=20 bottom =3D 0xbfffe670,=20 byte_string =3D 137279217,=20 byte_string_start =3D 0x83d1706 "\302\b=C3=89\t$\207",=20 constants =3D 137279245,=20 next =3D 0xbfffea90 } top =3D 0xbfffe670 result =3D -1073748040 #15 0x081e6361 in Feval (form=3D137279206) at eval.c:2358 numargs =3D 12 args_left =3D 138805418 i =3D 136469991 maxargs =3D 3 argvals =3D {137279217, 137279245, 20, 138805418, 138805418, 0, 0, = -1073747484} fun =3D 138485149 val =3D 12 original_fun =3D 138930242 original_args =3D 137279214 funcar =3D -1073747828 backtrace =3D { next =3D 0xbfffecb0,=20 function =3D 0xbfffe8e0,=20 args =3D 0xbfffe884,=20 nargs =3D 3,=20 evalargs =3D 1 '\001',=20 debug_on_exit =3D 0 '\000' } gcpro1 =3D { next =3D 0xbfffe848,=20 var =3D 0x839122a,=20 nvars =3D 0 } gcpro2 =3D { next =3D 0x816c718,=20 var =3D 0x1,=20 nvars =3D -1073747132 } gcpro3 =3D { next =3D 0x0,=20 var =3D 0xbfffe884,=20 nvars =3D 3 } #16 0x081e4b82 in internal_lisp_condition_case (var=3D139166106, bodyform= =3D137279206, handlers=3D137279270) at eval.c:1407 val =3D 138805418 c =3D { tag =3D 138805418,=20 val =3D 138805418,=20 next =3D 0xbffff1a4,=20 gcpro =3D 0x0,=20 jmp =3D {{ __jmpbuf =3D {-1073746588, -1073746584, -1073744732, -1073747= 400, 1672471279, -1595400832},=20 __mask_was_saved =3D 0,=20 __saved_mask =3D { __val =3D {3221220164, 3221219476, 3221222564, 3221219896, = 136213374, 138921242, 142554630, 3221219476, 396883, 0, 0, 0, 138805418, 0,= 0, 3221219368, 4294967266, 497502, 0, 332839, 1285052478, 446709, 0, 33283= 9, 11, 3221220528, 3221219920, 3221219924, 1, 0, 138479965, 138922218} } }},=20 backlist =3D 0xbfffecb0,=20 handlerlist =3D 0xbffff190,=20 lisp_eval_depth =3D 2,=20 pdlcount =3D 7,=20 poll_suppress_count =3D 1,=20 interrupt_input_blocked =3D 0,=20 byte_stack =3D 0xbfffea90 } h =3D { handler =3D 137279270,=20 var =3D 139166106,=20 chosen_clause =3D 138805418,=20 tag =3D 0xbfffe960,=20 next =3D 0xbffff190 } #17 0x08227325 in Fbyte_code (bytestr=3D137279113, vector=3D137279133, maxd= epth=3D24) at bytecode.c:869 handlers =3D 137279270 body =3D 137279206 count =3D 7 op =3D 143 vectorp =3D 0x82eb6a0 bytestr_length =3D 78 stack =3D { pc =3D 0x83d174f "\210\202L",=20 top =3D 0xbfffea50,=20 bottom =3D 0xbfffea50,=20 byte_string =3D 137279113,=20 byte_string_start =3D 0x83d170e "\b\204\006",=20 constants =3D 137279133,=20 next =3D 0x0 } top =3D 0xbfffea50 result =3D 138222001 #18 0x081e7b74 in funcall_lambda (fun=3D137279061, nargs=3D2, arg_vector=3D= 0xbfffed64) at eval.c:3174 val =3D 141607232 syms_left =3D 138805418 next =3D 139924762 count =3D 5 i =3D 2 optional =3D 1 rest =3D 0 #19 0x081e759e in Ffuncall (nargs=3D3, args=3D0xbfffed60) at eval.c:3036 fun =3D 137279061 original_fun =3D 139063306 funcar =3D 135674684 numargs =3D 2 lisp_numargs =3D 138805418 val =3D 138805418 backtrace =3D { next =3D 0xbfffefd0,=20 function =3D 0xbfffed60,=20 args =3D 0xbfffed64,=20 nargs =3D 2,=20 evalargs =3D 0 '\000',=20 debug_on_exit =3D 0 '\000' } internal_args =3D 0xbfffed68 i =3D 3 #20 0x081e2a8c in Fcall_interactively (function=3D139063306, record_flag=3D= 138805418, keys=3D138833597) at callint.c:849 val =3D 0 args =3D 0xbfffed60 visargs =3D 0xbfffed40 specs =3D 137279345 filter_specs =3D 137279345 teml =3D 0 up_event =3D 138805418 enable =3D 138805418 speccount =3D 3 next_event =3D 1 prefix_arg =3D 138805418 string =3D 0xbfffed81 "p\np" tem =3D 0x827511c "" varies =3D 0xbfffed20 i =3D 3 j =3D 3 count =3D 2 foo =3D 0 prompt1 =3D '\000' tem1 =3D 0x0 arg_from_tty =3D 0 gcpro1 =3D { next =3D 0x8579d72,=20 var =3D 0x3,=20 nvars =3D 0 } gcpro2 =3D { next =3D 0x81771b8,=20 var =3D 0x84600aa,=20 nvars =3D 138805418 } gcpro3 =3D { next =3D 0x3,=20 var =3D 0x84600aa,=20 nvars =3D 3 } gcpro4 =3D { next =3D 0xbfffee60,=20 var =3D 0xbfffed38,=20 nvars =3D 3 } gcpro5 =3D { next =3D 0xbffff704,=20 var =3D 0xbffff4a4,=20 nvars =3D -1073746408 } key_count =3D 1 record_then_fail =3D 0 save_this_command =3D 139063306 save_last_command =3D 139063306 save_this_original_command =3D 139063306 save_real_this_command =3D 139063306 #21 0x081e73c9 in Ffuncall (nargs=3D4, args=3D0xbffff030) at eval.c:2996 fun =3D 138479653 original_fun =3D 138930434 funcar =3D 0 numargs =3D 3 lisp_numargs =3D 0 val =3D 0 backtrace =3D { next =3D 0x0,=20 function =3D 0xbffff030,=20 args =3D 0xbffff034,=20 nargs =3D 3,=20 evalargs =3D 0 '\000',=20 debug_on_exit =3D 0 '\000' } internal_args =3D 0xbffff034 i =3D 136187689 #22 0x081e6ef9 in call3 (fn=3D138930434, arg1=3D139063306, arg2=3D138805418= , arg3=3D138805418) at eval.c:2820 ret_ungc_val =3D 137279061 gcpro1 =3D { next =3D 0x8bf8ebe,=20 var =3D 0x8466212,=20 nvars =3D 4 } args =3D {138930434, 139063306, 138805418, 138805418} #23 0x08172d86 in Fcommand_execute (cmd=3D139063306, record_flag=3D13880541= 8, keys=3D138805418, special=3D138805418) at keyboard.c:10336 final =3D 137279061 tem =3D 138805418 prefixarg =3D 138805418 #24 0x0816487b in command_loop_1 () at keyboard.c:1737 scount =3D 2 cmd =3D 139063306 keybuf =3D {56, -1073745664, -1208042826, -1223292826, 134550357, -= 1225353448, 134548642, -1225321128, -1073807358, -1208019440, 134548642, -1= 221756944, -1207963660, 0, -1073745648, -1073745920, 0, 0, 138805418, 13995= 1674, 137103213, 138782518, 0, 0, 0, 0, -1223352892, -1207977828, -10737455= 80, 0} i =3D 1 prev_modiff =3D 11 prev_buffer =3D 0x891f228 already_adjusted =3D 0 #25 0x081e4c96 in internal_condition_case (bfun=3D0x81641a9 , handlers=3D138836402, hfun=3D0x8163b90 ) at eval.c:1460 val =3D 138782518 c =3D { tag =3D 138805418,=20 val =3D 138805418,=20 next =3D 0xbffff2b8,=20 gcpro =3D 0x0,=20 jmp =3D {{ __jmpbuf =3D {-1073744000, -1073744124, -1073744732, -1073745= 288, 1671332591, -1595547264},=20 __mask_was_saved =3D 0,=20 __saved_mask =3D { __val =3D {0, 3071647572, 0, 3221222000, 3221221928, 322122= 1940, 134550357, 3087005944, 0, 3069646168, 3221159938, 134549363, 13454864= 2, 3073210352, 3087003636, 3071613396, 39, 3221221708, 3086925926, 13872112= 0, 138721248, 3221222244, 3071630884, 3073210440, 2, 4294967295, 3087003636= , 134549363, 1, 3221222016, 3086943894, 3087006384} } }},=20 backlist =3D 0x0,=20 handlerlist =3D 0x0,=20 lisp_eval_depth =3D 0,=20 pdlcount =3D 2,=20 poll_suppress_count =3D 1,=20 interrupt_input_blocked =3D 0,=20 byte_stack =3D 0x0 } h =3D { handler =3D 138836402,=20 var =3D 138805418,=20 chosen_clause =3D 134524876,=20 tag =3D 0xbffff1a4,=20 next =3D 0x0 } #26 0x08163f04 in command_loop_2 (ignore=3D138805418) at keyboard.c:1338 val =3D -1073744000 #27 0x081e4775 in internal_catch (tag=3D138834474, func=3D0x8163ee0 , arg=3D138805418) at eval.c:1204 c =3D { tag =3D 138834474,=20 val =3D 138805418,=20 next =3D 0x0,=20 gcpro =3D 0x0,=20 jmp =3D {{ __jmpbuf =3D {-1073744000, -1073744124, -1073744732, -1073745= 016, 1670955759, -1594667136},=20 __mask_was_saved =3D 0,=20 __saved_mask =3D { __val =3D {0 , 3072046750, 0, 0, 0, 13880= 5418, 3221222280, 136120528, 138493528, 138805418, 138825168, 136543850, 0,= 138973168, 3221222280, 136119354, 138825168} } }},=20 backlist =3D 0x0,=20 handlerlist =3D 0x0,=20 lisp_eval_depth =3D 0,=20 pdlcount =3D 2,=20 poll_suppress_count =3D 1,=20 interrupt_input_blocked =3D 0,=20 byte_stack =3D 0x0 } #28 0x08163ec0 in command_loop () at keyboard.c:1317 No locals. #29 0x081637b0 in recursive_edit_1 () at keyboard.c:940 count =3D 1 val =3D 134903343 #30 0x0816391a in Frecursive_edit () at keyboard.c:1002 count =3D 0 buffer =3D 138805418 #31 0x0816200f in main (argc=3D5, argv=3D0xbffff824) at emacs.c:1708 dummy =3D 0 stack_bottom_variable =3D -73 '\267' do_initial_setlocale =3D 1 skip_args =3D 0 rlim =3D { rlim_cur =3D 8388608,=20 rlim_max =3D 18446744073709551615 } no_loadup =3D 0 junk =3D 0x0 dname_arg =3D 0x0 ch_to_dir =3D 0xb72d7848 "" Lisp Backtrace: "vertical-motion" (0xbfffe104) "line-move-visual" (0xbfffe3c4) "line-move" (0xbfffe674) "byte-code" (0xbfffe884) "next-line" (0xbfffed64) "call-interactively" (0xbffff034) (gdb)=20 --NjcPelWKZ5-- From unknown Mon Jun 23 11:28:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Sep 2010 08:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6998 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Thamer Mahmoud Cc: 6998@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 6998-submit@debbugs.gnu.org id=B6998.128514531427764 (code B ref 6998); Wed, 22 Sep 2010 08:49:01 +0000 Received: (at 6998) by debbugs.gnu.org; 22 Sep 2010 08:48:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OyL0D-0007Dh-VJ for submit@debbugs.gnu.org; Wed, 22 Sep 2010 04:48:34 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OyL0A-0007DZ-NV for 6998@debbugs.gnu.org; Wed, 22 Sep 2010 04:48:32 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L95003004G2K600@a-mtaout21.012.net.il> for 6998@debbugs.gnu.org; Wed, 22 Sep 2010 10:51:03 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.203.3]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L950036Y4L2K410@a-mtaout21.012.net.il>; Wed, 22 Sep 2010 10:51:03 +0200 (IST) Date: Wed, 22 Sep 2010 10:51:05 +0200 From: Eli Zaretskii In-reply-to: <19609.28881.213914.115083@zemblan.newkuwait.org> X-012-Sender: halo1@inter.net.il Message-id: <83iq1yw492.fsf@gnu.org> References: <19591.19370.918828.700534@zemblan.newkuwait.org> <19594.45400.927788.599350@zemblan.newkuwait.org> <83tylt4zoa.fsf@gnu.org> <19607.29548.870306.576702@zemblan.newkuwait.org> <83hbhkxmgq.fsf@gnu.org> <19609.28881.213914.115083@zemblan.newkuwait.org> X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Date: Wed, 22 Sep 2010 05:58:25 +0300 > From: Thamer Mahmoud > Cc: 6998@debbugs.gnu.org > > Note that both the crash and the bug (mentioned further below) were > not reproducible on a virtual Windows XP. I didn't see the crash yet, but the display bug you mention near the end of your message is reproducible on my Windows XP box. Thanks. > To reproduce this crash: > > 1. Open attached test case with: emacs -Q --eval "(setq-default bidi-display-reordering t)" wrap_crash.org > It should open in org-mode by default. > > 2. Emacs _sometimes_ would render it like this: > > * First... > ...Second * > > If not, repeat step one until it does, or use something similar to > the command I provided in my last message, etc. "Repeat step one" means invoking Emacs again from the command line? Or killing the buffer and revisiting wrap_crash.org from the same Emacs session? If the former, it sounds strange that a new invocation of Emacs would behave differently from the previous one (unless there's an uninitialized variable somewhere...). > As a side bug, if you position cursor on "* First" in the testcase > then press [TAB] you will see that "* Second" gets deformed to: > > d *... This is related to the ellipsis that Org mode displays instead of lines it hides. If you type "M-x show-all RET", you will see the same display bug. I will work on fixing it, but in general, Org mode should set bidi-paragraph-direction to `left-to-right' in all its buffers, because using "* FOO" outlines with FOO in left-to-right script assumes left-to-right paragraphs, and because Org mode does not enforce an empty line before the "* FOO" lines, making them assume the direction of the previous paragraph, which looks odd.