From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "T.V Raman" Newsgroups: gmane.emacs.devel Subject: Re: We should decouple focus and frame switching Date: Sun, 10 Jun 2018 18:07:44 -0700 Message-ID: References: <6d1bc582-29be-5df7-56b1-e82305ee477f@dancol.org> <726a268360567d598996f0080b71c0f8.squirrel@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1528679195 17726 195.159.176.226 (11 Jun 2018 01:06:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 11 Jun 2018 01:06:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Emacs developers To: dancol@dancol.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 11 03:06:31 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fSBHz-0004UW-CC for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2018 03:06:31 +0200 Original-Received: from localhost ([::1]:45644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSBK4-0002HJ-LI for ged-emacs-devel@m.gmane.org; Sun, 10 Jun 2018 21:08:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fSBJR-0002HC-Vv for emacs-devel@gnu.org; Sun, 10 Jun 2018 21:08:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fSBJL-0005RS-IL for emacs-devel@gnu.org; Sun, 10 Jun 2018 21:08:01 -0400 Original-Received: from mail-pl0-x22d.google.com ([2607:f8b0:400e:c01::22d]:46844) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fSBJL-0005RJ-B3 for emacs-devel@gnu.org; Sun, 10 Jun 2018 21:07:55 -0400 Original-Received: by mail-pl0-x22d.google.com with SMTP id 30-v6so11326336pld.13 for ; Sun, 10 Jun 2018 18:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=OuXgkpDCVD7n8JPvSTmlwEo2dTbxwmo5FnbOUVtF0k0=; b=gECkZNHxc4dxocjzU2dvoy/O1nYCBYmGOnYXzW1BE1SeEBOn9o6zt9NCNzOkpXn4Er Boi3a6HxWG/RnvrnbfysGgzcRn7KvyVmkjuBfvIL6XQZ7+6kSlCnJCVAKeW1x65kw32e KLjmd3KT15OQdjbclxfEMp9tAQrCos6xXHzVPYinq8n+emwF2vUd9c4rTT5QoOdt1hPP 5i/geVswURibTysnmC1CLvWB5LiFQNg7dALx1Jtvrvw33EPzJQyDSmAWfEfxU/ZvWqgX y/bmWrVIAUS+agpBrNpnbBcDieFxUFmGYkOB9vT+pqJJoihmc/KL65IB/7fqvMXz5tpr Aypg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=OuXgkpDCVD7n8JPvSTmlwEo2dTbxwmo5FnbOUVtF0k0=; b=RKptxfkKroD7ViNs38bpAD4u1FR4tsZptfaxV0NWfOMne2xtOoxLNKEXx6SiT6CQYA VSUFL4esLyJE/2p4PVfbM2z3fpr7laBt25mkrzmbU00s39JZTfpuW14GSNn4Zghfu8mL WpdWx1SPdxutZVpri4BoY9Q4ED+XFKLqL/8jODq8Ad9ZQW3G5n9ZAVKsjkwB6cjjB+ez dgdA2H2fdw6Oaa/Z87av3FGUvzFud078MVxP/V6pM0jd2i15kmKkaQg202x+wMpSBnVE cBR5C2R4qH0J1P+fuWAwC/6m1dSDbe/LxrIyC/07JE/wBYBL+noyihueCR9986x/xPDX yuJQ== X-Gm-Message-State: APt69E18mLNgasgHW6RGNbtpBceZvZ8qh4UZfX+LXH6YlEwZ6IlAm50b SDdlw/NaTDA+997SjWqAa2P9jYTOdjQ= X-Google-Smtp-Source: ADUXVKLWLtxElC+VnaUCAmCerWJj8PKL8uF3LfOeBzeb9i0XgPqQ1C/kI1ZU8GegmuedhiRZzQ/3xA== X-Received: by 2002:a17:902:c6b:: with SMTP id 98-v6mr16035964pls.37.1528679271053; Sun, 10 Jun 2018 18:07:51 -0700 (PDT) Original-Received: from raman-glaptop (c-24-4-174-65.hsd1.ca.comcast.net. [24.4.174.65]) by smtp.gmail.com with ESMTPSA id r8-v6sm112686052pfk.179.2018.06.10.18.07.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 10 Jun 2018 18:07:46 -0700 (PDT) In-Reply-To: (dancol@dancol.org's message of "Sun, 10 Jun 2018 17:20:34 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c01::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226177 Archived-At: dancol@dancol.org writes: Deprecating focus-in-hook/focus-out-hook is fine by me, I was merely pointing out that not only are they not used, any usage is hopelessly broken anyway.>> dancol@dancol.org writes: >> >> focus-in-hook and focus-out-hook are demonstrably broken --- I remember >> sending a message here that showed those hooks firing multiple times >> under stumpwm for a single window-switch event. I believe someone else >> also reproed the buggy behavior under a different WM > > Yeah. That said, I'm not sure that asking for strictly ordered > exactly-once delivery is reasonable where we have a bunch of asynchronous > window systems and now focus events also being delivered to TTY terminals > via escape codes. Suppose you're switching from a TTY gui frame to a GUI > frame: you might see the focus-in on the GUI frame before the focus-out on > the TTY, and there's nothing we can do about it. Or it could happen the > other way around, unpredictably. > > I don't even think we should have separate focus-in and focus-out hooks. > We should just have one extension point, some kind focus-change-function. > Modes would add-function a handler to focus-change-function, and each time > the handler is called, it'd re-scan all the frames and windows it's > interested in and do whatever it wants to do based on that snapshot of the > current focus state. That's why it's important to provide some kind of API > that lets a package ask Emacs, "To the best of your current knowledge, > does FRAME have input focus?" and not just rely on state change > notifications. > > Now, we already have focus-in-hook and focus-out-hook. Do we just apply > the new semantics to these hooks? Having two separate hooks encourages > people to use the fragile edge-triggered model instead of the > level-triggered one I described above. > > Maybe the right approach is to just declare focus-in-hook and > focus-out-hook obsolete and not call them anymore at all, then direct > people to this new focus-change-function extension point that has the > improved semantics I described. I normally don't like that sort of change, > but the existing hooks are hopelessly broken. > --