From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#63511: [Patch] Fix for hidden window bug Date: Tue, 29 Aug 2023 09:22:44 +0800 Message-ID: <874jkiwskb.fsf@yahoo.com> References: <87il9570z1.fsf@yahoo.com> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3374"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Kangas , 63511@debbugs.gnu.org To: Christian Schmidt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 29 03:24:15 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qanSo-0000f0-O6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Aug 2023 03:24:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qanSX-0001vm-At; Mon, 28 Aug 2023 21:23:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qanSV-0001vP-Hh for bug-gnu-emacs@gnu.org; Mon, 28 Aug 2023 21:23:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qanSV-0007Bs-98 for bug-gnu-emacs@gnu.org; Mon, 28 Aug 2023 21:23:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qanSb-0004KX-L5 for bug-gnu-emacs@gnu.org; Mon, 28 Aug 2023 21:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Aug 2023 01:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63511 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 63511-submit@debbugs.gnu.org id=B63511.169327219316578 (code B ref 63511); Tue, 29 Aug 2023 01:24:01 +0000 Original-Received: (at 63511) by debbugs.gnu.org; 29 Aug 2023 01:23:13 +0000 Original-Received: from localhost ([127.0.0.1]:49199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qanRp-0004JJ-2A for submit@debbugs.gnu.org; Mon, 28 Aug 2023 21:23:13 -0400 Original-Received: from sonic302-20.consmr.mail.ne1.yahoo.com ([66.163.186.146]:34845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qanRl-0004Io-Bx for 63511@debbugs.gnu.org; Mon, 28 Aug 2023 21:23:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693272176; bh=gAEwVhpeZu8hBS/i1U0vHFu7TWFOKqRSsjw9id9fyJk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=o8ziLGP7ad/ky+F4A9tcI7N76mOmXp7K3qP58Is0u0qymVmCbiN2mRUdSqJQmYnEw9F8yI+446kEaKROix6YPNmy2GBekDXwtG1giOMvsUPDvMB4Z7ZtKpXnCXobdAbw5iBQdM/dE+QnimrWPLciuNPTtsQ6T/UryJqulDZeqdgGlY0jqlYHcqaR6xPGt3cX7HAgHlylNpJVnN+g9nmzQwHjNki94Sz5umqM0nrPnG1rq/1VnpsUhVlwFNZZy0hsBkuy13pDsHj66qFWXjtPCyaBhhKslQfRfGGaND4gsnoqfkMrfgU+KaYcq/xFybJ3KvnGKV+eAaxEy4SXYMEUAw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693272176; bh=Y0P1jjT6bNVJkofeSSXybAmrETRBidmf6//IDBjHpK9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=qJCk/UNCekgoC0HQUzZXV5YnF3rqyG4s6yWdeKAUlfOJhCoaP5mPYjWwru3s0ro45K5d4EDLA12z3o+gKVIMxn3x+nGxpJPHwAfKrMSQmteXwmK6P/wzH4Os2qLvMsaD7QrLQ/D0jRtRIvjzWvHhzlDg4oigxieEkIU1Uo6rItXPzy4YDJrzY4eNvzgb1ZwRsb8uotBt/sKj3uivgsPhyrWv2Xv2aICkLCsbMyaA2Ot7edDSKYV/PPiL6bJQ1JY+ECpm9kspFtZXIkQFnLPtCdcGQeTl+gcAhG0wNTubt/swZPHlCnJY6sa81rgsX9aRT9lFkri+Vold+EuyfH5oiQ== X-YMail-OSG: iwLhcKoVM1m_Eg7EdUxYVcJO9_LOKLr5zXehc15ZmNTggaDro8ORKiQKgmleEkZ _mShst17jJ8fSKPF76W9Y5SEyTd4Jcx1RruCiFj7xJ5tP5FHcbPkJ5HHzi9EHfbbSIywkbBRtBPS Kn_T1z6KV6GfU52KL3bEFrmUjZKESxlnfCaVcTdJ1frLuNLUIxrpJQt1jCY.ZlmBml9Lwtsi0.58 BU7.1jvlMwuRhDdO59Ln2sCsmB_zsR5IjfpSZMs.7rOQPuzGys8tduU8eFYqHR0dB7.pf3uGuhpJ gdlyG77yD5hNAOZmXtc4tNFfiodxZZD7DLPzng9LEy1xxku4.zav51Zkj9k7ezp3l4yDMaVly9Kf xdwc6_a5UtOGtR8.617ZQq0TzznPu9C.6zZ_5KRuNQm_Ds_kEwb9f_AGJzDkQUYEeI6wUr1DWrHj Wa3Ae_Q0SmcuTQBY2.wtaGXG_VRcUa6DFzMZVhN6dEdLmyrqCCHsMEx9ws8afghcYaCBdTlQpT0x scqLq.WAz.7BRPMwg4t8gHDzxu5vTohXTEOrry2FHgwwjijZ8FxiYoeYIOUr_m_5TCr3gXLrYHmc z9vk0euXlFEJS1npVwwQ5yIcc5RyxcDhFrRGE1miGTFJ5P3pDVKvAR.M96hABgfytqGsVrc.qjxM VSNcTcBQK3DPBAm2pLtVEmyljD2a1YyjeWoMD5x8BXnsPWhJ7DFOKAoB15dJd5jmvRyMMRdSCPGM m6R2fUjfdOtYCoC1n4xnacpAEGC6LFsEBjEUltexf7erW7ZH71iJRAXp2Sq3X41b9lRr2PWJ8vhc _5mTGp8nY_wZ6VFmtVly3CWO7mJpkXcyTl0kD8mFIU X-Sonic-MF: X-Sonic-ID: 20c4c072-0a73-4ea5-90f6-3bcf9f043be7 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Tue, 29 Aug 2023 01:22:56 +0000 Original-Received: by hermes--production-sg3-69654d8bd-752gm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 362ddb5f8071d0e65fc3d958e670f019; Tue, 29 Aug 2023 01:22:50 +0000 (UTC) In-Reply-To: (Christian Schmidt's message of "Mon, 28 Aug 2023 09:56:06 +0200") X-Mailer: WebService/1.1.21763 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268653 Archived-At: Christian Schmidt writes: > prop->type == (Atom) 0 IMHO refers to an empty list, which is valid. I'm sorry, but that contradicts the EWMH, which prescribes _NET_WM_STATE as an array of Atom. prop->type is only None (which is _not_ a type) when the property is deleted. > I would be surprised if this was a bug in E, given emacs is the only > program I know of that exhibits this issue. I have discussed this > issue extensively with raster, the main author of E, and we have come > to the same conclusion: when _NET_WM_STATE_HIDDEN the is the only > active/set property, and then is removed/unset (sorry if my _NET_WM_STATE_HIDDEN is not a property that may be ``set'' or ``unset'' (mind that this parlance is not X terminology), it's an element in a property named _NET_WM_STATE. Each window property is in fact an array of items whose width in bits is the format of the property. That property becomes empty when _NET_WM_STATE_HIDDEN is the only element of that array and is subsequently removed; when that transpires, GetWindowProperty still returns an empty array of the correct type, as the property is still set. The only two situations in which GetWindowProperty will return a type of None is when Enlightenment sets the property type to None or deletes the property in its entirety, both of which violate the EWMH. > terminology is wrong, my days of X programming have been 20+ years > ago, and these are corners I have never touched before), there is no > code path in emacs that can handle this case. Also, the request does > not hit the window manager, but it is X that replies. As such, the bug > would lie within X11. When a window property is changed to an empty value, its type remains intact. Enlightenment is not merely changing the property in this case, but also deleting it, which contravenes the EWMH. > What happens is that the array of atoms is empty, and thus the list is > (Atom) 0. Currently this is interpreted as "keep the current state", > and not to re-evaluate the (now empty) list of atoms to realize that > _NET_WM_STATE_HIDDEN is not set. An empty window property is empty -- its type remains intact, regardless of the number of items within. There's a distinct contrast between an empty window property and a window property that has abruptly vanished. > If that would be an issue, given there is no "unhidden" property that > could be set, how should the WM handle this? E sets > _NET_WM_STATE_HIDDEN when the window is hidden, and removes it when no > longer hidden. The window manager should empty the property instead of deleting it, which is more or less proscribed by convention. The removal of a WM property from a client toplevel window should always coincide with a corresponding change to _NET_SUPPORTED on the root window.