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: Sun, 07 Aug 2016 10:46:44 +0200 Message-ID: <57A6F574.7090101@gmx.at> References: <579E3F9E.8020200@gmx.at> <83h9azl4s1.fsf@gnu.org> <57A4C0DE.3060506@gmx.at> <9605148d-fa81-4cbc-ae81-9e1e8bd11362@default> <57A4CE4C.5010901@gmx.at> <57A4D8C3.5030205@gmx.at> <3e5c74c4-40ae-4b6e-8e8e-444306abb189@default> <57A5AEBD.9040805@gmx.at> <4522903e-6891-46f7-9838-fca2e481ac89@default> 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 1470559642 25003 195.159.176.226 (7 Aug 2016 08:47:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2016 08:47:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 07 10:47:18 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 1bWJjl-00059U-Gx for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 10:47:13 +0200 Original-Received: from localhost ([::1]:51877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWJji-0005gm-Bl for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 04:47:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWJjc-0005gh-Bl for emacs-devel@gnu.org; Sun, 07 Aug 2016 04:47:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWJjY-0004Bl-67 for emacs-devel@gnu.org; Sun, 07 Aug 2016 04:47:03 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:50834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWJjX-0004Bd-RR; Sun, 07 Aug 2016 04:47:00 -0400 Original-Received: from [192.168.1.100] ([212.95.7.67]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M3NEK-1bEVpb1z7Y-00qzLV; Sun, 07 Aug 2016 10:46:51 +0200 In-Reply-To: <4522903e-6891-46f7-9838-fca2e481ac89@default> X-Provags-ID: V03:K0:/ldagzeUGwp1cncsbaTFhf8rgCRnA49I/+JlJ1o4F4jvtlU9nI2 Lf8T3oAXH//racYxHO83aE7puqcB0aomMc70dZNvsmtDEWn2VTAZ/FUoWclMppfF4gM9EeO QZX6M955VXKzYIgMOxrZYPTIkC7fWQfW1KcZEYmR1B6wGh46TQtAHkQCimLyuTPPcTLMEZL QhDLaTWASWWtPNbXpLU2Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:cB5TEM9mFBE=:epsKrfUG/kRpzunaIAX5+L CsFUAe+SKaZVtv2mzpJfoJUmlSRwNrou/Ur94AU8EOOs4vmRWmxsn1L39R8Upqa5hSpLFCOW0 /b3biRul8vy0Fs9rJ84WzJ1WxGv3n+U9e7p8WA/DzNEFMO0//rn8LP8TFmkvJXaYUykkMUZhg 1z4L/ceQ1sTKdwH9TGJ1O5S2EJ4sHAG14E0I9IKzmTzFtWJtnwBWiiq5vNc+SL9sJWg0Rpad/ FXdEzQrTbTl3iv71UsSCTrE5Z1FqyPdUK1l202QJ1v+/iw/+ISRI8rlzVLEdvFjMIJIw8fNTM /YOpJnFHyQ7v1s/oYepiK+VZh7GEeJO2UlThTc/ZOuqNj7XHskemtoghHFzxJ9vCzM2ZBUhaM ChKK3e2ZfMr5WAvxAET+TM0Vp8YvTM6mDLZw5ZXm0KeZt7TX9EcfpviQIKSxNPV8q3eDAamVH 61d+GiLPnhsZCBY2Us6/Amhag/7O4jKFpHr8+itLy1+oDP8SjolOdHaQvyqOcn3pLpSlW/H7c NskAj/N3dJ0yLfylgCYqtyQ7vkVsshEvGfVDYFl6yOp3c/O60E9SgiRZPVzCLCH0AogNG9aSR uGwk3n9wY7RvpVheLjz3NY9TLU+tojOmIJ3Pct1Sq2oE93vvFsglk9HMOgBCcKrtIdbSf5UA3 JjZAbkSaVg+2MgOjotyEhThnweizT0xVDGjoC0OrmLaaSypUHeDBmjA5qrDCSbFfhHbWPgaON 3AOUVRJHCXiQ/Gu1PWNilhkLagFye6jRFyVHZWicTa0dp/rRVujYoM3sbFIiWHhoLQ4bYw7H X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.22 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:206464 Archived-At: > Yes... Or maybe not. Doesn't that conclusion depend on > supposing that `set-frame-parameter' returns the new parameter > value? I don't see the return value of that function mentioned > in its doc string or in the manual. (Maybe it should be?) It's irrelevant - the return value is that of =E2=80=98modify-frame-param= eters=E2=80=99 and that's always nil. Here I only care about _where_ nil gets printed, that is, in which minibuffer window. > But anyway, if you're sure that the value of `frame-parameter' > is nil (I assume you checked this in the C code), then OK. (set-frame-parameter minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-= frame)) sets the internal value of the 'minibuffer' frame parameter to the specified minibuffer window. Only the value reported afterwards by =E2=80=98frame-parameter=E2=80=99 is nil. > Yes, it is misleading. But why is it not critical (a problem)? Because internally Emacs ignores the frame parameter's value and relies on the value returned by =E2=80=98minibuffer-window=E2=80=99 instead. Th= e corresponding macro is FRAME_MINIBUF_WINDOW. C code hardly ever consults frame parameter alists, probably for two reasons: (1) Their values are either inaccurate or don't exist, and (2) it might be too costly to do so. > And why does it happen also for geometry parameters? (And why > does it happen for `frame-parameter'?) Because the frame geometry changes for a number of reasons, for example, when you maximize a frame or use the mouse to resize it. In this case Emacs has to tediously approximate the values of the 'height' or 'width' parameters from the real ones, the ones the user sees on the screen. The values of many parameters reported by =E2=80=98frame-parameters=E2=80= =99 are constructed ad-hoc from internal values (see Fframe_parameters for some general parameters and x_report_frame_params for the X Window related ones). What annoys me about the 'minibuffer' parameter is that it OT1H does not depend on any extraneous issue like a toolkit that is only able to draw things in certain sizes (like scroll bars on GTK) and that OTOH someone decided that in some cases it should specify a window which is not its task. >> This frame parameter takes effect when the frame is created, and >> can not be changed afterwards. > ^^^^^^^ > cannot (typo) A Freudian one, perhaps. >> But apparently it is possible to change the 'minibuffer' frame parame= ter >> after a frame was created since otherwise we were not able to redirec= t >> output as mentioned in (1). > > Yes. And why not be able to do that? And if there is a good > reason not to, then maybe Emacs should be fixed to not do it (?). Conceptually, it's a bad idea to set the value of that frame parameter: When, for a minibuffer-less frame, you want to use another minibuffer window, you do not (and cannot) change the frame's minibuffer-less status. So the frame parameter's value should stay unaltered indeed, ideally. But how else change the minibuffer window of a minibuffer-less frame? > Yes. I don't test it with `frame-parameter'. And I understand > that what you are saying is that it is only the value of > `frame-parameter' that is useless. > > But `frameset.el' does test it, AFAICT. Take a look at > `frameset--record-minibuffer-relationships', for example. > Perhaps there is a bug lurking there (?). IIUC =E2=80=98frameset--record-minibuffer-relationships=E2=80=99 is an at= tempt to fix what gets reported via =E2=80=98frame-parameters=E2=80=99. It must have = been a hair raising experience for Juanma to code that. Given a doc-string like default-minibuffer-frame is a variable defined in =E2=80=98frame.c=E2=80=99= =2E Its value is # It is a terminal-local variable; global value is the same. Documentation: Minibufferless frames use this frame=E2=80=99s minibuffer. Emacs cannot create minibufferless frames unless this is set to an appropriate surrogate. Emacs consults this variable only when creating minibufferless frames; once the frame is created, it sticks with its assigned minibuffer, no matter what this variable is set to. This means that this variable doesn=E2=80=99t necessarily say anything meaningful about t= he current set of frames, or where the minibuffer is currently being displayed. This variable is local to the current terminal and cannot be buffer-local= =2E which is wrong (because a frame does not necessarily "stick" with its assigned minibuffer) and not useful either (what should I make of information like "this variable doesn=E2=80=99t necessarily say anything meaningful about the current set of frames, or where the minibuffer is currently being displayed"). Also, =E2=80=98frameset-filter-minibuffer=E2=80=99 seems to do the right = thing. It's doc-string says When saving, convert (minibuffer . #) to (minibuffer . t). which fixes the mind-boggling sillyness that =E2=80=98frame-parameter=E2=80= =99 reports a frame's own minibuffer window when it has one. I slowly begin to understand why Juanma gave up coding for Emacs :-( martin