From unknown Wed Jun 25 02:07:06 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#23801 <23801@debbugs.gnu.org> To: bug#23801 <23801@debbugs.gnu.org> Subject: Status: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers Reply-To: bug#23801 <23801@debbugs.gnu.org> Date: Wed, 25 Jun 2025 09:07:06 +0000 retitle 23801 25.0.95; term.el redraws extremely slow with bidi support ena= bled, and large buffers reassign 23801 emacs submitter 23801 Phil Sainty severity 23801 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 19 06:37:08 2016 Received: (at submit) by debbugs.gnu.org; 19 Jun 2016 10:37:08 +0000 Received: from localhost ([127.0.0.1]:45590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEa6G-0002FD-1B for submit@debbugs.gnu.org; Sun, 19 Jun 2016 06:37:08 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEa6E-0002Ek-3s for submit@debbugs.gnu.org; Sun, 19 Jun 2016 06:37:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEa67-0005YS-7D for submit@debbugs.gnu.org; Sun, 19 Jun 2016 06:37:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEa67-0005YO-42 for submit@debbugs.gnu.org; Sun, 19 Jun 2016 06:36:59 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEa63-0002oK-Vj for bug-gnu-emacs@gnu.org; Sun, 19 Jun 2016 06:36:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEa5z-0005X6-Oc for bug-gnu-emacs@gnu.org; Sun, 19 Jun 2016 06:36:54 -0400 Received: from [219.88.242.62] (port=54272 helo=mail.orcon.net.nz) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEa5z-0005X2-87 for bug-gnu-emacs@gnu.org; Sun, 19 Jun 2016 06:36:51 -0400 Received: from [192.168.20.100] (host-203-94-60-222.xdsl.kinect.net.nz [203.94.60.222] (may be forged)) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id u5JA4c8F013008; Sun, 19 Jun 2016 22:04:57 +1200 From: Phil Sainty To: bug-gnu-emacs@gnu.org Subject: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers Message-ID: <57666E36.6030809@orcon.net.nz> Date: Sun, 19 Jun 2016 22:04:38 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-CanIt-Geo: ip=203.94.60.222; country=NZ; region=Auckland; city=Auckland; latitude=-36.8667; longitude=174.7667; http://maps.google.com/maps?q=-36.8667,174.7667&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 01R8y4Dfi - d796c78f4516 - 20160619 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii 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: -5.0 (-----) This is a spin-off from bug#20611: 24.4; mutt slow in ansi-term. I'm logging a new bug report by request, although it seems to me that this is still the same bug (and 20611 is still open), so I suggest that they can both be closed together once a fix is committed? I've experimented further with this issue since my comments in 20611, and my current observations follow... In certain circumstances, a full-screen redraw in a term.el terminal is incredibly slow, apparently increasing with the (width x height) number of characters in the terminal -- certainly things are dramatically worse when the term window is full-screen, than when it is only small; and as observed below, the slow-down is worse than linear with respect to the number of characters being drawn -- each block of characters drawn takes noticeably more time to draw than the previous block did). The issue affects both GUI and terminal Emacs, and affects all terminal buffers generated by term.el (i.e. this is not specific to `ansi-term' as it was treated in the original bug, but will also affect `term' and any other similar wrapper command which creates a terminal and runs a given program in it.) In my case a full-screen terminal is (210x48) characters, for which the initial screen redraw when running Debian package manager command "dpkg-reconfigure postfix" takes ~7 seconds (with the redraw occurring in three 'blocks' of visible activity, each of which 'instantly' draws the next X characters of the display, followed by some seconds of waiting before the next burst of visible activity. Conversely with a terminal size of (80x21) characters, performance is much better, with a redraw taking ~1 second and not obviously divided into blocks, but all happening at once. I would say that the block size seen in the large terminal would exceed the number of characters visible in the small terminal, so it is not surprising to see it all drawn in a single block of activity.) Curiously, I've just noticed that the redraw in the small case takes ~1 second usually; but if I expand the window and cause a slow redraw, and then reduce it to the original size and try again, the redraw is now much slower (~2 seconds instead of ~1). My speculation is that the amount of preceding text in the buffer is having an effect, because switching from a large window to a small window meant that a lot of the text which had been visible in the large window was no longer visible, yet still present if you scrolled back in the buffer. I've seemingly confirmed this by repeating the process (1. small and quick-ish; 2. large and extremely slow; 3. small again and not as quick as (1)); then deleting the contents of the buffer prior to the final shell prompt and repeating the command a fourth time, for which I once again observed a quick-ish response as per (1). Likewise, adding a lot of preceding text into a large-sized term buffer caused the command to slow down even more. Testing in GUI Emacs with an even larger area (234x53) I was seeing ~10 second redraws initially, and that increased to ~17 seconds after dumping a bunch of other text into the buffer. Furthermore, I see now that the processing time increases for each block displayed during the redraw. I assume all but the final block has the same number of characters, yet the approximate elapsed time when each appears on screen is as follows: ~1 second ~4 seconds ~9 seconds ~10 seconds (n.b. the final block is much smaller than the others) I believe those first three blocks are the same number of characters, yet the processing times needed to draw them are roughly 1, 3, and 5 seconds respectively. (At this point I would hazard a guess that each character drawn is also processing, to some extent, all of the preceding characters?) I haven't tried to delve into the term.el code at all (and I am not familiar with terminal emulation in any case), so I can only hope that these observations might help to explain the root cause of this issue. As established in bug#20611, disabling the bidi support (by either setting bidi-paragraph-direction to 'left-to-right, or by setting bidi-display-reordering to nil) improves the speed of the slow redraws by an order of magnitude. The proposed fix for that bug sets bidi-paragraph-direction in the `ansi-term' command, but this is not general enough. My initial thought is to set the value in `term-mode' instead. I am not familiar with bidi concerns, and do not know whether there is ever a use-case for bidi being active in a term-mode buffer, but I note the following comment in the change committed for the original bug: ;; There's a larger problem here with supporting bidirectional text: ;; the application that writes to the terminal could have its own ;; ideas about displaying bidirectional text, and might not want us ;; reordering the text or deciding on base paragraph direction. One ;; such application is Emacs in TTY mode... FIXME. -Phil In GNU Emacs 25.0.95.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) of 2016-06-18 built on shodan Repository revision: 2ad3d0182df68f00cca57584807f721c3c5c96f1 Windowing system distributor 'The X.Org Foundation', version 11.0.11701000 System Description: Ubuntu 15.04 Configured using: 'configure --prefix=/home/phil/emacs/trunk/usr/local --with-x-toolkit=lucid --without-sound' Configured features: XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GSETTINGS NOTIFY GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 Important settings: value of $LANG: en_NZ.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. GNU Emacs 25.0.95.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) of 2016-06-18 Mark activated Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message dired format-spec rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 88249 8416) (symbols 48 20114 0) (miscs 40 46 146) (strings 32 15667 3956) (string-bytes 1 429343) (vectors 16 11737) (vector-slots 8 429691 5060) (floats 8 166 283) (intervals 56 223 0) (buffers 976 11) (heap 1024 29329 1004)) From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 19 12:26:40 2016 Received: (at 23801) by debbugs.gnu.org; 19 Jun 2016 16:26:40 +0000 Received: from localhost ([127.0.0.1]:46582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEfYW-0003tb-J2 for submit@debbugs.gnu.org; Sun, 19 Jun 2016 12:26:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEfYV-0003tM-AU for 23801@debbugs.gnu.org; Sun, 19 Jun 2016 12:26:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEfYL-0002cT-DO for 23801@debbugs.gnu.org; Sun, 19 Jun 2016 12:26:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEfYL-0002cP-9r; Sun, 19 Jun 2016 12:26:29 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2690 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bEfYI-0007FB-Qu; Sun, 19 Jun 2016 12:26:27 -0400 Date: Sun, 19 Jun 2016 19:26:18 +0300 Message-Id: <83pord87rp.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-reply-to: <57666E36.6030809@orcon.net.nz> (message from Phil Sainty on Sun, 19 Jun 2016 22:04:38 +1200) Subject: Re: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers References: <57666E36.6030809@orcon.net.nz> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 23801 Cc: 23801@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Phil Sainty > Cc: Eli Zaretskii > Date: Sun, 19 Jun 2016 22:04:38 +1200 > > This is a spin-off from bug#20611: 24.4; mutt slow in ansi-term. > > I'm logging a new bug report by request, although it seems to me that > this is still the same bug (and 20611 is still open), so I suggest that > they can both be closed together once a fix is committed? > > I've experimented further with this issue since my comments in 20611, > and my current observations follow... Thanks. My problem is that I don't see these slow redraws. I tried in a TTY session on a GNU/Linux system, using "ls ~" as the command inside term-mode (my home directory on that system produces a 1500-line list of files). I don't see slow redraws, and don't see any perceptible speed-up when I set bidi-paragraph-direction to left-to-right. Can you reproduce the problem using 'ls'? From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 19 19:41:26 2016 Received: (at 23801) by debbugs.gnu.org; 19 Jun 2016 23:41:26 +0000 Received: from localhost ([127.0.0.1]:46794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEmLF-0000ZR-Pk for submit@debbugs.gnu.org; Sun, 19 Jun 2016 19:41:25 -0400 Received: from [219.88.242.59] (port=34471 helo=mail.orcon.net.nz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEmLC-0000ZG-Ot for 23801@debbugs.gnu.org; Sun, 19 Jun 2016 19:41:23 -0400 Received: from webmail-1.orcon.net.nz ([10.253.37.41]) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id u5JNfHZb010041; Mon, 20 Jun 2016 11:41:18 +1200 Received: from mail.orcon.net.nz (localhost [IPv6:::1]) by webmail-1.orcon.net.nz (Postfix) with ESMTP id CD5DA2012C41; Mon, 20 Jun 2016 11:41:17 +1200 (NZST) Received: from wlg-office-ffw.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by mail.orcon.net.nz with HTTP (HTTP/1.1 POST); Mon, 20 Jun 2016 11:41:17 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 20 Jun 2016 11:41:17 +1200 From: Phil Sainty To: Eli Zaretskii Subject: Re: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers In-Reply-To: <83pord87rp.fsf@gnu.org> References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-Spam-Score: -3.00 () [Hold at 3.00] FREEMAIL_FROM:0.001,CC(NZ:-3) X-CanIt-Geo: ip=202.78.240.7; country=NZ; region=Wellington; city=Wellington; latitude=-41.2798; longitude=174.7761; http://maps.google.com/maps?q=-41.2798,174.7761&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 02R8LFhxl - 18156b293009 - 20160620 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.250.8.6 X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 2016-06-20 04:26, Eli Zaretskii wrote: > My problem is that I don't see these slow redraws. I tried in a TTY > session on a GNU/Linux system, using "ls ~" as the command inside > term-mode (my home directory on that system produces a 1500-line list > of files). I don't see slow redraws, and don't see any perceptible > speed-up when I set bidi-paragraph-direction to left-to-right. > > Can you reproduce the problem using 'ls'? [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.59 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.59 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 23801 Cc: 23801@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.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 2016-06-20 04:26, Eli Zaretskii wrote: > My problem is that I don't see these slow redraws. I tried in a TTY > session on a GNU/Linux system, using "ls ~" as the command inside > term-mode (my home directory on that system produces a 1500-line list > of files). I don't see slow redraws, and don't see any perceptible > speed-up when I set bidi-paragraph-direction to left-to-right. > > Can you reproduce the problem using 'ls'? [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.59 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.59 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS On 2016-06-20 04:26, Eli Zaretskii wrote: > My problem is that I don't see these slow redraws. I tried in a TTY > session on a GNU/Linux system, using "ls ~" as the command inside > term-mode (my home directory on that system produces a 1500-line list > of files). I don't see slow redraws, and don't see any perceptible > speed-up when I set bidi-paragraph-direction to left-to-right. > > Can you reproduce the problem using 'ls'? No, the majority of commands do respond quickly. I suspect you'll need to do something which repaints the entire terminal. The examples I know of are starting the "mutt" email client (as per the original report) or, for Debian, running "dpkg-reconfigure" for some package with a configuration menu. I'm sure there will be plenty of others, but I'm afraid I can't suggest a more commonly-available example at the moment. If you have anything which provides a full-screen terminal UI, however, give that a try. Both previous examples are drawing a background colour (before eventually drawing some text over the top, which happens quickly). Perhaps there are a ton of escape sequences being processed for the colours? (I would have thought the colouring was just a single ON and OFF wrapping the entire redraw, but I don't know how these things actually work). I've just tried installing and running "mc", which was another example I thought I'd seen mentioned somewhere. That's GNU Midnight Commander. This one is curious in that its initial redraw (with a background colour) is pretty fast regardless; however when you quit (type "exit" at the prompt), there's a slow redraw to get back to the shell (but also a bit faster than my other examples). I guess it simply depends on exactly what each application is doing. GNU Midnight Commander is a file manager. I think "mc" followed by "exit" should be a pretty easy/safe test for you to try? From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 19 20:00:12 2016 Received: (at 23801) by debbugs.gnu.org; 20 Jun 2016 00:00:12 +0000 Received: from localhost ([127.0.0.1]:46809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEmdQ-0000zy-4Z for submit@debbugs.gnu.org; Sun, 19 Jun 2016 20:00:12 -0400 Received: from [219.88.242.56] (port=48517 helo=mail.orcon.net.nz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEmdO-0000zq-Au for 23801@debbugs.gnu.org; Sun, 19 Jun 2016 20:00:11 -0400 Received: from webmail-1.orcon.net.nz ([10.253.37.41]) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id u5K006Hs000466; Mon, 20 Jun 2016 12:00:06 +1200 Received: from mail.orcon.net.nz (localhost [IPv6:::1]) by webmail-1.orcon.net.nz (Postfix) with ESMTP id 2163F2186B1D; Mon, 20 Jun 2016 12:00:06 +1200 (NZST) Received: from wlg-office-ffw.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by mail.orcon.net.nz with HTTP (HTTP/1.1 POST); Mon, 20 Jun 2016 12:00:06 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 20 Jun 2016 12:00:06 +1200 From: Phil Sainty To: Eli Zaretskii Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers In-Reply-To: References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> Message-ID: <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-Spam-Score: -3.00 () [Hold at 3.00] FREEMAIL_FROM:0.001,CC(NZ:-3) X-CanIt-Geo: ip=202.78.240.7; country=NZ; region=Wellington; city=Wellington; latitude=-41.2798; longitude=174.7761; http://maps.google.com/maps?q=-41.2798,174.7761&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 01R8M06A3 - b5f3fbd8ada8 - 20160620 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.250.8.5 X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: The "lynx" web browser is another example which may be convenient to try. Starting lynx causes a slow redraw. Exit with 'q' (and 'y' to confirm). [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.56 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.56 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 23801 Cc: 23801@debbugs.gnu.org, bug-gnu-emacs 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.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: The "lynx" web browser is another example which may be convenient to try. Starting lynx causes a slow redraw. Exit with 'q' (and 'y' to confirm). [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.56 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.56 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS The "lynx" web browser is another example which may be convenient to try. Starting lynx causes a slow redraw. Exit with 'q' (and 'y' to confirm). From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 10:29:47 2016 Received: (at 23801) by debbugs.gnu.org; 20 Jun 2016 14:29:47 +0000 Received: from localhost ([127.0.0.1]:47806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0Cx-00066H-5R for submit@debbugs.gnu.org; Mon, 20 Jun 2016 10:29:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34907) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0Cv-000662-G7 for 23801@debbugs.gnu.org; Mon, 20 Jun 2016 10:29:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF0Cn-0003FY-NO for 23801@debbugs.gnu.org; Mon, 20 Jun 2016 10:29:40 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF0Cn-0003FN-Jn; Mon, 20 Jun 2016 10:29:37 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3418 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bF0Cl-0004WP-Np; Mon, 20 Jun 2016 10:29:36 -0400 Date: Mon, 20 Jun 2016 17:28:43 +0300 Message-Id: <83d1nc7x44.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-reply-to: (message from Phil Sainty on Mon, 20 Jun 2016 11:41:17 +1200) Subject: Re: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 23801 Cc: 23801@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > Date: Mon, 20 Jun 2016 11:41:17 +1200 > From: Phil Sainty > Cc: 23801@debbugs.gnu.org > > > Can you reproduce the problem using 'ls'? > > No, the majority of commands do respond quickly. > > I suspect you'll need to do something which repaints the entire > terminal. I don't understand what that means. The output from "ls" repaints the entire terminal as well, as it produces 1500 lines, much more than is shown in the window. Perhaps you mean cursor motion commands, i.e. escape sequences that move the cursor up and down the screen, not just down? But if that is the reason, I'd expect to see its signs in the profile, which was not the case, I think. If you load term.el (not the .elc file!), and then run your experiments under the profiler (profiler-start), what does profiler-report produce? > Both previous examples are drawing a background colour (before > eventually > drawing some text over the top, which happens quickly). Perhaps there > are > a ton of escape sequences being processed for the colours? Probably, but I don't see how bidirectional display could slow down this processing, because AFAIU these escape sequences are converted to faces that are put on the displayed text, something that doesn't involve the bidirectional reordering for display at all. > I guess it simply depends on exactly what each application is > doing. GNU Midnight Commander is a file manager. I think "mc" > followed by "exit" should be a pretty easy/safe test for you to try? My problem is precisely that I cannot figure out what could the application be doing that would be so profoundly affected by bidirectional display. Does making the screen buffer (term-buffer-maximum-size) smaller help in any way? From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 10:35:59 2016 Received: (at 23801) by debbugs.gnu.org; 20 Jun 2016 14:35:59 +0000 Received: from localhost ([127.0.0.1]:47810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0Iw-0006GA-UF for submit@debbugs.gnu.org; Mon, 20 Jun 2016 10:35:59 -0400 Received: from [219.88.242.62] (port=38749 helo=mail.orcon.net.nz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0Iu-0006G0-PA for 23801@debbugs.gnu.org; Mon, 20 Jun 2016 10:35:57 -0400 Received: from [192.168.20.100] (host-203-94-60-222.xdsl.kinect.net.nz [203.94.60.222] (may be forged)) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id u5KEZlxd007379; Tue, 21 Jun 2016 02:35:48 +1200 Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers To: 23801@debbugs.gnu.org References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> From: Phil Sainty Message-ID: <5767FF42.10208@orcon.net.nz> Date: Tue, 21 Jun 2016 02:35:46 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-Spam-Score: -1.71 () [Hold at 3.00] FREEMAIL_FROM:0.001, RDNS_NONE:1.274, TO_NO_BRKTS_NORDNS:0.001, T_TO_NO_BRKTS_FREEMAIL:0.01, CC(NZ:-3) X-CanIt-Geo: ip=203.94.60.222; country=NZ; region=Auckland; city=Auckland; latitude=-36.8667; longitude=174.7667; http://maps.google.com/maps?q=-36.8667,174.7667&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 01R92zL0f - 3053bf5b6734 - 20160621 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Progress... I believe the terminal screen refreshes which exhibit the issue are performed by inserting spaces (with a background colour). It turns out that we can demonstrate this issue without any other programs, simply by inserting spaces (or tabs). [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 23801 Cc: Eli Zaretskii 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.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Progress... I believe the terminal screen refreshes which exhibit the issue are performed by inserting spaces (with a background colour). It turns out that we can demonstrate this issue without any other programs, simply by inserting spaces (or tabs). [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS Progress... I believe the terminal screen refreshes which exhibit the issue are performed by inserting spaces (with a background colour). It turns out that we can demonstrate this issue without any other programs, simply by inserting spaces (or tabs). Most critically, inserting non-whitespace characters does NOT cause performance issues! (At least not the ones I've tried.) (This presumably explains why midnight commander's initial draw was so comparatively speedy, as it was drawing the final content from the outset, rather than clearing the screen first and then writing the content.) Recipe: emacs -Q (and maximise the terminal or GUI frame) M-x term (and run a shell) printf "%10000s" x (to insert an 'x' preceded by 9,999 spaces.) That's not as obvious without a background colour, but we can provide that easily enough: printf "\033[41m%10000s\033[47m" x (Drawing in red, and reverting to a white background. Use 40m in the final sequence if you need to revert to black instead.) Bash supports numeric prefix arguments for repetition just like Emacs, so you can also insert lots of spaces like so: M-10000 SPC You can insert 1,000 TABs with: M-1000 C-v C-i With this approach we are entering (but not yet submitting) a command, and I further note that using C-u at this point to erase our input is also really slow to complete -- but again, only when it is whitespace being 'erased'. e.g. M-10000 x C-u is perfectly speedy. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 11:06:35 2016 Received: (at 23801) by debbugs.gnu.org; 20 Jun 2016 15:06:35 +0000 Received: from localhost ([127.0.0.1]:47853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0mY-00009r-RJ for submit@debbugs.gnu.org; Mon, 20 Jun 2016 11:06:35 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47315) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0mW-00009e-Ry for 23801@debbugs.gnu.org; Mon, 20 Jun 2016 11:06:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF0mO-0003T9-GQ for 23801@debbugs.gnu.org; Mon, 20 Jun 2016 11:06:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF0mO-0003SU-D6; Mon, 20 Jun 2016 11:06:24 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3449 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bF0mM-0006zE-Al; Mon, 20 Jun 2016 11:06:22 -0400 Date: Mon, 20 Jun 2016 18:05:29 +0300 Message-Id: <83y45z7veu.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-reply-to: <5767FF42.10208@orcon.net.nz> (message from Phil Sainty on Tue, 21 Jun 2016 02:35:46 +1200) Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> <5767FF42.10208@orcon.net.nz> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 23801 Cc: 23801@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Phil Sainty > Cc: Eli Zaretskii > Date: Tue, 21 Jun 2016 02:35:46 +1200 > > I believe the terminal screen refreshes which exhibit the issue > are performed by inserting spaces (with a background colour). Is background color really necessary? > It turns out that we can demonstrate this issue without any other > programs, simply by inserting spaces (or tabs). > > Most critically, inserting non-whitespace characters does NOT > cause performance issues! (At least not the ones I've tried.) Thanks, this finally begins to make sense. I will look into this when I have time. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 11:08:08 2016 Received: (at 23801) by debbugs.gnu.org; 20 Jun 2016 15:08:08 +0000 Received: from localhost ([127.0.0.1]:47857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0o4-0000CH-7r for submit@debbugs.gnu.org; Mon, 20 Jun 2016 11:08:08 -0400 Received: from [219.88.242.59] (port=53608 helo=mail.orcon.net.nz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0o1-0000C9-T9 for 23801@debbugs.gnu.org; Mon, 20 Jun 2016 11:08:06 -0400 Received: from [192.168.20.100] (host-203-94-60-222.xdsl.kinect.net.nz [203.94.60.222] (may be forged)) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id u5KF7w7c034664; Tue, 21 Jun 2016 03:08:00 +1200 Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers To: 23801@debbugs.gnu.org References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <83d1nc7x44.fsf@gnu.org> From: Phil Sainty Message-ID: <576806CE.8080007@orcon.net.nz> Date: Tue, 21 Jun 2016 03:07:58 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <83d1nc7x44.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-Spam-Score: -1.71 () [Hold at 3.00] FREEMAIL_FROM:0.001, RDNS_NONE:1.274, TO_NO_BRKTS_NORDNS:0.001, T_TO_NO_BRKTS_FREEMAIL:0.01, CC(NZ:-3) X-CanIt-Geo: ip=203.94.60.222; country=NZ; region=Auckland; city=Auckland; latitude=-36.8667; longitude=174.7667; http://maps.google.com/maps?q=-36.8667,174.7667&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 02R937X4T - dee50e4af541 - 20160621 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 21/06/16 02:28, Eli Zaretskii wrote: >> I suspect you'll need to do something which repaints the entire >> terminal. > > I don't understand what that means. The output from "ls" repaints the > entire terminal as well, as it produces 1500 lines, much more than is > shown in the window. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.59 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.59 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 23801 Cc: Eli Zaretskii 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.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 21/06/16 02:28, Eli Zaretskii wrote: >> I suspect you'll need to do something which repaints the entire >> terminal. > > I don't understand what that means. The output from "ls" repaints the > entire terminal as well, as it produces 1500 lines, much more than is > shown in the window. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.59 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.59 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS On 21/06/16 02:28, Eli Zaretskii wrote: >> I suspect you'll need to do something which repaints the entire >> terminal. > > I don't understand what that means. The output from "ls" repaints the > entire terminal as well, as it produces 1500 lines, much more than is > shown in the window. Yes, in hindsight the slow redraws with a background colour were so blatantly drawing every single character in the terminal that I was imagining that other kinds of command output (with less colourful results) did not need to do that; and that the problem was therefore connected to the slow redraws processing many more characters than was necessary for other kinds of screen update. Now that I've (AFAICS) isolated the issue to whitespace, I can see that my earlier presumption doesn't actually make much sense. Apologies for the confusion. Let me know if you'd still like me to provide profiler or elp results? I'm well and truly done for the night, but I can follow up tomorrow. (I'm hoping that with the prior email you're now able to replicate the issue, though?) From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 14:48:52 2016 Received: (at 23801) by debbugs.gnu.org; 21 Jun 2016 18:48:52 +0000 Received: from localhost ([127.0.0.1]:50045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFQjD-0003C2-RN for submit@debbugs.gnu.org; Tue, 21 Jun 2016 14:48:52 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFQjC-0003Bo-0B for 23801@debbugs.gnu.org; Tue, 21 Jun 2016 14:48:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFQj3-00060m-Qo for 23801@debbugs.gnu.org; Tue, 21 Jun 2016 14:48:44 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFQj3-00060T-No; Tue, 21 Jun 2016 14:48:41 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1101 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFQix-0000jv-T2; Tue, 21 Jun 2016 14:48:40 -0400 Date: Tue, 21 Jun 2016 21:47:32 +0300 Message-Id: <83r3bq5qgr.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-reply-to: <5767FF42.10208@orcon.net.nz> (message from Phil Sainty on Tue, 21 Jun 2016 02:35:46 +1200) Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> <5767FF42.10208@orcon.net.nz> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 23801 Cc: 23801@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Phil Sainty > Cc: Eli Zaretskii > Date: Tue, 21 Jun 2016 02:35:46 +1200 > > emacs -Q (and maximise the terminal or GUI frame) > M-x term (and run a shell) > printf "%10000s" x > > (to insert an 'x' preceded by 9,999 spaces.) > > That's not as obvious without a background colour, but we can > provide that easily enough: > > printf "\033[41m%10000s\033[47m" x > > (Drawing in red, and reverting to a white background. Use 40m > in the final sequence if you need to revert to black instead.) > > > Bash supports numeric prefix arguments for repetition just like > Emacs, so you can also insert lots of spaces like so: > > M-10000 SPC > > You can insert 1,000 TABs with: > M-1000 C-v C-i > > > With this approach we are entering (but not yet submitting) a > command, and I further note that using C-u at this point to erase > our input is also really slow to complete -- but again, only when > it is whitespace being 'erased'. > > e.g. M-10000 x C-u is perfectly speedy. Can you try this in an Emacs built from the latest master branch of the Emacs Git repository? It could be that the current development sources already provide improvement in these cases. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 22 09:13:21 2016 Received: (at 23801) by debbugs.gnu.org; 22 Jun 2016 13:13:21 +0000 Received: from localhost ([127.0.0.1]:50436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFhy5-0007Op-B6 for submit@debbugs.gnu.org; Wed, 22 Jun 2016 09:13:21 -0400 Received: from [219.88.242.56] (port=40252 helo=mail.orcon.net.nz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFhy2-0007Of-Ic for 23801@debbugs.gnu.org; Wed, 22 Jun 2016 09:13:19 -0400 Received: from [192.168.20.100] (host-203-94-60-222.xdsl.kinect.net.nz [203.94.60.222] (may be forged)) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id u5MDD8X8028782; Thu, 23 Jun 2016 01:13:10 +1200 Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers To: Eli Zaretskii References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> <5767FF42.10208@orcon.net.nz> <83r3bq5qgr.fsf@gnu.org> From: Phil Sainty Message-ID: <576A8EE4.5090107@orcon.net.nz> Date: Thu, 23 Jun 2016 01:13:08 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <83r3bq5qgr.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-Spam-Score: -1.73 () [Hold at 3.00] FREEMAIL_FROM:0.001, RDNS_NONE:1.274, CC(NZ:-3) X-CanIt-Geo: ip=203.94.60.222; country=NZ; region=Auckland; city=Auckland; latitude=-36.8667; longitude=174.7667; http://maps.google.com/maps?q=-36.8667,174.7667&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 01R9Nd9BW - 4cec2bfae6a3 - 20160623 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 22/06/16 06:47, Eli Zaretskii wrote: > Can you try this in an Emacs built from the latest master branch of > the Emacs Git repository? It could be that the current development > sources already provide improvement in these cases. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.56 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.56 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 23801 Cc: 23801@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.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 22/06/16 06:47, Eli Zaretskii wrote: > Can you try this in an Emacs built from the latest master branch of > the Emacs Git repository? It could be that the current development > sources already provide improvement in these cases. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [219.88.242.56 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [219.88.242.56 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS On 22/06/16 06:47, Eli Zaretskii wrote: > Can you try this in an Emacs built from the latest master branch of > the Emacs Git repository? It could be that the current development > sources already provide improvement in these cases. Indeed, the master branch emacs -Q seems as quick as 24 and 25 do with their bidi support disabled. Excellent! Presumably these fixes aren't going to make it into 25.1. Should I anticipate that 25.2 will include them? From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 22 11:28:18 2016 Received: (at 23801) by debbugs.gnu.org; 22 Jun 2016 15:28:18 +0000 Received: from localhost ([127.0.0.1]:51317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFk4g-0005Yf-LB for submit@debbugs.gnu.org; Wed, 22 Jun 2016 11:28:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFk4f-0005YM-Ey for 23801@debbugs.gnu.org; Wed, 22 Jun 2016 11:28:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFk4Y-0005Dq-Rb for 23801@debbugs.gnu.org; Wed, 22 Jun 2016 11:28:12 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFk4Y-0005Df-Oc; Wed, 22 Jun 2016 11:28:10 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1884 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFk4X-0007lp-Uh; Wed, 22 Jun 2016 11:28:10 -0400 Date: Wed, 22 Jun 2016 18:27:21 +0300 Message-Id: <83shw5452e.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-reply-to: <576A8EE4.5090107@orcon.net.nz> (message from Phil Sainty on Thu, 23 Jun 2016 01:13:08 +1200) Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> <5767FF42.10208@orcon.net.nz> <83r3bq5qgr.fsf@gnu.org> <576A8EE4.5090107@orcon.net.nz> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.5 (------) X-Debbugs-Envelope-To: 23801 Cc: 23801@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.5 (------) > Cc: 23801@debbugs.gnu.org > From: Phil Sainty > Date: Thu, 23 Jun 2016 01:13:08 +1200 > > On 22/06/16 06:47, Eli Zaretskii wrote: > > Can you try this in an Emacs built from the latest master branch of > > the Emacs Git repository? It could be that the current development > > sources already provide improvement in these cases. > > Indeed, the master branch emacs -Q seems as quick as 24 and 25 do > with their bidi support disabled. Thanks for testing. So I think this bug can be closed. > Presumably these fixes aren't going to make it into 25.1. Should > I anticipate that 25.2 will include them? We are still debating whether 25.2 will be produced from the master branch or from emacs-25. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 25 20:35:50 2016 Received: (at 23801) by debbugs.gnu.org; 26 Jun 2016 00:35:50 +0000 Received: from localhost ([127.0.0.1]:55830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGy3C-0001Sk-FM for submit@debbugs.gnu.org; Sat, 25 Jun 2016 20:35:50 -0400 Received: from [219.88.242.22] (port=41553 helo=mail.orcon.net.nz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGy3A-0001SW-SB for 23801@debbugs.gnu.org; Sat, 25 Jun 2016 20:35:49 -0400 Received: from [192.168.20.100] ([150.107.172.115]) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id u5Q0ZeVq044269; Sun, 26 Jun 2016 12:35:41 +1200 Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers To: Eli Zaretskii References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> <5767FF42.10208@orcon.net.nz> <83r3bq5qgr.fsf@gnu.org> <576A8EE4.5090107@orcon.net.nz> <83shw5452e.fsf@gnu.org> From: Phil Sainty Message-ID: <576F235C.8070409@orcon.net.nz> Date: Sun, 26 Jun 2016 12:35:40 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <83shw5452e.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-Spam-Score: -1.73 () [Hold at 3.00] FREEMAIL_FROM:0.001, RDNS_NONE:1.274, CC(NZ:-3) X-CanIt-Geo: ip=150.107.172.115; country=NZ; region=Auckland; city=Auckland; latitude=-36.8667; longitude=174.7667; http://maps.google.com/maps?q=-36.8667,174.7667&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 02RbczF9p - 7e0258ca0ad7 - 20160626 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 23/06/16 03:27, Eli Zaretskii wrote: > Thanks for testing. So I think this bug can be closed. Yes, agreed. Bug #20611 can potentially be closed as well, with the caveat that there was a workaround commit made for that one, and it is presumably important to ensure that the workaround will not get merged to master later on, being unnecessary in that branch. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 23801 Cc: 23801@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.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 23/06/16 03:27, Eli Zaretskii wrote: > Thanks for testing. So I think this bug can be closed. Yes, agreed. Bug #20611 can potentially be closed as well, with the caveat that there was a workaround commit made for that one, and it is presumably important to ensure that the workaround will not get merged to master later on, being unnecessary in that branch. [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS On 23/06/16 03:27, Eli Zaretskii wrote: > Thanks for testing. So I think this bug can be closed. Yes, agreed. Bug #20611 can potentially be closed as well, with the caveat that there was a workaround commit made for that one, and it is presumably important to ensure that the workaround will not get merged to master later on, being unnecessary in that branch. (Although I'd still be inclined to shift that workaround to act in term-mode-hook rather than in ansi-term. I'll follow up in that bug, though.) > We are still debating whether 25.2 will be produced from the > master branch or from emacs-25. Ok. Either way, if we have the workaround in effect in emacs-25, and the real fix in master, this problem is dealt with for the upcoming releases. thanks, -Phil From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 26 12:45:45 2016 Received: (at 23801) by debbugs.gnu.org; 26 Jun 2016 16:45:45 +0000 Received: from localhost ([127.0.0.1]:56956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bHDBp-0000KJ-9B for submit@debbugs.gnu.org; Sun, 26 Jun 2016 12:45:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bHDBn-0000K7-Fn for 23801@debbugs.gnu.org; Sun, 26 Jun 2016 12:45:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHDBe-0000HU-RY for 23801@debbugs.gnu.org; Sun, 26 Jun 2016 12:45:38 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHDBe-0000HO-JJ; Sun, 26 Jun 2016 12:45:34 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2701 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bHDBa-0001WF-G1; Sun, 26 Jun 2016 12:45:33 -0400 Date: Sun, 26 Jun 2016 19:45:12 +0300 Message-Id: <8360svzyp3.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-reply-to: <576F235C.8070409@orcon.net.nz> (message from Phil Sainty on Sun, 26 Jun 2016 12:35:40 +1200) Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> <5767FF42.10208@orcon.net.nz> <83r3bq5qgr.fsf@gnu.org> <576A8EE4.5090107@orcon.net.nz> <83shw5452e.fsf@gnu.org> <576F235C.8070409@orcon.net.nz> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 23801 Cc: 23801@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > Cc: 23801@debbugs.gnu.org > From: Phil Sainty > Date: Sun, 26 Jun 2016 12:35:40 +1200 > > On 23/06/16 03:27, Eli Zaretskii wrote: > > Thanks for testing. So I think this bug can be closed. > > Yes, agreed. > > > Bug #20611 can potentially be closed as well, with the caveat > that there was a workaround commit made for that one, and it > is presumably important to ensure that the workaround will not > get merged to master later on, being unnecessary in that branch. Done. > (Although I'd still be inclined to shift that workaround to act > in term-mode-hook rather than in ansi-term. I'll follow up in > that bug, though.) Also done. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 26 12:46:13 2016 Received: (at 23801-done) by debbugs.gnu.org; 26 Jun 2016 16:46:13 +0000 Received: from localhost ([127.0.0.1]:56960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bHDCH-0000Ld-HL for submit@debbugs.gnu.org; Sun, 26 Jun 2016 12:46:13 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bHDCF-0000LP-FE for 23801-done@debbugs.gnu.org; Sun, 26 Jun 2016 12:46:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHDC9-0000KE-PP for 23801-done@debbugs.gnu.org; Sun, 26 Jun 2016 12:46:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHDC9-0000K8-MU for 23801-done@debbugs.gnu.org; Sun, 26 Jun 2016 12:46:05 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2702 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bHDC6-0001Yj-Ux for 23801-done@debbugs.gnu.org; Sun, 26 Jun 2016 12:46:04 -0400 Date: Sun, 26 Jun 2016 19:45:49 +0300 Message-Id: <834m8fzyo2.fsf@gnu.org> From: Eli Zaretskii To: 23801-done@debbugs.gnu.org In-reply-to: <576F235C.8070409@orcon.net.nz> (message from Phil Sainty on Sun, 26 Jun 2016 12:35:40 +1200) Subject: Re: bug#23801: 25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers References: <57666E36.6030809@orcon.net.nz> <83pord87rp.fsf@gnu.org> <0b5cd701be526f2391bb8fe15bb120c7@mail.orcon.net.nz> <5767FF42.10208@orcon.net.nz> <83r3bq5qgr.fsf@gnu.org> <576A8EE4.5090107@orcon.net.nz> <83shw5452e.fsf@gnu.org> <576F235C.8070409@orcon.net.nz> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 23801-done 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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > Cc: 23801@debbugs.gnu.org > From: Phil Sainty > Date: Sun, 26 Jun 2016 12:35:40 +1200 > > On 23/06/16 03:27, Eli Zaretskii wrote: > > Thanks for testing. So I think this bug can be closed. > > Yes, agreed. Done. From unknown Wed Jun 25 02:07:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 25 Jul 2016 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator