From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Fri, 11 Sep 2015 20:51:46 -0400 Message-ID: References: <6eipe9fypj.fsf@just-testing.permabit.com> <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> <6ea8swr8ja.fsf@just-testing.permabit.com> <83si6n65ld.fsf@gnu.org> <6e613irc91.fsf@just-testing.permabit.com> <83bnda5lso.fsf@gnu.org> <6ezj0tphtd.fsf@just-testing.permabit.com> <83h9n14e04.fsf@gnu.org> <6esi6kpn4t.fsf@just-testing.permabit.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442019141 12270 80.91.229.3 (12 Sep 2015 00:52:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2015 00:52:21 +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 Sat Sep 12 02:52:10 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 1ZaZ34-0001Vs-3E for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Sep 2015 02:52:10 +0200 Original-Received: from localhost ([::1]:59088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaZ33-0007Bh-A8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Sep 2015 20:52:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaZ2z-0007Af-Qj for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 20:52:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaZ2w-0005FW-Ja for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 20:52:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaZ2w-0005FD-Ft for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 20:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZaZ2w-00012l-2K for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 20:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Sep 2015 00:52: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.14420191113994 (code B ref 11822); Sat, 12 Sep 2015 00:52:02 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 12 Sep 2015 00:51:51 +0000 Original-Received: from localhost ([127.0.0.1]:57502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaZ2k-00012L-DQ for submit@debbugs.gnu.org; Fri, 11 Sep 2015 20:51:50 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:41687) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaZ2i-00012D-Dw for 11822@debbugs.gnu.org; Fri, 11 Sep 2015 20:51:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxFgA731xV/zi6xEVcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBBgEBAQEeizqELA5LB4QtBYZmmDGSFIIUgUUjgWZVgVkigTSBRAEBAQ X-IPAS-Result: A0AxFgA731xV/zi6xEVcgxCEAoVVu0CHSwQCAoE8OxIBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBBgEBAQEeizqELA5LB4QtBYZmmDGSFIIUgUUjgWZVgVkigTSBRAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="164607448" Original-Received: from 69-196-186-56.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.196.186.56]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2015 20:51:47 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 516CEAE12C; Fri, 11 Sep 2015 20:51:46 -0400 (EDT) In-Reply-To: <6esi6kpn4t.fsf@just-testing.permabit.com> (Ken Raeburn's message of "Fri, 11 Sep 2015 19:11:30 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (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:106437 Archived-At: > (Also: Iconifying the remote frame doesn't seem to help. In > prepare_menu_bars, when all_windows is set but some_windows is not, the > call to x_consider_frame_title, which can trigger face realization, *is* > called for iconified frames.) Maybe instead of doing prepare_menu_bars: (forall frames (compute-title-and-stuff)) later: (forall frames (recompute-glyph-matrices-and-then-display)) we should do (forall frames (compute-title-and-stuff) (recompute-glyph-matrices-and-then-display)) > * Some requests do require replies from the server, like color lookup > (return RGB data from server-side database) or color cell allocation > (return pixel ID), and the library is not generally designed to allow > for pipelining of these requests; it'll wait for the reply before > returning control to the application. BTW, IIUC while Xlib is not designed for that, the newer Xcb library exposes the underlying wire protocol more directly, making it possible to send several color requests before waiting for the replies. > * Some types of displays are limited in the number of colors they can > show, so being a good X neighbor involves freeing colors (the correct > number of times) if you're done with them and not about to shut down > the connection, unless you're using a private colormap, in which case > the only foot you might shoot is your own. I'm not sure if these > display types are at all common any more. FWIW, I've used 8bit-deep framebuffers not that long ago. But they're probably rare by now, indeed. > For a local X server, the round trip time is cheap enough that it's > probably good enough to generate all the extra traffic and accept the > (very brief) waits for replies, and just let the X server deal with > maintaining the reference counts on color cells. As mentioned earlier, I think this is not true if we repeat it per-frame since we can have 100 frames, at which point the delay can become significant even locally. Stefan