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: Tue, 08 Sep 2015 15:54:49 -0400 Message-ID: <6ea8swr8ja.fsf@just-testing.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> <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> <83bndc7r5b.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441742140 3565 80.91.229.3 (8 Sep 2015 19:55:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 19:55:40 +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 Tue Sep 08 21:55:27 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 1ZZOz5-0002eU-S0 for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 21:55:16 +0200 Original-Received: from localhost ([::1]:37005 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZOz5-0005iF-Ik for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Sep 2015 15:55:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZOyw-0005fN-IZ for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 15:55:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZOys-0001AK-6x for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 15:55:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZOys-00019h-3X for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 15:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZOyr-0000M0-PE for bug-gnu-emacs@gnu.org; Tue, 08 Sep 2015 15:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Sep 2015 19:55: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.14417420961343 (code B ref 11822); Tue, 08 Sep 2015 19:55:01 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 8 Sep 2015 19:54:56 +0000 Original-Received: from localhost ([127.0.0.1]:52989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOyl-0000La-Hs for submit@debbugs.gnu.org; Tue, 08 Sep 2015 15:54:55 -0400 Original-Received: from mail-qg0-f51.google.com ([209.85.192.51]:35781) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZOyj-0000LS-1n for 11822@debbugs.gnu.org; Tue, 08 Sep 2015 15:54:53 -0400 Original-Received: by qgt47 with SMTP id 47so92417237qgt.2 for <11822@debbugs.gnu.org>; Tue, 08 Sep 2015 12:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=iCGIAboMmfh8T1CHtPhTvqBic1HI/g/0Bh3AEHz1QGI=; b=CUHNFeXLHKNzMW0DCQp6jgHfST1LaiQQlOOWOkNZ4p7VGRTbxRIzuUiIszX7ZLBA85 lRr4Cjf9hTSNTPyVHpkf5+iM0/gxPdGvkKC+jni4QCF8B0IkcullN5ZuR6+FwGle1zqX 00PPtRfyzgtKkIF60P7n9Mw3Fom2/a1MuLobU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=iCGIAboMmfh8T1CHtPhTvqBic1HI/g/0Bh3AEHz1QGI=; b=N3lSP4YAcNJh2hm5EYfOh+akoWDcAAyM6VpnBv5BlbMeHb9J8Ws3YG1GEAmJVssihG C2RfOKg8EAojphEg0yJTUZ2cNxa0k5Tna2thziR1f3etBsP5WmPJkvUVqC7NwXx6e7vu 7Av2L3sk1++17W67K5ajHjzThpUUKnesfNUkD/Qdx1pxlGf8Vog5RlntwpD5kwWY/1vd WWbmhPq3UCFpoWssOKSzLGY9awm6/ULIZthfmZo4sXtIRh1f4g7lPoDGx0eOdmUlVRqq 2Rc750Z59XeLy0kT76xtf2HhhcqpCowC1mzUvMBeKAw22EbEa/JDwxt1OPTevAeMfJgs E0XQ== X-Gm-Message-State: ALoCoQmw72tJf4rOjZkw9JHMeJOxQ0OgNVswltHYF4H3qsYO18DGACF4D6I33a12rNlNsqzK2d4f X-Received: by 10.140.96.200 with SMTP id k66mr10539537qge.81.1441742092419; Tue, 08 Sep 2015 12:54:52 -0700 (PDT) Original-Received: from just-testing.permabit.com (vpn.permabit.com. [66.202.84.2]) by smtp.gmail.com with ESMTPSA id k193sm2449016qhc.34.2015.09.08.12.54.50 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 12:54:50 -0700 (PDT) In-Reply-To: <83bndc7r5b.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Sep 2015 20:33:04 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (gnu/linux) 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:106272 Archived-At: Eli Zaretskii writes: > I'm still not following you: what do input events have to do with the > need to redisplay or not redisplay some frame(s)? If we don't need to update a frame, that's great. But I'm also thinking about cases where a frame does need updating but isn't on the currently-used display. Though for it to be important in this context, updating text probably don't matter much(?), just cases where we actually need to stop and wait for a reply, which probably means changes to face definitions like updating the foreground color. Would changing sizes for a face cause the face to be recomputed from scratch? That's something I sometimes do with buffers that I may well have visible on multiple displays. Giving updates to a remote display that's not the currently-active one lower priority than dealing with input on the active display could let us be more responsive on the active display, but at the risk of leaving the other display slightly out of date in occasional cases where it might matter (a second person working at the second display at the same time, both displays mapping to the same physical display via multiple ssh connections, etc). > Anyway, I think preventing frames from being unnecessarily redisplayed > will bring larger benefits than just avoiding realization of some > faces. Perhaps so. I think we've got inefficiencies at multiple levels: updating frames that don't need it; updating faces that don't need it (on frames where something does or may need updating); redundant color queries to a display; probably some issues around image handling. Fixing any of them would be an improvement, but addressing more than one is probably better still. Ken