From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs raison d'etre Date: Wed, 20 May 2020 11:06:12 +0200 Message-ID: <4518e4d3-f33a-256f-bb8e-342050bc59c7@gmx.at> References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <4bb36686-34e7-4ac8-898c-74e254902349@default> <29f65907-affb-481e-82f3-62522a766f69@default> <83sgfybn22.fsf@gnu.org> <1701f0b1-a481-bb45-08b8-99da4a6139fc@gmx.at> <736c1336-58ea-dd1f-18ba-94f902e37f61@yandex.ru> <980996b3-bdfb-92e9-4b1f-594b8f5b68d0@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="33420"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jean-Christophe Helary , Richard Stallman , =?UTF-8?Q?Andreas_R=c3=b6hler?= , Emacs developers , Karl Fogel , homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, Sergey Organov , Stefan Monnier , Arthur Miller , Eli Zaretskii , Drew Adams , Stefan Kangas To: Dmitry Gutov , Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 20 11:09:22 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jbKj4-0008b2-B3 for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 11:09:22 +0200 Original-Received: from localhost ([::1]:47882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbKj3-0002yk-4h for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 05:09:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47994) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbKgV-0000Kv-GX for emacs-devel@gnu.org; Wed, 20 May 2020 05:06:43 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:40457) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbKgU-0003GX-EK; Wed, 20 May 2020 05:06:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589965574; bh=q2nZHDfKMYafHp0YrUHDCKzeEpg1GTVaLKLKdAEgXVI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ZJ50t00YUeIinSDNvb27vwbbGnz6+dta0We3gGr/EB/3g03F6oQlcdm+AYn6FOWnF l0auZcvn5hny6ZAOyD6ltNvVmrI/aeAiQR0nWIcSbwUmvEACPjcRV0GrzRMHwCNc5y WZcSjdeV5yL4ylFWu7Ipxs1QiT6R1MF7R0JLuDX4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.223]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MRTN9-1jNE4h1XzJ-00NPsf; Wed, 20 May 2020 11:06:14 +0200 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:G6tfkA71cQJcEgMdawBdwjBNNzcDE9ryd4LIF2uKnIauCrjmr/S +eZ/FPSB03cXz9touDD9vNfVuYBciSU3691D+S9LJZCnEBVX2Ky+I12VviFQ9ZYHX5h/+BB CACKq1KRi1fCp0K3PD2ynwU028o+28GpPA1T9PbxSSujx0mwM1Sb3/3TmVi9u4mK6AkvWT6 Y7l265cHxVIsCp71Agh9Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:eBm+sCEWhXo=:lsO6+flIJl5J87vaAOnsax LEOpd0ItlMBf4FF/ZNQUb40kf2B2H4yHtodfNS+t+Ees1z73InP0E4gFY9l2IZtskWgkEQg+g yYTLAJXYAj2UE0XvpJZ57lZqXVxgjRq9difquLdod/G5nOGzoi+UZYqCiczSMzO8HwYwwU8Jt 589PIYZ7lc2lde3+eZILjQtxX6LARmskw6Eg/b21MROxB8bSroWK6OmqRJ5VVBXqAMuPhnRWF LnItCM1fTtjvWzATZIDBzFNpNT5LyboR4mIsEFZ7A2f+e5BSyqutSp44vMFLrhxDD7pBp9mn7 0BzSV5+TdL7x5W91yuGG9b5wCoUmKrMSNQfWYcGs37dlQTOrAcpm3Xl4odpFUvD/8hc/xKX9e ST3E5d5BuXTpliQq2+CseqHeT5+F27bHSNziVzDRR8IWtpVCXy6pGc/bi4ucpL0Mdhj+OuDOS R8oTLNeyfJP/otiW4Q66G/J5wDa2YRFirqk4QPHJ/Cm9R3C2Sd4gBmUUSVL/tMFAJ0zcM8ukB am9vXUbaBHf/mf9Xa2sJnLQIdY9AnlJkEOQQTgFsVwFBIkUrnYUX4g8M7EQpOo1PJa7b5bdNj cEq/uUfqzjxlwT+Yomz1skoSs32zwim+eU2JGid0KrYcZ+unWwsWdfSzfGuMk2ksPivyxa93U Oxo8/Lg1ag49ex49xE3A1EiBg0YY6qEludCynqEycSIwanOS9tnumnneMcq4E8MjCcnl/bdFA Kz4d2cblXTTlx16yl7PnaMSI4nj3c0Vk7cDbSqnpk1no4Mq82Gw8ntnXpxaNIV1Nai4iJics Received-SPF: pass client-ip=212.227.15.15; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/20 04:28:01 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251024 Archived-At: >> Right. In a "normal" session you have to create a minibuffer-only frame >> first and then delete the normal frame to get uniform behavior. Emacs >> does not offer a function to remove the minibuffer window from a normal >> frame so this is the best you can get. > > Any chance to change the latter in Emacs 28? Is that difficult? It's hairy and that's why people never tried to change the ritual of setting up an initial frame with a minibuffer window. Likely to make sure that if things go wrong anywhere, there's always at least one minibuffer window you can act upon or that displays vital information about what went wrong during setup. Note that producing the minibuffer-less + minibuffer-only setup is accomplished by 'frame-notice-user-settings' which deletes the initial minibuffer-equipped frame in a hair-raising fashion in order to make sure that at least one minibuffer window is available at any time. > It would improve the starting experience quite a bit. The startup experience of general minibuffer-only frame setups or that of the setup with a minibuffer-only child frame? I think these are today also affected by other parameters like, for example, whether you put these specifications into an early init file or the normal one. > The main remaining annoyance is the blink when the child frame is resized/repositioned. You would have to tell me more about that blink. If it's due to the setting of 'x-gtk-resize-child-frames', there's nothing I can do about it. If it's due to the delay implied by 'pop-up-mini-hide-if-empty', try to experiment with that. > So how do you feel about a package in GNU ELPA? Not really enthusiastic. The historical constraints of how to set up and use the minibuffer window are too restrictive IMHO so what you see here is just a workaround. Maybe things will change in a couple of years. > If we can move the settings into the definition of pop-up-mini-mode, > it should be quite usable. And also do something with the scenario > where someone installs it, turns on the mode, and simply stares at the > error. What's so bad about that error? It simply tells what is missing. If you provide such a frame, things should work, even in parallel with the already existing minibuffer window. martin