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: Tue, 08 Sep 2015 20:33:04 +0300 Message-ID: <83bndc7r5b.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> <83a9y3dwa8.fsf@gnu.org> <838vdndv9m.fsf@gnu.org> <1341183F-84AB-4257-B28B-57BDE5CA4F20@permabit.com> <83r3m97bzs.fsf@gnu.org> <37C523EE-3D76-40F7-B7B2-99D6F0BD7B97@permabit.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1441733613 22572 80.91.229.3 (8 Sep 2015 17:33:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 17:33:33 +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 Tue Sep 08 19:33:14 2015 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 1ZZMld-0004LJ-Ag for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 19:33:13 +0200 Original-Received: from localhost ([::1]:36099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZMlc-0004j9-B1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 13:33:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZMlW-0004iw-OR for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 13:33:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZMlS-00032W-D7 for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 13:33:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZMlS-00032N-Ar for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 13:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZMlS-0005NO-0R for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 13:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 17:33: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.144173357520654 (code B ref 11822); Tue, 08 Sep 2015 17:33:01 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 8 Sep 2015 17:32:55 +0000 Original-Received: from localhost ([127.0.0.1]:52878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZMlK-0005N3-SN for submit@debbugs.gnu.org; Tue, 08 Sep 2015 13:32:55 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:45797) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZMlI-0005Mt-Fj for 11822@debbugs.gnu.org; Tue, 08 Sep 2015 13:32:53 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NUD00700CE9M300@mtaout28.012.net.il> for 11822@debbugs.gnu.org; Tue, 08 Sep 2015 20:32:38 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUD00OU1CQE7C80@mtaout28.012.net.il>; Tue, 08 Sep 2015 20:32:38 +0300 (IDT) In-reply-to: <37C523EE-3D76-40F7-B7B2-99D6F0BD7B97@permabit.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.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:106257 Archived-At: > From: Ken Raeburn > Date: Tue, 8 Sep 2015 06:15:47 -0400 > Cc: 11822@debbugs.gnu.org > > > The face cache of a new frame should start out empty, so clearing it > > is a no-op. But maybe you mean something else, I didn't yet have a > > good look at the backtraces. > > Since there’s nothing to clear out on that frame, there should be no need to make the call. But we make it, and the call we make forces the clearing of all caches, not just the one for that frame. Therefore, we should prevent the effect of that on other frames. I see no need for this effect, since faces are frame-local. > > The face cache is per-frame, so indeed, there should be no effect on > > other frames. If the backtraces indicate otherwise, I'd be surprised. > > Unfortunately Fclear_face_cache (and global variables like face_change_count or windows_or_buffers_changed) isn’t frame-specific. So — I expect but haven’t tested — changing screenGamma on an existing frame will probably also force faces to be recomputed on every frame. Then we should make them part of the frame structure, and only clear the face cache of a single frame at a time -- the frame on which a change to faces requires that. > >> 5) Even better, can we do the other-display updates in small increments, so that once we start doing those updates we don’t have a block of 160*RTT seconds where we’re unresponsive to new user input? > > > > Not sure I understand the idea; please elaborate about the increments > > you had in mind. > > In realize_basic_faces we call realize_named_face 14 times and realize_default_face once. For a display that’s not the one the user appears to be using (selected frame is elsewhere, no X events received), I’m wondering if we can have Emacs check for events (user input on any frame, subprocess output, etc), if there are none, realize one face, check for events again, etc., and when all of the faces are done, do any needed updates to the frame. Give priority to user interaction as much as possible, both in terms of handling input events and prioritizing updates to certain frames over others. Of course, if we get events associated with that other frame/display, or a call is made to force redisplay, we’d want to get things updated right away. I'm still not following you: what do input events have to do with the need to redisplay or not redisplay some frame(s)? > That’s probably a lot of work. :-) But maybe there are some smaller changes that could be made. Do we have to realize all 15 right away? The way the code is written, it expects the basic faces to be realized, yes. > If it’s not the selected frame, perhaps it doesn’t need the (active) mode line face As you see from your backtraces, Emacs changes the selected frame many times behind your back, so this is not true. Anyway, I think preventing frames from being unnecessarily redisplayed will bring larger benefits than just avoiding realization of some faces. > and if there are no tool bar or scroll bars, it doesn’t need those faces either. Maybe they could be processed later as (or if) needed? We would need flags to manage that. Once again, I don't think the basic faces are the main problem as long as they are rtealized only for the frame(s) that really need them to be recomputed.