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#21473: 24.5; very slow tooltip display to sort-of-slow remote display Date: Wed, 7 Oct 2015 02:09:47 -0400 Message-ID: <9E18042B-99C0-4DAC-AEFA-257A5BF59513@permabit.com> References: <9F31D581-6B5A-42B7-8031-6920089AFFF4@permabit.com> <83pp15hdbg.fsf@gnu.org> <59C0A752-87BB-4467-9A3F-DC1E5A278842@permabit.com> <83612wf8pr.fsf@gnu.org> <83si5wbcap.fsf@gnu.org> <6ebnci3o1s.fsf@just-testing.permabit.com> <83oagf0xx5.fsf@gnu.org> <5AFBFA9B-153C-4CFB-8864-BAB733413B11@permabit.com> <83a8ry1kyt.fsf@gnu.org> <9CBD7FEC-C4BC-4FD8-8FE1-9760C2113DAC@permabit.com> <831td925nh.fsf@gnu.org> <08005C15-1EEE-46DE-B608-BDAE091E7F4F@permabit.com> <83mvvwyavf.fsf@gnu.org> <83io6kxdf9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1444198283 23287 80.91.229.3 (7 Oct 2015 06:11:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 06:11:23 +0000 (UTC) Cc: 21473@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 07 08:11: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 1ZjhwV-0006ZT-J2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Oct 2015 08:11:11 +0200 Original-Received: from localhost ([::1]:55402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjhwU-0001J1-Qz for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Oct 2015 02:11:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjhwR-0001Ir-2v for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2015 02:11:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjhwM-0005Y6-VO for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2015 02:11:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjhwM-0005Y2-S0 for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2015 02:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZjhwM-00017x-AN for bug-gnu-emacs@gnu.org; Wed, 07 Oct 2015 02:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Oct 2015 06:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21473 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21473-submit@debbugs.gnu.org id=B21473.14441982134276 (code B ref 21473); Wed, 07 Oct 2015 06:11:02 +0000 Original-Received: (at 21473) by debbugs.gnu.org; 7 Oct 2015 06:10:13 +0000 Original-Received: from localhost ([127.0.0.1]:57655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZjhvY-00016u-ED for submit@debbugs.gnu.org; Wed, 07 Oct 2015 02:10:12 -0400 Original-Received: from mail-qg0-f53.google.com ([209.85.192.53]:33779) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZjhvD-000167-LX for 21473@debbugs.gnu.org; Wed, 07 Oct 2015 02:10:10 -0400 Original-Received: by qgev79 with SMTP id v79so7514743qge.0 for <21473@debbugs.gnu.org>; Tue, 06 Oct 2015 23:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WB5sVW5vkhHK/dC4YG1KnodyBUXTZrVVLkxGLNCyKG0=; b=WfOCcTYS9Pqb17YCsALxY9YURyNOSbFFGc0XT9rMeC02vJ1SX9RVLFDg9n2KHELcQ/ 7uTGCj9jkEbWZCrDy0ktMC1fwgkY6gfiisz5skiDeNRn9qZvyM0BG0U0oq9f5jZYoeqK xI1JpfJzlX+KRRUSrw0+tRzWyt0ul1cKUgsFk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WB5sVW5vkhHK/dC4YG1KnodyBUXTZrVVLkxGLNCyKG0=; b=W71xLtN5/6TXF395YPO1duuASoFlh9t8S1OtSSgLrUeAm6bmincecjuQ5YoVNQROuz tTDTV2tfzCBQXtKmcwCskfoR5/wk1oP70bfksUCsFuz5NB0VoWsRpE9lxNfg7nwP0vbC /dleGMKbusJYxpXqE9M+Zebr40FKi+H5vpCZlyfkalLGLocpE2E3XrVEGnikQxX37YUx ls5MqkT5r8r5myO1t4Gl52caSZrLnbqJAaJbj6X0NAnhfMV4bJdbqSasSGn7CmfJzvFl MK2fmXivjeZJd/SL4OSpw2oEJgiRmD08oZiqThmZPfz97yf1dd7x1DW8EaV/gSem9pQJ illw== X-Gm-Message-State: ALoCoQkL7yBWPnQaQ//3/Q4bvxLNfmK7h0VHQyLk0LhuYuyK8MjBNft7HHmfdFxCIWCrVPesYFr9 X-Received: by 10.140.147.146 with SMTP id 140mr44983384qht.68.1444198191174; Tue, 06 Oct 2015 23:09:51 -0700 (PDT) Original-Received: from [192.168.17.111] (c-66-31-203-101.hsd1.ma.comcast.net. [66.31.203.101]) by smtp.gmail.com with ESMTPSA id t37sm15645897qge.26.2015.10.06.23.09.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Oct 2015 23:09:49 -0700 (PDT) In-Reply-To: <83io6kxdf9.fsf@gnu.org> X-Mailer: Apple Mail (2.2104) 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:107397 Archived-At: > On Oct 6, 2015, at 10:46, Eli Zaretskii wrote: >=20 >> From: Ken Raeburn >> Date: Tue, 6 Oct 2015 05:30:42 -0400 >> Cc: 21473@debbugs.gnu.org >>=20 >> It looks like I was mistaken. It appears that it was using the arrow = only because that=E2=80=99s the default pointer shape for the X root = window. According to some of the X docs I was reading, if the = =E2=80=9Ccursor=E2=80=9D (pointer shape) is never defined for a window, = then the window uses the value from the parent window. >>=20 >> If I change the root window=E2=80=99s default pointer shape, then = when the mouse is in the tooltip window it also uses that shape. I doubt = that=E2=80=99s what we want; one of the shapes used by Emacs would be = better, even if we only allow one to be used for that frame. Then again, = if the window is supposed to go away quickly, maybe we don=E2=80=99t = care at all? On a slow, remote link, there can be enough lag for the = pointer to be visible in the tooltip window for a good half second at = least. >>=20 >> The odd part: It appears that it=E2=80=99s already broken, even with = the call to x_set_mouse_color being applied to the tooltip frame. I=E2=80=99= m still getting whatever odd cursor shape I installed for the root = window. This is with the Xquartz server on OS X; I=E2=80=99ll try later = with the X.org server. It behaves the same on the x.org server. The default root-window mouse = cursor is a big =E2=80=9CX=E2=80=9D, and the same is true for the = tooltip window. >=20 > I suggest to make that call conditional on a user variable, by > default off. Most users, certainly on fast networks, will never see > that pointer anyway. >=20 > WDYT? They can see it if any CPU-intensive work keeps Emacs busy right after = the tooltip is displayed =E2=80=94 garbage collection, auto-revert of = large files, processing of data received from the net, etc. Then Emacs = may not be able to make the X window disappear right away when the user = moves the mouse. I wonder if it might be better to change x_set_mouse_color to check some = new field =E2=80=9Cf->tooltip_p=E2=80=9D that makes it define just one = cursor. (The arrow we use for non-text areas, or the vertical-bar xterm = cursor we use for text?) For users on fast networks, the extra traffic I=E2=80=99m worrying over = =E2=80=94 which I think would then be reduced to three XSync exchanges, = if we also do color-name caching and TrueColor optimizations =E2=80=94 = wouldn=E2=80=99t be a big deal. A tiny price for getting the display = right in a minor case, if we can, and I think I can reduce that count. I think that=E2=80=99s probably better than a new Lisp variable to = control low-level protocol details that should usually be invisible, to = deal with a problem that we could fix reasonably well in the C code. Of course, there=E2=80=99s also the little matter of making the = cursor-setting actually work. Until (unless?) that happens, we might as = well disable it for everyone. I can check that in if you'd like. Ken=