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 07:48:07 +0300 Message-ID: <83r3m97bzs.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> 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 1441687706 24235 80.91.229.3 (8 Sep 2015 04:48:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 04:48:26 +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 06:48:11 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 1ZZApG-00024z-Lh for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 06:48:10 +0200 Original-Received: from localhost ([::1]:59967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZApG-0003NX-7U for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 00:48:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZApC-0003NP-In for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 00:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZAp8-0001Mw-Gq for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 00:48:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZAp8-0001Mj-DK for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 00:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZAp8-0001lG-8I for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 00:48: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 04:48: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.14416876806761 (code B ref 11822); Tue, 08 Sep 2015 04:48:02 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 8 Sep 2015 04:48:00 +0000 Original-Received: from localhost ([127.0.0.1]:52000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZAp5-0001ky-RF for submit@debbugs.gnu.org; Tue, 08 Sep 2015 00:48:00 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:43326) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZAp3-0001kp-2o for 11822@debbugs.gnu.org; Tue, 08 Sep 2015 00:47:58 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NUC00P00DFF1V00@mtaout26.012.net.il> for 11822@debbugs.gnu.org; Tue, 08 Sep 2015 07:50:13 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUC00MYVDFPVE20@mtaout26.012.net.il>; Tue, 08 Sep 2015 07:50:13 +0300 (IDT) In-reply-to: <1341183F-84AB-4257-B28B-57BDE5CA4F20@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:106230 Archived-At: > From: Ken Raeburn > Date: Mon, 7 Sep 2015 17:09:23 -0400 > > After dropping the ball on this about three years ago, I’ve started digging into it again with version 24.5. Thanks for the footwork and the data. I will study it and see what I can come up with. For now, just a couple of quick comments: > 1) For a new frame, I doubt any cache clearing is needed when setting screenGamma or other frame parameters; if there’s anything cached before we’ve finished computing the parameters, we may have computed the cached thing too early. 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. > 2) When changing screenGamma or another frame parameter does require clearing some cached values that were based on the old parameter settings, it still shouldn’t affect other frames. 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. > 3) When frames on the same display have the same relevant frame parameters, as I expect is by far the most common case, can we share info between them, so these lookups and delays will be per-display instead of per-frame? Faces are per frame, so it's hard to share them without a lot of management code (which would be needed to maintain the illusion of frame-specific face definitions). > 4) If something else (changing a face attribute?) requires potentially updating all frames, maybe we can immediately do just the current frame, or the visible frames on the current display (and maybe tty frames?), and delay updates to other frames/displays briefly — say until an idle timer expires or the frame receives input, whichever happens first — so that we can give priority to user interaction on the selected frame/display? We should have optimizations in the redisplay code that don't redisplay all frames just because faces on one particular frame need to be recomputed. There's a tricky part about this: the display engine is prepared to be called for a frame or window that only potentially need redisplay. For starters, it should be clear that deciding which frames need redisplay involves iterating through all the frames, checking for some telltale signs. It just could be (I didn't yet look at your data) that some of this iteration somehow calls init_iterator, for the purposes of testing whether a frame needs redisplay. IOW, I think redisplay optimizations don't assume that just recomputing the basic faces could be a bottleneck, so it's possible that we don't try too hard to avoid 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. Thanks.