From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Fri, 10 Aug 2012 10:46:23 +0300 Message-ID: <83a9y3dwa8.fsf@gnu.org> 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> <2AB38709-2307-437E-A242-70B8A358BE4F@permabit.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1344584813 18073 80.91.229.3 (10 Aug 2012 07:46:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2012 07:46:53 +0000 (UTC) Cc: 11822@debbugs.gnu.org To: Ken Raeburn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 10 09:46:53 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 1Szjvo-0003uj-Q6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Aug 2012 09:46:53 +0200 Original-Received: from localhost ([::1]:59819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Szjvo-0004Ad-1s for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Aug 2012 03:46:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Szjvm-0004AX-4p for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:46:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Szjvl-0001eW-20 for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:46:50 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Szjvk-0001eS-Uc for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:46:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Szk3i-0004Ux-G9 for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 03:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Aug 2012 07:55:02 +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.134458527917259 (code B ref 11822); Fri, 10 Aug 2012 07:55:02 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 10 Aug 2012 07:54:39 +0000 Original-Received: from localhost ([127.0.0.1]:45910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szk3L-0004UJ-Fu for submit@debbugs.gnu.org; Fri, 10 Aug 2012 03:54:39 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:49829) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szk3I-0004U9-U3 for 11822@debbugs.gnu.org; Fri, 10 Aug 2012 03:54:38 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M8J0060044J0500@a-mtaout23.012.net.il> for 11822@debbugs.gnu.org; Fri, 10 Aug 2012 10:46:18 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8J005NE495VI50@a-mtaout23.012.net.il>; Fri, 10 Aug 2012 10:46:18 +0300 (IDT) In-reply-to: <2AB38709-2307-437E-A242-70B8A358BE4F@permabit.com> X-012-Sender: halo1@inter.net.il 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:62991 Archived-At: > From: Ken Raeburn > Date: Fri, 10 Aug 2012 03:27:04 -0400 > Cc: 11822@debbugs.gnu.org >=20 > 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 fra= me, > > which are: the frame's selected window, the menu bar, and the too= l bar > > (the last two are displayed in a special kinds of window). For > > example, the backtrace above comes from displaying the menu bar. >=20 > Ah, that's interesting. It's especially interesting considering I = have menu bar and tool bar displays turned off. Not really relevant at this point, since the traceback shows Emacs wa= s displaying the frame title. The code in prepare_menu_bars is computing the menu-bar items, it doe= s not display them. > 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? It caches them when it can, AFAIK. But I'm not the expert on that part. > According to the code you quoted, it's a "face cache", and all I se= e 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? There are no colors in Emacs except as face attributes. If you need to colorize some parts of display, you need to realize a correspondin= g face. > Oh, hmm=85 the code you quoted ensures that the indicated frame has= a face cache, and conditionally calls recompute_basic_faces; that fu= nction checks that there is a face cache, and if so, calls clear_face= _cache and then realize_basic_faces. But clear_face_cache clears cac= hes of all frames. So if I understand correctly, if that function yo= u quoted (init_iterator) is given a frame with no cache (which I assu= me is the state a new frame is in?), or if the cache "used" flag is c= lear, it'll wipe out all cached faces from all frames, so the higher-= level iteration over all the frames (or windows?) will have to rebuil= d the faces, even if they had indeed been cached. Is that correct? I think so, yes. > Is there a reason recompute_basic_faces can't just clear the cache = for its own frame and leave the others alone? Are you saying that the used flag of the frame's cache is not a sufficient condition for clearing the face caches?