From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: dancol@dancol.org Newsgroups: gmane.emacs.devel Subject: Re: We should decouple focus and frame switching Date: Sun, 10 Jun 2018 16:28:15 -0700 Message-ID: <726a268360567d598996f0080b71c0f8.squirrel@dancol.org> References: <6d1bc582-29be-5df7-56b1-e82305ee477f@dancol.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1528673214 8459 195.159.176.226 (10 Jun 2018 23:26:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Jun 2018 23:26:54 +0000 (UTC) User-Agent: SquirrelMail/1.4.23 [SVN] To: "Daniel Colascione" , "Emacs developers" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 11 01:26:50 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 1fS9jU-00025q-BE for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2018 01:26:48 +0200 Original-Received: from localhost ([::1]:45477 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fS9lb-0004D8-7Z for ged-emacs-devel@m.gmane.org; Sun, 10 Jun 2018 19:28:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fS9kw-0004Cn-GR for emacs-devel@gnu.org; Sun, 10 Jun 2018 19:28:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fS9kv-0003x2-HX for emacs-devel@gnu.org; Sun, 10 Jun 2018 19:28:18 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40036) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fS9kv-0003wV-7G for emacs-devel@gnu.org; Sun, 10 Jun 2018 19:28:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=LwjZEHPYlmS0ps+FVN64JpkyEi93t0gcAFHgUaRY0fw=; b=TKmQgyRH3Eh62LboGq4BCGMf8jR0ysE5DM3X9kYLF48YCZuRPpbCMjMx26fZOGJsrx8Xi4oO3g2fHuWa2kalu1gw3ur6/tE2UTjNICPxPEraf1Bn3CXtpVxxnQ07Q1N30LO4Ta36r0uImKW2YfpC1ghDxEuNGjjSbZjlbBM5AQ/Ffbv/9mccor8V0rIAHGNDYtBESMUSe2S/PbLcW28Ej5TxOq5nwtcOb76O3UMMi7ezbke8kNnHrswozwlAhoeu+Jh7Dc4DGVlIaKsPGlBcaLdzKNgeiW3j7dp8BduEsHBZt52DoXRmQ3TVumQhKp2LIUBRhX0+oexiRIFsq2KzHA==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fS9kt-0002VQ-A9; Sun, 10 Jun 2018 16:28:15 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Sun, 10 Jun 2018 16:28:15 -0700 In-Reply-To: X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:226173 Archived-At: >>>>>> "DC" == Daniel Colascione writes: > > DC> How about this? We'll add a frame-focused-p function that returns nil, > t, > DC> or 'unknown, and wire up focus-in-hook and focus-out-hook to run only > when > DC> we actually observe a window system focus change, letting the frame > switch > DC> stuff run completely independently. This way, we'll be able to write > lisp > DC> (as I've been trying to do) that reflects the real window system > focus. > > DC> Sound good? > > Why might we not want this? First of all, I'm worried about backward compatibility with existing packages that rely on the current strange behavior of focus-in and focus-out. I briefly scanned the tree, ELPA, and EmacsWiki, and I didn't see anything that would obviously break, but that's no guarantee. The alternative I was considering is to keep the existing focus events as they are and add a new set of window-system-focus query functions and hooks alongside it. Second, Chesterton's fence: maybe there's a good reason the focus events are structured the way they are? I was hoping somebody knew why we did it this way in the first place.