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: Fri, 05 Aug 2016 18:37:50 +0200 Message-ID: <57A4C0DE.3060506@gmx.at> References: <579E3F9E.8020200@gmx.at> <83h9azl4s1.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 1470415155 22529 195.159.176.226 (5 Aug 2016 16:39:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Aug 2016 16:39:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 05 18:39:12 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 1bVi9F-0004G4-Ru for ged-emacs-devel@m.gmane.org; Fri, 05 Aug 2016 18:39:01 +0200 Original-Received: from localhost ([::1]:46211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVi9C-0008EL-Kb for ged-emacs-devel@m.gmane.org; Fri, 05 Aug 2016 12:38:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVi8L-0008Bq-L8 for emacs-devel@gnu.org; Fri, 05 Aug 2016 12:38:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bVi8H-0006sJ-Qs for emacs-devel@gnu.org; Fri, 05 Aug 2016 12:38:05 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:61135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVi8C-0006rp-9D; Fri, 05 Aug 2016 12:37:56 -0400 Original-Received: from [192.168.1.101] ([212.95.7.19]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mc9U3-1bmyOs2KGd-00JZCG; Fri, 05 Aug 2016 18:37:53 +0200 In-Reply-To: <83h9azl4s1.fsf@gnu.org> X-Provags-ID: V03:K0:OutZnfadGm1v7gGgWgs1W3kK5JZ7uYQsI2MblTZlNKDA8FF3QcT AjPKaYjmXDOgogkKUKivaugaTcnoIr2pPgPTdlc87Hk4SfMtqbz8noHZrxhlxc0ILc4v5HW pAWoxzEl+od32Lgp5B84XjelLaTH93S23J+nOKn+4s4hqeTDHMgaB9RGRnf5ehk4l2EQ5VP ihDmbSbjw/LKq5wOBIiDQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:oNKLAPfRFII=:AIXWFGfw4JahK3JLDWTqeh ekbmG78nocJfbnnFJOksEj8I90de756wUwZcX/4/IPe4sH9mDNogPlTmtMP9yZs9zwtg9U8Te K+kkiJHTFdD2UTnQd0pxoaPwbpp5MI91P6r6E05fBMuDBZ+TgjMjbDA7/HWakAS5zyQDG9uip dNK+QQ0nZjqPqil+JigOzRgULcXcTJgrnuaNvPqHoalcrdNaDrHui2d9AmDl8UDNNcATHHC/Q KdrEf+ohIltmwQ/iwaKeRMBCEyeYZ1WJxN6Mp0lUx5441FMfldcoXPuqclqAY7GW1fGs1ktlf Rfz7ycFeltqe0W8hGVTdILhOlYcVAS4amV/9dIRPnPjekvBCWm8XoFp2oPM2FSef9AsubZxP/ E6cZr+uN1N7/8Pox+tiIzWXPBJgRKfWSZLaxNI5hOLqLs9f5SIGrZGk7TrCO5QwwIV6+stioE 7qC1N20wGISSg7es+VD4qS6dMNBNs07uvEbYoxuvfQdgR0vTYGx1VGEClepC5rvpSYggYwIaR mow/apW4pzb121QH06tj9fYXFWh5ZSDLeHYKfC+Xp7R4+/lSW3K/It2dYsPCJaQ6RKr/vPfMh zirM4NC5VfwVDhqNpy/43+pqlGhIhKqU3EyxQ5ZZGsOYyEVmwHFyeQlp7qdg/Qitrhtqugde+ Pc7GM7WLNKR8JgNoRIZoHM5GZbMh1MtlmT03ilgoRNokKh6ic3ba6V42tuTAvLiAqlhehIm6A DazZxEeQzuYRux9J40Aa4gwkoiQ4vHVD5EiuiG1dTf0XWC2Rhg4Qn+YzQqB8X9s9aIap/Vf+ 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:206427 Archived-At: >> I'm not sure how to deal with this situation. Personally, I'd prefer= to >> report the real, internal 'minibuffer' parameter but am afraid that >> might break existing code. > > You mean, you think there's some code out there that expects to > receive nil in that case? Do we have any code in our tree that might > expect that? I'm afraid so, yes. Otherwise this rigmarole would hardly make sense. But I haven't checked all places because I rather soonish stumbled upon things like (eq (cdr (or (assq 'minibuffer initial-frame-alist) (assq 'minibuffer window-system-frame-alist) (assq 'minibuffer default-frame-alist) '(minibuffer . t))) t) in =E2=80=98frame-notice-user-settings=E2=80=99. And one revealing comme= nt is in =E2=80=98set-frame-configuration=E2=80=99: ;; Since we can't set a frame's minibuffer status, ;; we might as well omit the parameter altogether. >> In any case, the documentation should be fixed. Somehow. > > Before fixing the docs we should decide what the code should do. That's what I tried to initiate. Is there anyone out there who has an idea how the 'minibuffer' parameter should be set and used? Maybe nobody uses them any more. martin