From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 09:05:58 2020 Received: (at submit) by debbugs.gnu.org; 24 May 2020 13:05:58 +0000 Received: from localhost ([127.0.0.1]:36655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcqKE-0005Ti-2F for submit@debbugs.gnu.org; Sun, 24 May 2020 09:05:58 -0400 Received: from lists.gnu.org ([209.51.188.17]:51844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcqKC-0005Ta-NS for submit@debbugs.gnu.org; Sun, 24 May 2020 09:05:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcqKC-0007Bn-JW for bug-gnu-emacs@gnu.org; Sun, 24 May 2020 09:05:56 -0400 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]:40436) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcqKB-0002QD-J9 for bug-gnu-emacs@gnu.org; Sun, 24 May 2020 09:05:56 -0400 Received: by mail-ot1-x335.google.com with SMTP id d26so11936850otc.7 for ; Sun, 24 May 2020 06:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FNtceJ1fCYbhkBAtxo9dtfHdq/kYXCMDqLQRVvMQaS0=; b=FNgrow2aZKB5jlI+TlboysaPT7a8pT1B5cJ+fHHcau5GZgTOm6hbxUcVnze6FRl2mO gbBZsKjEP+FKH5IBAdk1CAFZ07J1ohrccRfgXA63OIqbwVUpsbvoa0N86t+B1gNoKWiN F5HuZOvBf8YbFPLKxNj1aRAv4JTEDTbcVlAV0oGHVYgcohwDPqorvA14JoUiCt+lbnTW t2YLscMVe3PnqCYcAeXhe3tfqsZ3+oMFCPISAH14uJZfU8vV2qjhcndarFqhrQMRj0MC dVgI4ywX58pm/6vyMFFem5vyZ4kxkjsMo2I/EGNFFSNF6epnMMwG4szB3Bclwjyc/xen MqhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FNtceJ1fCYbhkBAtxo9dtfHdq/kYXCMDqLQRVvMQaS0=; b=V1nJv5cgt+im2p4cGN16sYfVsZ5rY7b2e/MhROdFNggjXydPfOtRlZyPZjqevQdnHe 5S66gDI9YTYNNXXyq40+k6tlIjBfdGjczI8iaf3UxQJKWTSm7IZHNzJ9B3JR+g+oh4qx kGfEGNufDd0RaRBEqlzcAHEOK5pLqOJ1Y3HHDarfw89TL008t29IHgUDAt4zFDGmtNjh +bEpkeUoXfLCQni2CYoDc2YDSai1t04Zv+Tilbt2L1v197cRjjXryGAeKTthVW6wM8VG 0EbnVnBdgO55BEdQQTlyoutKT3RzapHi8zlwXkrDAwbQ4v6W/hPQnnKBTli8xpMCPTY0 11SA== X-Gm-Message-State: AOAM533Hg0L0sk0SEkjFQ3Tba+L/jp1WakqbM4JSuqmmD/GGHQFnod7N M45XkS/Bzr/C5ZqgoJwj17RjMV9Y74Znu3tV0GKcIG+f X-Google-Smtp-Source: ABdhPJypOZOc+eS1gQ+85eVWf6DsTY98axwtsopqxP1XFhnYnufVVcj7uWq3KAcZE8+g1uk3lz2y0t3NoqMQrMqiEy0= X-Received: by 2002:a9d:6a44:: with SMTP id h4mr18294753otn.287.1590325553831; Sun, 24 May 2020 06:05:53 -0700 (PDT) MIME-Version: 1.0 From: Pip Cet Date: Sun, 24 May 2020 13:05:17 +0000 Message-ID: Subject: 28.0.50; RTL problem To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="000000000000b6c94905a6648592" Received-SPF: pass client-ip=2607:f8b0:4864:20::335; envelope-from=pipcet@gmail.com; helo=mail-ot1-x335.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000b6c94905a6648592 Content-Type: text/plain; charset="UTF-8" Hi, I'm surprised by the way vanilla Emacs behaves when given RTL input: Recipe: emacs -Q hebrew.txt hebrew.txt contains (or should contain!) two newlines followed by the Hebrew word Ivri, punctuated, followed by another single newline. Expected result: right-aligned text Actual result: left-aligned text Is that a bug, or is there something I don't understand? It only appears to be left-aligned when there are precisely two newlines at the beginning of the file. I'm attaching a screenshot since I don't know whether it's a font-specific issue. Thanks! --000000000000b6c94905a6648592 Content-Type: text/plain; charset="UTF-8"; name="hebrew.txt" Content-Disposition: attachment; filename="hebrew.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kal2qd9y1 CgrXota015HWsNeo1rTXmQo= --000000000000b6c94905a6648592 Content-Type: image/jpeg; name="ivri.jpg" Content-Disposition: attachment; filename="ivri.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kal2pobp0 /9j/4AAQSkZJRgABAQEBGgEbAAD/2wBDAFA3PEY8MlBGQUZaVVBfeMiCeG5uePWvuZHI//////// ////////////////////////////////////////////2wBDAVVaWnhpeOuCguv///////////// ////////////////////////////////////////////////////////////yQARCALhAvgDAREA AhEBAxEB/8wACgAQEAUBEBEF/9oADAMBAAIRAxEAPwDQqsn8M7XsyKP75izEObpjRvnzr/EkENMH A9r+MGA+zRG973ve973ve973ve973ve973ve973ve973ve973vfdg8BW1MZDhAj4O8BwmmK5T562 tC/QutwiQOlMoRq/rrrRi3fX6ZF9wDDB/ADHTgr2y9cCZzfK3O5z6RUYa4gek0lJI/KGRoGNgADr pH8Z/MMLRtpGyE58Hn1WqQnZninmPBUs/mFQLxDsod/ZV5VYe70eGwx7t2vwPeZJvYhZzLYtFLix pfqh/tPFWU5uwSu5YFwTt3HWxoiykyCcsf8AR/74nryLsdTh2+xG0p/W3xSJPRQPV8YtyA+0lESP zy8FLRQyCkWCSB7JE0SxVuvtMpHo66Rqw6orrZhUFsOZB7tuwcFTVQW1qk1VQCa2CHy6OvCoW+oT ZK4H7TE7J9VnQ+518434yV7VMeVxiDrJGeMf3wz3t9R9VItLJMWdHNPXVD2FUcf5dCSjvVu//XIm PVfafItFRkMssDo63+yeTKgkILijUWA2XOLB2pIHgUH7IRL+vhfXOAycxLcA6oY1T0ylPALiGL0N Nlavnrs0inKmiIKSJSn3/bkMSKUESbFBIkkWLpafpVQbcvXwdb4FW2JXKpvN4cueB/qUmaKw3tWe jbVqniytnqY1AoxLxFPDvEn2JfgFJYNgdscK3+NkoAERgGjy3vXgSkZY0RBsf43QampUrTcR1Ag7 MqUXJlSSvrmHhHIFqp6n/K2+hCsOtZOxU2Ek9cxRecERgluIrEco8aF7eO/3sny8AX6JJ5mLGQ0P OMTzXnu6gROI7ih3o2UBIhornWj9u+rTm1XHRlf1EwSO/wAqYkyWg8D/APR7RnSAOGqmHEoSg+UW I0qpIS2DXHGIVL8UnDHZarG4EKOQrGI1q58lompqf6ec129YoiVn69meuQDHR7L18MltM7/HAIsd US8GBJ+lUiFV/hdA9Ubxh9ydh+c5aOzuAelnwuJI/BZJdEJiALwoP70MenkNNdUFQivzsMj3l92+ XPjPBGYcphsF7xRmMSdUlh9dmiNEd5nYQ6CGgGl/vcrc1u+NEXA6lC+fpDuWYEtDN0k933YTu0Et p1FTM9jJvgMsm+vm0n85eJpNyz5X7Nfu6j6rgQ5G1R8PhG4c+CZBMCGRmFDSR9cQ3RsnlwkUCb1J uJwD6KAZAVojLmJvDP5EnlkFovz3Kfnl2e6LlX2X1icupKteLjxBMhl3MHgl2YqHxuF9kjd0TfHg pLUvvw6oOuXr7jDgCfzbUvYbu5B72zaaFilKbLNK3roonmhqKzgdfJfUXczflLMsNSqhbsu3AYuU TsTiZvDyZdADphCYGwgl6GEjAhLNujjTR5lXQAAa/o4W7B/cKHgTkuO8RNUBnzjEAlTmSP2SDHsP tjuemv8ARAm+jHRGa0zCQYU4SwiaxkpOTsC05w49f2tGOYrPM6g7LFtOJmNkPQzrAy3gT7LX4NXu tPoIVW1soJBH0fVZGalwcSoWYW45yBm/1fNsSpAi9/7WYOL2gylZoAKkhNAy1/bwy6yX6eiJTur8 nlk+yEZuEvHRit1F1Uq0m9UJDCuREe3xUx7s4mUMu273pXrHk7axOZE5HpV7jhvbzJE+cFEfH5jF iAnuO08pQioCUlIFs1SWBTCdgPIVlUJWeW7rMn+eLbXsEh5/Ub6lvoVrsICDgcorRIfGjJ+NRd+8 QJHEo0Yn24DPtzdU8gUtDdATKwMfHjpy/mIcDS5xdg4j94FQJeji5LgDPa3VQXkAMRJUFT4v9UW8 Pdakf8LgwmJe/wA356BsAXTHPcXorobtmwJbdM609iL4ZKHIKNr8NgFqS3WM0ZqtmyaIUXE9d9lw sRrva+812M4UP1LraQninKniylet12OQ/L3yvEjuZywcxLycsG9/7YQZXOglcdB2zRhjac9rva89 Dc1MdtMVky0dF7ECNQEmo44ePdoJ9WyPw5Ntqq+qoSA+XWWWHGEge07u78qoAKeQ5EbPui6t83d4 FMhJKlcJ7hQWAM4xRpHib1iPGgzu6CBIhi+tn7RzflmMqQmTPcc+jmxJsIG3M2CW4+qIP2JIIpkq Ky7i6G4BTHfEBTZoxG3pZQcUCsLLep19kMSqP2tbUHTBeeAT/mAKUhFJsmVuLLPv4y/GyqGInX9L Z4r66crBZuClO1slIK0KGeQ6Br0clADn+Tszpqea91zx4YCycKu4cglZgEA0fbrD7hz6s8raw4vC utainxuBrkaBXWrW9Z3SICsCqnoErmv079O4E5sQJ+M92WCh2ooahKQ5h06I4ginP/Na1I0t1+a7 ORgESguPAA7ZPE+8GSOxPAPOzHS5YJ8wjWcoNTn5XAoP2sG2l+Mlrfqec+erVuaSFXVMisArQUKp PaeAZY7qOEQu0Y5QjBmE65jDZHfFpAYlixec8Jk2eVcCWWN2IxNYFgxWGs7hIzhEYT32xPor1Tgw zzXNpFhITrGBFsC2rhvjQrdayv8AxYl1Msrdsh3qXMP1tMBUy6mWwjby2Te+Uup4x0ZpKrzdVIj+ ve5PyYdYWMhBiF6LvQj9AZmguLimCYxpdeaMJAozAxYAQWpCgYF3D5I5gMiz+hT/ANODYlB/LjT2 FHfr+f1pNCzsJIoilhpP7jbF2uTbxyUwVCqpLCvGa6AdXcnCVDjl6wmb2yYDjyf0fzQD2uwmb2yZ UpoIFWbbCzAwmb2yaa/DOyzdGDHQwmb2ybebtVHy50OxlhM3tk4j7q3iLuqnTNhM3tk6BtNATJV8 ns5hM3tk75uBItMClgIjCZvbJ6hVueQZsXCI2Eze2T58aNT45F9G/MJm9sn7YsLjp65ES3YTN7ZQ DwF5GkM7UtMwmb2ygdFE0o3HIXPiwmb2yfdBntAvI1up1hM3tk+6QLgffAudljCZvbJ9013LuUBc 7pGEze2T7qPepUp5t4EMJm9sn3Va9wr5D7xcYTN7ZPusZ8TYF23lAwmb2yfdbb56lb+vNthM3tk+ 67H19LCtehTCZvbJ919nvmB129NWEze2T7sG/lEGZN6qsJm9sn3YjfU4Rrb1xYTN7ZPuxmvfAqRX ZhhM3tk+7oDOwDC9dsmEze2T7wG9uYNh13FYTN7ZPvADzpGWHe6l2PPbJ+mrfsgZ2d7zXY89sn6d bgIxo92x8djz2yfp/gFcGpHcLB2PPbJ+ob4ksa1dz5nY89sn6jXDGhsQ3bSdjz2yfqS0PGGz/epB 2PPbJ+pdJFUbat9RnY89sn6mwkzRuK3+4djz2yfqeKUxG6bgZZ2PPbJ+qDJYUUGGDNHY89sn6oul yRYyYSMdjz2yfqkwYEF81hap2PPbJ+qY5jMZQ2GmnY89sn6p5GXhsiYdidjz2yfqokZ+HH1iAp2P PbJ+qlxpodtmIknY89sn6qqmwR6lYkIdjz2yfqrebbH3RiWZ2PPbJ+qwRu4gIGJvHY89sn6rInGe MBO0UP6/3z2yfqs1po4zvkaViuIY0/Vvr5acjr7jvJm5z4Uhm1X0SJztIm2rzucxAMIBUJdVe3Bw QOoJi6b9ALHs4GSrfnomDJzeT1f+SDm2j9GMbtDykpiNcsNVmIZxRASrDxMTs5DUpZRbwcTENdDX 9+ExMeIYG10tpHt500DdcOjkKJty0dnI7a03alSBQUk53fCcO0BQ1tVq8bhr/wBuNIGse1HfjTSR 9anTvJo3ygxRpiA6+mB86oJbClG+NQ+sujADdn7GlGIxei0q2QnqsbkmIftn3GaJc4csI89o3Rzs RH35Qb3AZDcZK+ZYjUqZM6JebmsqhJhXTWfPLl1sApXJHKHrsYwpwpkznJC6hiS4A/YMekC1iYou 4qFcVdi0UYk5QmLlWvTz/wBw8t2rQaxiN8q8RkPwPT8lVa2gbcmRDITc9ARi4Ezk4GZA3sTqYPT1 /wAUGFKOxLUKif37AYQMc/8ANLJNI/DeLpLzPlTDamKC2Chqoz7baFq/RNGyxW6+dHuu9aDvjeWo ejflq1p5XdLOEVzTemRf1KLHzqAbn7YGFoLRuNk9K9DgzHdN52KTio/uxGZPJgktTMEn/I4m/QIw wN2zVFTuJIAAfzjvw7VMuS6J2PcK/wB+0v7zTQJXxuFTAUSkXSbkpT2lXbzOyZ3GgIwNrGUHlkHe kiHD6dvF82BOvqufRq6wv4Zj+khXVNekGIVJm9Z4HjybTj0nwgnBTZlRYhedJmmuJhj+AjGJ98V8 B84AJ9hdJhgmjeXG0SmQawOF3n91XXMc6wmAF5cmyzzxk8SR1YU8xWvW+anfCCzAIFkoISpGHB3e sHTmXeLA1erBiyJ5D0sg9qQq/VgEQ986Jytua3SPQ2sH98biIhON4Kkybtghaa8q5eNMzCXUKNZM BHLdPwhH9reOKfS/Jn6REPLbeVOdPCdnu+b1kMVxn+rb3/wPbrPwpt3sKBtBpdYQKvc4o9FRn32X JT7B6/uhrVZ/Z3Ym2YOnjl+rYT/uNKNiaOslaCAuRaoZfpDcql7Xi64cOE31iD+zm0Z6IEbDf4dI l/CjueHUFDECr9N+2001n2fyx4BhQeRp6BKIcxxG/eE3SEImgVfFOnqJjZt9NVGRUSMQ1V1SJXQU KCM9a49fwLIHquZfo41ysgqFhsugklhMmZep0jrZv/6HnQG5eszqpfgKNzWT2E3aa6yJnjp+WheN bMWC4rOIhU6LbONXUkMApjb/AF3GYx0mBVWcrkv+sxPw55p/7FnBOJ70wi0wsIBWieDEO9xmEEV8 HKsZWxsBjz5n99eOi58BPICj/WrcHfydngHbkiGRI/Gj27bZastORgv1HqHtI7dkIrDVdBa6GNBs jBW9sFXwdjpAkcwrE2n0blwJOw3DF3rnVujNaiJgtBah+pkffFQkImpMPhcIj/QHP+Dam1krBbou /9k= --000000000000b6c94905a6648592-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 10:46:19 2020 Received: (at 41506) by debbugs.gnu.org; 24 May 2020 14:46:19 +0000 Received: from localhost ([127.0.0.1]:38451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcrtK-0008JD-SP for submit@debbugs.gnu.org; Sun, 24 May 2020 10:46:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcrt9-0008Ic-KI for 41506@debbugs.gnu.org; Sun, 24 May 2020 10:46:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32959) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcrt4-0001WO-38; Sun, 24 May 2020 10:46:02 -0400 Received: from [176.228.60.248] (port=1483 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcrt3-0003op-D2; Sun, 24 May 2020 10:46:01 -0400 Date: Sun, 24 May 2020 17:46:12 +0300 Message-Id: <838shhxuff.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sun, 24 May 2020 13:05:17 +0000) Subject: Re: bug#41506: 28.0.50; RTL problem References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Date: Sun, 24 May 2020 13:05:17 +0000 > > I'm surprised by the way vanilla Emacs behaves when given RTL input: > > Recipe: > emacs -Q hebrew.txt > > hebrew.txt contains (or should contain!) two newlines followed by the > Hebrew word Ivri, punctuated, followed by another single newline. > > Expected result: > right-aligned text > > Actual result: > left-aligned text > > Is that a bug, or is there something I don't understand? It's a bug, but one that's very tricky to fix, AFAIR. If you insert or delete a single character, the display becomes correct. From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 09:45:30 2020 Received: (at control) by debbugs.gnu.org; 29 May 2020 13:45:30 +0000 Received: from localhost ([127.0.0.1]:54183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefKD-0003QP-UQ for submit@debbugs.gnu.org; Fri, 29 May 2020 09:45:30 -0400 Received: from mail-qt1-f181.google.com ([209.85.160.181]:41813) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefKC-0003QC-Oz for control@debbugs.gnu.org; Fri, 29 May 2020 09:45:29 -0400 Received: by mail-qt1-f181.google.com with SMTP id w90so1902562qtd.8 for ; Fri, 29 May 2020 06:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=hj+C4kb24d63OUSySn0rpkm/lkf0jB/VrUBIXA/tu0U=; b=F+V0ApAoJogoiBGDubukQ0xXcyrDEKmA5ds3+JYnVBIgGPWNI4v6sdgWuGVJdHmWBM mHY98Ne7R6Iep0LoWSN1BAgCWLlqFiwvrg6lisq4G+kAQpy1fGIAJKhP2bYcm6Tr2SUB KNLRrm5W091tZBEuu2dy1TFeSGNk4JdGVZ4aqBKMrAs5H1MMzaV836+4dBVNW/PVRA2s MQXAHJJWY6myTjWRuuB7hQYbiHK3ICvKteotccWRISeQUKQyj0oY42SAJiOaUv5xJ1Hq 6EO1mrW31Fu0swwMsyBM1mieQ6sS+U2WBkkqE/gLFWWeTANvxgNM/YpbHVq5eZFKydpB MKYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=hj+C4kb24d63OUSySn0rpkm/lkf0jB/VrUBIXA/tu0U=; b=Tfmeo8eDZ3JVnBWHeLTaBeG6GH5PUJnYA05dPpkGfzTa/0CnNeb/bksR8Fw+cwdNT7 ZfBPBSNLO3x/ixP9q7pYfBud6LXZW8Z8Sw3pL2Bc9odBwhPnPZoSHcx4u4QRZbyt4o6h s+tylqgM5lbh1ZgX43sMXcU+pOkPLXroPPgOgDB3JzKkkG07f/xgABf2C86v9XYOoh9B bl71EM5/YDbjbivvGS3+Psoo10EUAbeFcGlUelHJy5Yf2pu3BcNSHVHqsZzm+dq4EnON nyc8S3pvfa7gROUqcONs7+rxF/fmpC8j86dJ/lKcbAUDenwyISaMVlEdEzYVLYZbl9XR 89NA== X-Gm-Message-State: AOAM532qYTjkcCJ/H6z3rUEDld6GksSYS6xlPdyGRKMXiiZN5l7/RZBc cntte818ENkla+YcvvZz1OhxAwZt X-Google-Smtp-Source: ABdhPJyVRI9+GEhVioqXu8O+pmao++SwbCY0klIPCk//Wl8Go4reID6Xxs20lFv6x0G8+LR8/nbU4g== X-Received: by 2002:aed:3f17:: with SMTP id p23mr8955483qtf.346.1590759922940; Fri, 29 May 2020 06:45:22 -0700 (PDT) Received: from vhost2 (CPE001143542e1f-CMf81d0f809fa0.cpe.net.cable.rogers.com. [99.230.38.42]) by smtp.gmail.com with ESMTPSA id j22sm7130598qke.117.2020.05.29.06.45.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 May 2020 06:45:22 -0700 (PDT) From: Noam Postavsky To: control@debbugs.gnu.org Subject: control message for bug #41506 Date: Fri, 29 May 2020 09:45:20 -0400 Message-ID: <855zceua6n.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) retitle 41506 two newlines followed by RTL text aligns left instead of right tags 41506 + confirmed quit From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 06:18:38 2020 Received: (at 41506) by debbugs.gnu.org; 2 Jun 2020 10:18:39 +0000 Received: from localhost ([127.0.0.1]:37980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg40E-00067p-Mq for submit@debbugs.gnu.org; Tue, 02 Jun 2020 06:18:38 -0400 Received: from mail-ot1-f46.google.com ([209.85.210.46]:33281) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg40D-00067d-G0 for 41506@debbugs.gnu.org; Tue, 02 Jun 2020 06:18:37 -0400 Received: by mail-ot1-f46.google.com with SMTP id v17so10523389ote.0 for <41506@debbugs.gnu.org>; Tue, 02 Jun 2020 03:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1pNgdxPOs0S/DZL4Dp68XL7Y6STkzD/M+rt6CQ0/tVE=; b=cflH8EBspAG4ZRy/4yA1gOXOA1taM55D/BahPxVlrJaV1O9TzKmyJgxBkvWA+XVMD6 2oufQjXIvM0s/MJYfBtBpc5tVm3l7JLsqscTQbvJb/jWng7T+NjRt4teX9Gd9zDhiNiu OXfNLebo+1lgC1x42cBbZ+j4cMSGLxwrsHGNhGHc0osYerzfBO+3HYYL1ih/T5SKXMHu T62ZYuVcCJUg/UxkyFOo6ZFO3giRqueeA9phW6qxXjjMIICwpME9EIZoNBPPgXDl2aNd dmFMi1pK4DokYZ5wJpICnUfYYxCPpI6AUNH0kcYNvgzRe4CHaEENd1m1VSN0y2nNhjyG bVMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1pNgdxPOs0S/DZL4Dp68XL7Y6STkzD/M+rt6CQ0/tVE=; b=F99+SBxuqx05YruEfPHfsU+4EEJt3UUw9ZhC0TmN3IK5B2OS6MV3/L9XZ7QQwDWBUD wzEgdkh3tx/mpvCcD07BEebA141stG5GNwExynzY9mYICuzrFc5v6plLIX5wQOzsrpX4 iMbpUMLyp2hTIugeSkPTl/yzdggCmf/SlHx5xnqd/Jjsz4+7p+Ajd4nq6Jh6EQmJJIeb rn5RF4NCAXf/uPQjHQY9rl5vAidikBehczx3zUQOETVkXdQTcFPxLNTN3B6UNlqfkKIy JyexaJ4hGCcCBeG4og1le+YX11i4C44FtpZCPDkvZwuOVhbVfR5Uf9+BEYAkuBlrUsOU VKKA== X-Gm-Message-State: AOAM533OANl0pBw9oZF/MdveE9/Naz6xLsXLJLaHNOfFz/0O9q1wVl95 lnzJ8xK+zOMlBod2/tE62pVc20PoHyoH+f59xn8= X-Google-Smtp-Source: ABdhPJz2z0Y0uPWqioUA2A/sJUJ6s0cJE6dT3jMqn9kypMLj1KBcEtfjzIqZ5zv64jgMqFJj+V6DnKiJV7/6QVItL7U= X-Received: by 2002:a05:6830:1f4a:: with SMTP id u10mr270678oth.154.1591093111678; Tue, 02 Jun 2020 03:18:31 -0700 (PDT) MIME-Version: 1.0 References: <838shhxuff.fsf@gnu.org> In-Reply-To: <838shhxuff.fsf@gnu.org> From: Pip Cet Date: Tue, 2 Jun 2020 10:17:55 +0000 Message-ID: Subject: Re: bug#41506: 28.0.50; RTL problem To: Eli Zaretskii Content-Type: multipart/mixed; boundary="000000000000ba1bf905a7173b33" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000ba1bf905a7173b33 Content-Type: text/plain; charset="UTF-8" On Sun, May 24, 2020 at 2:46 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sun, 24 May 2020 13:05:17 +0000 > > > > I'm surprised by the way vanilla Emacs behaves when given RTL input: > > > > Recipe: > > emacs -Q hebrew.txt > > > > hebrew.txt contains (or should contain!) two newlines followed by the > > Hebrew word Ivri, punctuated, followed by another single newline. > > > > Expected result: > > right-aligned text > > > > Actual result: > > left-aligned text > > > > Is that a bug, or is there something I don't understand? > > It's a bug, but one that's very tricky to fix, AFAIR. If you insert > or delete a single character, the display becomes correct. The attached patch seems to avoid the problem, but I'm sure I'm missing something. The comment says "don't do that at BEGV since then we are potentially in a new paragraph that doesn't yet exist". I'm failing to make sense of that, and the commit (5e65aec01a9bc5a147e492f11dd0115c98bedef4) isn't too helpful either: "Fix bidi iteration near BEGV and ZV." I suspect what might have been meant is that narrowing an LTR paragraph to a line containing STRONG_R text shouldn't result in RTL display, but it does... --000000000000ba1bf905a7173b33 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Bidi-patch.patch" Content-Disposition: attachment; filename="0001-Bidi-patch.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kaxrowf90 ZGlmZiAtLWdpdCBhL3NyYy9iaWRpLmMgYi9zcmMvYmlkaS5jCmluZGV4IDEwMTdiZDJkNTIuLmUz YTVmZTdkZTYgMTAwNjQ0Ci0tLSBhL3NyYy9iaWRpLmMKKysrIGIvc3JjL2JpZGkuYwpAQCAtMTcw NywxNSArMTcwNywxMiBAQCBiaWRpX3BhcmFncmFwaF9pbml0IChiaWRpX2Rpcl90IGRpciwgc3Ry dWN0IGJpZGlfaXQgKmJpZGlfaXQsIGJvb2wgbm9fZGVmYXVsdF9wKQogCXJldHVybjsKIAogICAg ICAgLyogSWYgd2UgYXJlIG9uIGEgbmV3bGluZSwgZ2V0IHBhc3QgaXQgdG8gd2hlcmUgdGhlIG5l eHQKLQkgcGFyYWdyYXBoIG1pZ2h0IHN0YXJ0LiAgQnV0IGRvbid0IGRvIHRoYXQgYXQgQkVHViBz aW5jZSB0aGVuCi0JIHdlIGFyZSBwb3RlbnRpYWxseSBpbiBhIG5ldyBwYXJhZ3JhcGggdGhhdCBk b2Vzbid0IHlldAotCSBleGlzdC4gICovCisJIHBhcmFncmFwaCBtaWdodCBzdGFydC4gICovCiAg ICAgICBwb3MgPSBiaWRpX2l0LT5jaGFycG9zOwogICAgICAgcyA9IChTVFJJTkdQIChiaWRpX2l0 LT5zdHJpbmcubHN0cmluZykKIAkgICA/IFNEQVRBIChiaWRpX2l0LT5zdHJpbmcubHN0cmluZykK IAkgICA6IGJpZGlfaXQtPnN0cmluZy5zKTsKLSAgICAgIGlmIChieXRlcG9zID4gYmVnYnl0ZQot CSAgJiYgYmlkaV9jaGFyX2F0X3BvcyAoYnl0ZXBvcywgcywgYmlkaV9pdC0+c3RyaW5nLnVuaWJ5 dGUpID09ICdcbicpCisgICAgICBpZiAoYmlkaV9jaGFyX2F0X3BvcyAoYnl0ZXBvcywgcywgYmlk aV9pdC0+c3RyaW5nLnVuaWJ5dGUpID09ICdcbicpCiAJewogCSAgYnl0ZXBvcysrOwogCSAgcG9z Kys7Cg== --000000000000ba1bf905a7173b33-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 12:34:57 2020 Received: (at 41506) by debbugs.gnu.org; 2 Jun 2020 16:34:57 +0000 Received: from localhost ([127.0.0.1]:40768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg9sO-0001ig-Mb for submit@debbugs.gnu.org; Tue, 02 Jun 2020 12:34:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg9sN-0001iT-Rh for 41506@debbugs.gnu.org; Tue, 02 Jun 2020 12:34:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47891) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jg9sI-0001FS-Ht; Tue, 02 Jun 2020 12:34:50 -0400 Received: from [176.228.60.248] (port=1555 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jg9sH-0000sd-K3; Tue, 02 Jun 2020 12:34:50 -0400 Date: Tue, 02 Jun 2020 19:34:31 +0300 Message-Id: <83tuztctpk.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Tue, 2 Jun 2020 10:17:55 +0000) Subject: Re: bug#41506: 28.0.50; RTL problem References: <838shhxuff.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Date: Tue, 2 Jun 2020 10:17:55 +0000 > Cc: 41506@debbugs.gnu.org > > > It's a bug, but one that's very tricky to fix, AFAIR. If you insert > > or delete a single character, the display becomes correct. > > The attached patch seems to avoid the problem, but I'm sure I'm > missing something. This condition was added 11 years ago, when I just started integrating bidi.c with Emacs. The commit log message and the comment both say I had some real problem on my hands that this condition fixed. However, I have now thrown several use cases on the patched code, and could see no problem. So I guess whatever issues I had back then were meanwhile solved "by other means", and you should install this patch. If there is indeed some subtlety here, it will present itself sooner or later (like, in another 11 years). > I suspect what might have been meant is that narrowing an LTR > paragraph to a line containing STRONG_R text shouldn't result in RTL > display, but it does... No, this works as designed: the Emacs display engine always behaves as if there's nothing before beginning of the narrowed region. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 15:08:15 2020 Received: (at 41506) by debbugs.gnu.org; 2 Jun 2020 19:08:15 +0000 Received: from localhost ([127.0.0.1]:40986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgCGl-0007aq-28 for submit@debbugs.gnu.org; Tue, 02 Jun 2020 15:08:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgCGj-0007aX-9J for 41506@debbugs.gnu.org; Tue, 02 Jun 2020 15:08:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51329) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgCGe-0001Pq-2o; Tue, 02 Jun 2020 15:08:08 -0400 Received: from [176.228.60.248] (port=3283 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jgCGc-0005qS-6C; Tue, 02 Jun 2020 15:08:06 -0400 Date: Tue, 02 Jun 2020 22:07:48 +0300 Message-Id: <83ftbdcmm3.fsf@gnu.org> From: Eli Zaretskii To: pipcet@gmail.com In-Reply-To: <83tuztctpk.fsf@gnu.org> (message from Eli Zaretskii on Tue, 02 Jun 2020 19:34:31 +0300) Subject: Re: bug#41506: 28.0.50; RTL problem References: <838shhxuff.fsf@gnu.org> <83tuztctpk.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 02 Jun 2020 19:34:31 +0300 > From: Eli Zaretskii > Cc: 41506@debbugs.gnu.org > > So I guess whatever issues I had back then were meanwhile solved "by > other means", and you should install this patch. If there is indeed > some subtlety here, it will present itself sooner or later (like, in > another 11 years). Btw, please note that some residual problem remains: after the patch, if a buffer begins with 2 newlines and an RTL letter, the first screen line is rendered right-to-left, which is wrong. You can see that it's wrong if you insert more newlines at BOB: then only the single empty line immediately before the RTL letter is rendered right-to-left. Of course, this is better than the original problem. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 03:58:54 2020 Received: (at 41506) by debbugs.gnu.org; 6 Jun 2020 07:58:54 +0000 Received: from localhost ([127.0.0.1]:50608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhTiy-0005iP-I3 for submit@debbugs.gnu.org; Sat, 06 Jun 2020 03:58:54 -0400 Received: from mail-lj1-f179.google.com ([209.85.208.179]:35811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhTiw-0005iB-Jr for 41506@debbugs.gnu.org; Sat, 06 Jun 2020 03:58:39 -0400 Received: by mail-lj1-f179.google.com with SMTP id j18so1461968lji.2 for <41506@debbugs.gnu.org>; Sat, 06 Jun 2020 00:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=vjxUGLCtaV8xZxSEBTxSD/MIgugve7EYg3K9IVIpJGA=; b=q4DWW9XUrEsZEyXj3QEoTcZo1isUNeZcwaUxP5UmK+0KOib68/UE8lzuivvqBeA+VF MMSX3O429KomRwNNqtvXAJImtXhj/vurHlTQI3uVoCmhjlhKo0lAU645naZITMn+Cbua Q010vGjNCtRJ9ycUd+vR7LI0WbSWwBaDFlR121VwQcMbYwKLVPOh91WfhTCtzoxQOGyo PJFl6xvVrNs1iFfVsQx4lc9jsAbFtj+OoTvbVnFSlRPZqVRvH+Zj5dhGZCrMzBxlquV1 eGIEp1OssRzte7b3o7KNnMs4HVsnrSNwqByjGSqCPhw8SCMhYEUeTY6AlFf42e8HC+sl VhMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=vjxUGLCtaV8xZxSEBTxSD/MIgugve7EYg3K9IVIpJGA=; b=t16oyomwS1CM2qknhr/aQ0LcW9xM/CvPCjM/LT1x4zESZ50urs12+Nlinhhn2brgNI opQeNWhkKrylQu4z3ataAaqjk5vwa9FBO//klSSqIBS7eEITldjJ1lk+9yQl0wp7in9C JiWQJV+dvEEY77HGODOioOvGvSKQsKz43F68sf0LIqvmjSk9bHILZSPkzF6mjH3EsxWe p0hhK35lubxS6+LrhVr4DP8/1v8h5lr5JkeCMK5lrecERrLWiRzU8JDVHUru4Xzbwo5E IROOK1KORs/z6R+dOODMCD6sq6JBbXfbgfWj4LLfJO3G73amKtMuccyjTR06pyri0iXR SeUQ== X-Gm-Message-State: AOAM533ZWhZJYhqIWql05I5pYiZh1rK5uBStmVpBAXCXq62Py+Y2gKFz P69sLMU9yk0WNqq21p8mnppO3/99f+0= X-Google-Smtp-Source: ABdhPJzhX/op5/1smNYIxfJIDkRWT3poMg0s/UhnpYDiLzU2E3Go4VhcfPQ5Y8nHzD6RQ9XrR1mOyQ== X-Received: by 2002:a2e:8754:: with SMTP id q20mr6773520ljj.270.1591430311978; Sat, 06 Jun 2020 00:58:31 -0700 (PDT) Received: from chametz (tor-exit1-readme.dfri.se. [171.25.193.77]) by smtp.gmail.com with ESMTPSA id r17sm1747900ljd.0.2020.06.06.00.58.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2020 00:58:31 -0700 (PDT) From: Pip Cet To: Eli Zaretskii Subject: Re: bug#41506: 28.0.50; RTL problem References: <838shhxuff.fsf@gnu.org> <83tuztctpk.fsf@gnu.org> <83ftbdcmm3.fsf@gnu.org> Date: Sat, 06 Jun 2020 07:58:24 +0000 In-Reply-To: <83ftbdcmm3.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Jun 2020 22:07:48 +0300") Message-ID: <87k10kzkv3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> Date: Tue, 02 Jun 2020 19:34:31 +0300 >> From: Eli Zaretskii >> Cc: 41506@debbugs.gnu.org >> >> So I guess whatever issues I had back then were meanwhile solved "by >> other means", and you should install this patch. If there is indeed >> some subtlety here, it will present itself sooner or later (like, in >> another 11 years). > > Btw, please note that some residual problem remains: after the patch, > if a buffer begins with 2 newlines and an RTL letter, the first screen > line is rendered right-to-left, which is wrong. You can see that it's > wrong if you insert more newlines at BOB: then only the single empty > line immediately before the RTL letter is rendered right-to-left. > > Of course, this is better than the original problem. I decided to investigate further, and finally came up with this patch, which appears to work. I'm not a hundred percent sure it's the right thing to do, because when we're called with bidi_it->first_elt = true, it's possible we shouldn't touch bidi_it->new_paragraph at all... --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Handle-buffers-containing-two-newlines-followed-by-a.patch >From b5302d2e89710166cc8540c8fc08a7eaabc341f4 Mon Sep 17 00:00:00 2001 From: Pip Cet Date: Sat, 6 Jun 2020 07:52:13 +0000 Subject: [PATCH] Handle buffers containing two newlines followed by an RTL char * src/bidi.c (bidi_paragraph_init): Correct handling of initial newlines. (Bug#41506) --- src/bidi.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/bidi.c b/src/bidi.c index 1017bd2d52..8d2d3c1f07 100644 --- a/src/bidi.c +++ b/src/bidi.c @@ -1707,14 +1707,14 @@ bidi_paragraph_init (bidi_dir_t dir, struct bidi_it *bidi_it, bool no_default_p) return; /* If we are on a newline, get past it to where the next - paragraph might start. But don't do that at BEGV since then - we are potentially in a new paragraph that doesn't yet - exist. */ + paragraph might start. But don't do that for the first + element since this function will be called twice in that + case. */ pos = bidi_it->charpos; s = (STRINGP (bidi_it->string.lstring) ? SDATA (bidi_it->string.lstring) : bidi_it->string.s); - if (bytepos > begbyte + if (!bidi_it->first_elt && bidi_char_at_pos (bytepos, s, bidi_it->string.unibyte) == '\n') { bytepos++; -- 2.27.0.rc0 --=-=-= Content-Type: text/plain If you have any further comments, I'd be glad to amend the comments in bidi.c to reflect what we actually do understand. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 04:35:22 2020 Received: (at 41506) by debbugs.gnu.org; 6 Jun 2020 08:35:22 +0000 Received: from localhost ([127.0.0.1]:50648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhUIU-0006eF-70 for submit@debbugs.gnu.org; Sat, 06 Jun 2020 04:35:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhUIS-0006e2-Ts for 41506@debbugs.gnu.org; Sat, 06 Jun 2020 04:35:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58022) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhUIN-0003di-LS; Sat, 06 Jun 2020 04:35:15 -0400 Received: from [176.228.60.248] (port=3867 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhUIM-0006hY-SG; Sat, 06 Jun 2020 04:35:15 -0400 Date: Sat, 06 Jun 2020 11:35:06 +0300 Message-Id: <833678a8xx.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87k10kzkv3.fsf@gmail.com> (message from Pip Cet on Sat, 06 Jun 2020 07:58:24 +0000) Subject: Re: bug#41506: 28.0.50; RTL problem References: <838shhxuff.fsf@gnu.org> <83tuztctpk.fsf@gnu.org> <83ftbdcmm3.fsf@gnu.org> <87k10kzkv3.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Cc: 41506@debbugs.gnu.org > Date: Sat, 06 Jun 2020 07:58:24 +0000 > > when we're called with bidi_it->first_elt = true, it's possible we > shouldn't touch bidi_it->new_paragraph at all... Can you elaborate on why you think that? first_elt can be set when we are at the beginning of a paragraph or when we are in the middle of it, so its meaning is different from that of new_paragraph. > + paragraph might start. But don't do that for the first > + element since this function will be called twice in that > + case. */ Which code causes the two calls, and why is that significant in this case? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 09:05:56 2020 Received: (at 41506) by debbugs.gnu.org; 6 Jun 2020 13:05:56 +0000 Received: from localhost ([127.0.0.1]:51043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhYWJ-0003NB-UT for submit@debbugs.gnu.org; Sat, 06 Jun 2020 09:05:56 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:56288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhYWI-0003My-V7 for 41506@debbugs.gnu.org; Sat, 06 Jun 2020 09:05:55 -0400 Received: by mail-wm1-f46.google.com with SMTP id c71so10833849wmd.5 for <41506@debbugs.gnu.org>; Sat, 06 Jun 2020 06:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=G40V1rQme00epRO7bFANEwX6GmjrUcEbKD2zA1UcXEA=; b=WjaoKSXavhR0TWc7NCXDxnFdVv0uV1oyhVwmysW8IvMvco1HAJbyrnqd/1SWtLLRUU vJhXPaY9tRjF/oQdk1HDR+J6pbAmCk95KWfsvhbEUZNKFr2Jvzwzy0sL/Rsj3xu0vE7r LpP1zLjfd7HO1r9ufzoQh/PHtfqHlarvgXkzUjMRmALzSSJbVtTM9aIl20WMafwXUuo9 dIow150MJ8CDCoyQy2BZJc0EHqtj1gf9orTMtrAQFGVGGUYjo0kPSdruGMP7UNvL3Dy0 QEFxvmbEftMgXr8/hlOSaL8Z9L4MeGw1ZMotz2woss1zpJd6qSUhe5DvkErEg764nlnH gGAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=G40V1rQme00epRO7bFANEwX6GmjrUcEbKD2zA1UcXEA=; b=MILl1c4ltwlll2HSuEiKSkMZuXhm6mu4M4qzgWUldADACee/JMgaEc+BH9ddjuK+z3 5k+yZUgTn01eLLuvI2S6xKc/DoaiqgPU5BjGxc73PQJnyYt9JVVdmW1iChEkUvIPsO5h jQ0mA/rCvXP54YdPk50HLYgBXYVHFOe9WlN6qB8YtkA2Tpeer1oMlWBA8/160BZouikh tWhU18sbnsGH7L4c7G+2b8FoeSpCtEYdnpoP3zkKcwrxNdr35h17b0WfCTWNefx6U9+Q nfMQ3gBV7z9KlDe6j3V3pXPBFo8OYYepKjFSyGN8GHnwkuBY3yXHt8bWN7pq6HABGlrA 2MgA== X-Gm-Message-State: AOAM531Ka2vA4A6qAdv2DaaQkqbuWeynTUW19nK5A9KrdBBdUc+SQl6Q /HQyJWy9cGFbY4OfurynlbwPgg0Wj9w= X-Google-Smtp-Source: ABdhPJzf2DGV3L2hkdWEbZwQBukaeXpQeu3fFr8WNKrOcclSALjLP96cAonIWOxsDOthSHPuGjSlKg== X-Received: by 2002:a1c:4b15:: with SMTP id y21mr7387333wma.32.1591448748731; Sat, 06 Jun 2020 06:05:48 -0700 (PDT) Received: from chametz ([185.220.101.13]) by smtp.gmail.com with ESMTPSA id v6sm8097339wrf.61.2020.06.06.06.05.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2020 06:05:48 -0700 (PDT) From: Pip Cet To: Eli Zaretskii Subject: Re: bug#41506: 28.0.50; RTL problem References: <838shhxuff.fsf@gnu.org> <83tuztctpk.fsf@gnu.org> <83ftbdcmm3.fsf@gnu.org> <87k10kzkv3.fsf@gmail.com> <833678a8xx.fsf@gnu.org> Date: Sat, 06 Jun 2020 13:05:43 +0000 In-Reply-To: <833678a8xx.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Jun 2020 11:35:06 +0300") Message-ID: <871rmsz6mw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Pip Cet >> Cc: 41506@debbugs.gnu.org >> Date: Sat, 06 Jun 2020 07:58:24 +0000 >>=20 >> when we're called with bidi_it->first_elt =3D true, it's possible we >> shouldn't touch bidi_it->new_paragraph at all... > > Can you elaborate on why you think that? Sorry, I shouldn't have said "touch" there. I meant "set", though I no longer think so. > first_elt can be set when we are at the beginning of a paragraph or > when we are in the middle of it, so its meaning is different from that > of new_paragraph. Indeed. >> + paragraph might start. But don't do that for the first >> + element since this function will be called twice in that >> + case. */ > > Which code causes the two calls, and why is that significant in this > case? Maybe this code would be clearer: if (!bidi_it->first_elt) { bytepos++; pos++; } We always look at the paragraph containing the next character to be loaded by bidi_level_of_next_char. If first_elt is set, that is the current character; otherwise, it's the one after that. In the "\n\n=D7=A9" case, this happens: 1. bidi_paragraph_init is called with first_elt =3D 1 at buffer position 1 2. new_paragraph is cleared to false 3. bidi_at_paragraph_end is called for buffer position 2. That looks like a line ending a paragraph, though it's actually a line starting the next paragraph. Still, it returns true. 4. new_paragraph is set again 5. bidi_paragraph_init is called with first_elt =3D 0 at buffer position 1 So everything happens to work in this case, even though several of the assumptions in the bidi code are violated. The code is written to assume paragraphs contain at least two characters: that assumption means it's valid for bidi_paragraph_init to clear new_paragraph. In this case, it's not, but the next line we're looking at, while not actually ending a paragraph, looks like it is... What I'm not sure about is "\n \n=D7=A9". It could be either a single two-line paragraph followed by =D7=A9, or a single-character paragraph followed by another paragraph whose first line happens to contain only a space character; in the first case, paragraph orientation would default to L2R, in the second case, it would be R2L. Do you happen to know what Unicode says for this case? --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Handle-buffers-containing-two-newlines-followed-by-a.patch >From c5232df875d62ead326d5e90f122ab9ac9798e59 Mon Sep 17 00:00:00 2001 From: Pip Cet Date: Sat, 6 Jun 2020 13:02:55 +0000 Subject: [PATCH] Handle buffers containing two newlines followed by an RTL char * src/bidi.c (bidi_paragraph_init): Correct handling of initial newlines. (Bug#41506) --- src/bidi.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/bidi.c b/src/bidi.c index 1017bd2d52..8aa325fe6d 100644 --- a/src/bidi.c +++ b/src/bidi.c @@ -1714,8 +1714,12 @@ bidi_paragraph_init (bidi_dir_t dir, struct bidi_it *bidi_it, bool no_default_p) s = (STRINGP (bidi_it->string.lstring) ? SDATA (bidi_it->string.lstring) : bidi_it->string.s); - if (bytepos > begbyte - && bidi_char_at_pos (bytepos, s, bidi_it->string.unibyte) == '\n') + /* We always look at the paragraph containing the next character + to be loaded by bidi_level_of_next_char. + + This code happens to work for a buffer containing two + newlines followed by an RTL character (Bug#41506). */ + if (!bidi_it->first_elt) { bytepos++; pos++; -- 2.27.0.rc0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 09:45:56 2020 Received: (at 41506) by debbugs.gnu.org; 6 Jun 2020 13:45:56 +0000 Received: from localhost ([127.0.0.1]:51090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhZ92-0006UX-9E for submit@debbugs.gnu.org; Sat, 06 Jun 2020 09:45:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhZ90-0006UK-HY for 41506@debbugs.gnu.org; Sat, 06 Jun 2020 09:45:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60508) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhZ8v-0003qX-7d; Sat, 06 Jun 2020 09:45:49 -0400 Received: from [176.228.60.248] (port=3922 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jhZ8t-0002Pe-Mr; Sat, 06 Jun 2020 09:45:48 -0400 Date: Sat, 06 Jun 2020 16:45:38 +0300 Message-Id: <83lfl08fzx.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <871rmsz6mw.fsf@gmail.com> (message from Pip Cet on Sat, 06 Jun 2020 13:05:43 +0000) Subject: Re: bug#41506: 28.0.50; RTL problem References: <838shhxuff.fsf@gnu.org> <83tuztctpk.fsf@gnu.org> <83ftbdcmm3.fsf@gnu.org> <87k10kzkv3.fsf@gmail.com> <833678a8xx.fsf@gnu.org> <871rmsz6mw.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41506 Cc: 41506@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Cc: 41506@debbugs.gnu.org > Date: Sat, 06 Jun 2020 13:05:43 +0000 > > >> + paragraph might start. But don't do that for the first > >> + element since this function will be called twice in that > >> + case. */ > > > > Which code causes the two calls, and why is that significant in this > > case? > > Maybe this code would be clearer: > > if (!bidi_it->first_elt) > { > bytepos++; > pos++; > } Could be, let's see what is the conclusion of this discussion. > In the "\n\nש" case, this happens: > > 1. bidi_paragraph_init is called with first_elt = 1 at buffer position 1 > 2. new_paragraph is cleared to false > 3. bidi_at_paragraph_end is called for buffer position 2. That looks > like a line ending a paragraph, though it's actually a line starting the > next paragraph. Still, it returns true. > 4. new_paragraph is set again > 5. bidi_paragraph_init is called with first_elt = 0 at buffer position 1 I minor correction to item 3: the second newline in this example is handled as belonging to the previous paragraph. You can see that by examining the behavior of RIGHT and LEFT arrow keys: they behave differently in R2L and L2R paragraphs. > What I'm not sure about is "\n \nש". It could be either a single > two-line paragraph followed by ש, or a single-character paragraph > followed by another paragraph whose first line happens to contain only a > space character; in the first case, paragraph orientation would default > to L2R, in the second case, it would be R2L. Do you happen to know what > Unicode says for this case? It's not Unicode in this case, it's Emacs. If UAX#9 is read and followed strictly, then each \n ends a paragraph and begins a new one. IOW, every physical line is a separate paragraph. This is a direct consequence of Newline's bidi class being B (paragraph separator): (get-char-code-property #x0a 'bidi-class) => B (as mandated by 3.2 in UAX#9), and of rules P1--P3 in UAX#9. However, since in Emacs the usual case is that hard newlines are used to fill text, the default UAX#9 behavior would make no sense, as a line that happens to start with a R2L character would be rendered right-to-left, even if the previous line wasn't. It would produce a randomly jagged display of paragraphs that mix L2R and R2L characters just because a line was broken in a different place by filling. So we use the "higher-level protocols" fire escape (see 4.3 in UAX#9) and define a "paragraph" differently, for the purposes of base paragraph direction: we by default require that paragraphs be separated by empty lines, see bidi-paragraph-separate-re. Thus, the above example by default treats the " \n" line as a paragraph separator, and the ש after it as the start of a new paragraph. (For completeness, we do support the strict interpretation of UAX#9: if you set both bidi-paragraph-start-re and bidi-paragraph-separate-re to "^", you get that. Any code changes we come up with here must therefore be tested at least with those settings as well.)