From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Fri, 10 Aug 2012 03:27:04 -0400 Message-ID: <2AB38709-2307-437E-A242-70B8A358BE4F@permabit.com> References: <6eipe9fypj.fsf@just-testing.permabit.com> <83d34h739a.fsf@gnu.org> <501848BE.10702@permabit.com> <5021D940.8050401@permabit.com> <415962DC-9BF5-4595-8180-7BE8DB545206@permabit.com> <502427D2.3080003@permabit.com> <83ipcre0fm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1344583678 9884 80.91.229.3 (10 Aug 2012 07:27:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2012 07:27:58 +0000 (UTC) Cc: 11822@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 10 09:27:59 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SzjdV-0008TV-OO for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Aug 2012 09:27:57 +0200 Original-Received: from localhost ([::1]:53970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzjdR-0007n4-VN for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Aug 2012 03:27:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzjdN-0007mg-Jn for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:27:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzjdM-0003wb-9Q for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:27:49 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzjdM-0003wR-5T for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:27:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SzjlJ-00043l-Sw for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Aug 2012 07:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11822 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11822-submit@debbugs.gnu.org id=B11822.134458412115555 (code B ref 11822); Fri, 10 Aug 2012 07:36:01 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 10 Aug 2012 07:35:21 +0000 Original-Received: from localhost ([127.0.0.1]:45883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szjke-00042q-Ic for submit@debbugs.gnu.org; Fri, 10 Aug 2012 03:35:21 -0400 Original-Received: from pbit-mailserver.permabit.com ([204.246.225.83]:53279) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szjkd-00042j-J9 for 11822@debbugs.gnu.org; Fri, 10 Aug 2012 03:35:20 -0400 Original-Received: from [10.2.0.50] (vpn-50.permabit.com [10.2.0.50]) by pbit-mailserver.permabit.com (Postfix) with ESMTPSA id EED58148E1F4; Fri, 10 Aug 2012 03:27:04 -0400 (EDT) In-Reply-To: <83ipcre0fm.fsf@gnu.org> X-Mailer: Apple Mail (2.1278) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:62990 Archived-At: On Aug 10, 2012, at 02:16, Eli Zaretskii wrote: > Normally, the frame's face cache is not removed during redisplay of > frame's windows, so you get one call per frame. For new frames, the > cache is empty, so you get 3 calls for each window on the new frame, > which are: the frame's selected window, the menu bar, and the tool bar > (the last two are displayed in a special kinds of window). For > example, the backtrace above comes from displaying the menu bar. Ah, that's interesting. It's especially interesting considering I have = menu bar and tool bar displays turned off. The one frame (X11 window) I = have on the remote display is subdivided into four Emacs windows (top vs = bottom, then each of those split into left and right). And there's the = minibuffer, of course. Currently three of those four windows have = header lines, but there is no tool bar or menu bar. >=20 >> But either way, we get into the display code and it thinks it's got = to=20 >> do the color/face setup all over again for the remote display. >=20 > If the face cache is empty, what else can it do? I haven't really looked at the redisplay code much, but shouldn't a = cache be, I don't know, caching this stuff it keeps looking up over and = over? According to the code you quoted, it's a "face cache", and all I = see is color-processing calls, but if we're not building faces, why do = we need the color processing, and if we are building them, why aren't we = caching them? Oh, hmm=85 the code you quoted ensures that the indicated frame has a = face cache, and conditionally calls recompute_basic_faces; that function = checks that there is a face cache, and if so, calls clear_face_cache and = then realize_basic_faces. But clear_face_cache clears caches of all = frames. So if I understand correctly, if that function you quoted = (init_iterator) is given a frame with no cache (which I assume is the = state a new frame is in?), or if the cache "used" flag is clear, it'll = wipe out all cached faces from all frames, so the higher-level iteration = over all the frames (or windows?) will have to rebuild the faces, even = if they had indeed been cached. Is that correct? Is there a reason recompute_basic_faces can't just clear the cache for = its own frame and leave the others alone? Ken=