From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: About the 'minibuffer' frame parameter Date: Sat, 06 Aug 2016 11:33:55 +0200 Message-ID: <57A5AF03.30807@gmx.at> References: <579E3F9E.8020200@gmx.at> <83h9azl4s1.fsf@gnu.org> <57A4C0DE.3060506@gmx.at> <837fbvkofs.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1470476086 17349 195.159.176.226 (6 Aug 2016 09:34:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2016 09:34:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 11:34:42 2016 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 1bVy05-0003WO-Ey for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 11:34:37 +0200 Original-Received: from localhost ([::1]:48617 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVy02-0002CG-8u for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 05:34:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVxzV-0002Bz-Vq for emacs-devel@gnu.org; Sat, 06 Aug 2016 05:34:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bVxzU-00089p-RX for emacs-devel@gnu.org; Sat, 06 Aug 2016 05:34:01 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:57302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVxzU-00089B-Gr; Sat, 06 Aug 2016 05:34:00 -0400 Original-Received: from [192.168.1.100] ([212.95.7.63]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MU11l-1beWb0325x-00QiEZ; Sat, 06 Aug 2016 11:33:59 +0200 In-Reply-To: <837fbvkofs.fsf@gnu.org> X-Provags-ID: V03:K0:n++6WMfnYNE1QW+NFhiNUGsAMXC2mROSeHy2QVeVxVb0l4lhgK1 EA+TFqfvCz+sSGTGGmJkMyIpI3lNUVNrLXttQiqGw3Am5+Ni6yavNcVXmnd8GPzkAiR0Rxt MdZjVtQMO3Hvu2W0sqXh4kLhIkJ7IW3bWr76fGwOGdjK7x64ysJC+bSAo3HP3w+2kN/AnFk lctqyu7kP3s2bxuYID3lg== X-UI-Out-Filterresults: notjunk:1;V01:K0:e3Qp87nNu50=:wlWrrQ+9D/qyp8jgGUNQ1g WFybDb3qxrnG2IfOl5uJSrsGDFuAc4YzvJ1VQzS4i9lcMMUiPg1IJnueTvu90Wj0Myns4NOPM +ii4Q84eouve5cdfJp7r74glO8nJepKJ+++DLr9VMugqNXT++re2Tbd+Fw6NanYKTJuBWaBgT FAF3N2iA7OlD1IhZF/IcJdPNH0KUfdNO1BAx+WHFby/929oBIbjpRTRA0K0Y6RZw0GpfK8O7U oFi8eJmj5Ykc6sfJ4fnVHbqmMKbzHsmIG77gZhwswjbsfTnd+e5R8QeYlqwUwc784q6u6j8yW MCRyhIOiiYhAzUY0FNGosgW68zMvOXbrBMYvFhvGW0XM7LClAMAShij+LkhBkGPIztTGaChst TZdN0IQLIWbbk5umFcLS7sKFLSdbbKD58ObJN2RWzU/ASci0NQMTD/baZGg3TOg5hLPviVrHb w/7e5M/YIxIeyumdQnKVhBaegkN/NnRkF5aa8wVxrIBhLUyfdlz8U4Q8YijjIQM6vmtpujVQB Ga95tJ28rwoAkg91lM2wKxpc1M+KDNtJNBNCkP04kiIJwk/weVvck+SMl8yNJ1jb03NTQRvDR y43QZnkKEoLuOphRiSwdP92FP8BG1ZtPbymJiCOGBYGtuRiw01+uKLHAMUlUHhW7mWUyIO97o +HgLXIqvYD/QNFCRnI+p/Phov7R4Yf9VmUSzfe1qpBOaN72fzIGXnDxO98ZB7rWUnK9BMqpld gSy/WHLvW4Hym1+dZMZqxYHnwCIW8EmaOapobEZyWNr7ofDMAPQRRFf/+rZNgS2E/4OyIg5Q X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 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:206436 Archived-At: > We could simply change the above code to follow suit. Change what? Initially I only wanted to simplify code like (FRAME_HAS_MINIBUF_P (f) && !FRAME_MINIBUF_ONLY_P (f)) because once f has been created, FRAME_HAS_MINIBUF_P (f) and !FRAME_MINIBUF_ONLY_P (f) invariantly hold for the entire lifetime of f. A bit field telling whether a frame owns a minibuffer or is minibuffer-only/-less seems more practical instead of these macros. The value stored in that bit field would have to reflect the value stored in the 'minibuffer' frame parameter. But for a minibuffer-less frame we OT1H store the minibuffer window in that parameter and OTOH we report the value nil for that parameter in =E2=80=98frame-parameters=E2=80=99. We could either modify that code in store_frame_param if (EQ (prop, Qminibuffer) && WINDOWP (val)) { if (! MINI_WINDOW_P (XWINDOW (val))) error ("Surrogate minibuffer windows must be minibuffer windows"); if ((FRAME_HAS_MINIBUF_P (f) || FRAME_MINIBUF_ONLY_P (f)) && !EQ (val, f->minibuffer_window)) error ("Can't change the surrogate minibuffer of a frame with its own mi= nibuffer"); /* Install the chosen minibuffer window, with proper buffer. */ fset_minibuffer_window (f, val); } to store Qnil instead of the minibuffer window or do away with the special treatment of the 'minibuffer' parameter in =E2=80=98frame-paramet= ers=E2=80=99 as I mentioned earlier. The former should be sane because so far C-code always goes for the value of FRAME_MINIBUF_WINDOW to find the minibuffer window of a frame. However, we'd still have to explain that =E2=80=98set-frame-parameter=E2=80= =99 can change a frame's minibuffer window without reflecting the change in the return value of =E2=80=98frame-parameters=E2=80=99. As mentioned before, removing the special treatment of the 'minibuffer' parameter in =E2=80=98frame-parameters=E2=80=99 would imply that Elisp co= de relying on the values we report currently might be broken in the future. The doc change required for this solution would be marginal. Things would be much clearer if we had provided some orthogonality of =E2=80=98minibuffer-window=E2=80=99 and =E2=80=98set-minibuffer-window=E2= =80=99. martin