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: Sat, 12 Sep 2015 10:30:57 +0300 Message-ID: <83pp1o2ixa.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> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1442043143 7920 80.91.229.3 (12 Sep 2015 07:32:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2015 07:32:23 +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 09:32:12 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 1ZafIB-00009C-4z for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Sep 2015 09:32:11 +0200 Original-Received: from localhost ([::1]:59795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZafIA-0007n4-7N for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Sep 2015 03:32:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZafI6-0007mK-Mq for bug-gnu-emacs@gnu.org; Sat, 12 Sep 2015 03:32:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZafI3-00086f-Co for bug-gnu-emacs@gnu.org; Sat, 12 Sep 2015 03:32:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZafI3-00086b-95 for bug-gnu-emacs@gnu.org; Sat, 12 Sep 2015 03:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZafI2-0001sR-QR for bug-gnu-emacs@gnu.org; Sat, 12 Sep 2015 03:32:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Sep 2015 07:32: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.14420430757143 (code B ref 11822); Sat, 12 Sep 2015 07:32:02 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 12 Sep 2015 07:31:15 +0000 Original-Received: from localhost ([127.0.0.1]:57594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZafHF-0001r7-CZ for submit@debbugs.gnu.org; Sat, 12 Sep 2015 03:31:14 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:35674) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZafH7-0001qt-FV for 11822@debbugs.gnu.org; Sat, 12 Sep 2015 03:31:07 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NUJ00500YQINP00@mtaout28.012.net.il> for 11822@debbugs.gnu.org; Sat, 12 Sep 2015 10:30:49 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUJ00PMTZJC6T70@mtaout28.012.net.il>; Sat, 12 Sep 2015 10:30:49 +0300 (IDT) In-reply-to: <6esi6kpn4t.fsf@just-testing.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:106443 Archived-At: > From: Ken Raeburn > Cc: 11822@debbugs.gnu.org > Date: Fri, 11 Sep 2015 19:11:30 -0400 > > > [redisplay-dont-pause] should avoid redisplaying other frames > > when input is available after redisplaying the first one. Your > > original complaint was (and still is, as far as I'm concerned) > > that Emacs was unnecessarily trying to redisplay frames on another > > display, which caused undue network round-trips for communicating > > with X. Setting that variable to nil should at most only redraw > > the selected frame when user input is available. If you perform > > this experiment when the frame(s) in need of network > > communications are on the inactive display, you should see whether > > the effect is tangible. If it isn't, trying to refrain from > > displaying frames on other displays, per one of your suggestions, > > will not be very effective, perhaps not at all, and we need to > > look for other ways to optimize this use case. > > Well... if by "redisplay" we include both the face realization and text > drawing, yes, that's my complaint, but no, I don't think the flag will > avoid *all* of the redisplay mechanism for frames after the first, only > the text-drawing part. If we get as far as redrawing text on any of the > frames, including the selected one, it looks to me like by that point > we've already updated faces on any frames for which we think we need to, > and that's the part that makes it slow. Please look at the code (as it was before what I describe was deleted): We have a loop over all frames. Each iteration through the loop, we first compute the glyph matrices for all the windows on that frame (by calling redisplay_windows), which includes recalculating all the faces when we think they changed. Then we call update_frame for that frame, which delivers the changes to the glass. If update_frame returns non-zero, _we_abort_the_loop_, i.e. we don't proceed doing anything for the remaining frames. And update_frame returns non-zero if it sees input available and redisplay-dont-pause is nil. Therefore, when input becomes available during displaying the first frame, at most that one frame should be redrawn, and then Emacs should abandon redisplay. It should continue abandoning it for as long as there's input to process. At some point, we removed the code that broke out of the frame displaying loop in that scenario, so now what happens is indeed what you describe. We even had a more elaborate code that aborted the loop based on measuring the time it took to redisplay the first frames; it was also deleted. We could reinstate all that, but given that we deleted it several releases ago, this begs the question how far are we prepared to go for catering to such rare use cases? > So I'd expect it to possibly "save" an unnoticeable amount of time > during which it previously would've sent off text updates to other > frames without waiting for any X server replies. Do you still think so, after what I explained above? > (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.) Something else to optimize, I guess. > > Then these calls cannot be avoided with the current design of face > > realization. IOW, creating a single frame where communications with X > > are over a slow network will always be slow, unless we radically > > change the design and implementation of faces. > > We can reduce the number of round trips. If we only ever use 13 distinct > named colors, in an ideal world we could make do with 13 round trips to > allocate them in the colormap. But then we need an additional level of > reference counting or garbage collection on the client (Emacs) side. I said "unless we radically change the design and implementation of faces". We must work on our communications skills, because otherwise I cannot see how what you say contradicts what I said. > Start with reducing unnecessary frame updates and face cache > invalidations (reducing the number of face realization calls), and > redundant color lookups (which could make realizing any single face > anew faster), and only if that's not enough should we consider more > complicated stuff like the above. I will leave the color look up stuff out of the initial attempt to optimize this use case, primarily because I think it's a separate step, which logically belongs to changing how faces are realized, and also because I'd like to see how much of the problem is removed by that initial attempt. > >> The color lookups are currently done for each face independently. If > >> multiple faces use the same colors, we'll have multiple requests to the > >> X server for those colors. > > > > That should be part of redesigning how faces are realized. But you > > rejected the idea, so how do you expect this to happen? > > Let the generic face code continue to process each face independently. > It doesn't need to know that the X11 layer is providing the information > out of a cache in "struct x_display_info". Such a cache might also help > with lookups from image-processing code too. Patches to the relevant parts of the X display back-end to do this are welcome. Thanks.