From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs raison d'etre Date: Thu, 21 May 2020 03:15:14 +0300 Message-ID: <71896546-9110-3b00-1b12-40bc60c181e3@yandex.ru> 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> <4518e4d3-f33a-256f-bb8e-342050bc59c7@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="89856"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 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: martin rudalics , Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 21 02:15:55 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 1jbYsN-000NFG-3V for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 02:15:55 +0200 Original-Received: from localhost ([::1]:39176 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbYsM-0001H8-4Q for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 20:15:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbYrp-0000qB-Tr for emacs-devel@gnu.org; Wed, 20 May 2020 20:15:21 -0400 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:41815) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbYro-0003r3-HQ; Wed, 20 May 2020 20:15:21 -0400 Original-Received: by mail-wr1-x435.google.com with SMTP id h17so4916534wrc.8; Wed, 20 May 2020 17:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uJ3nQ4Y6us/wlcVscPeFkoV3jmJREYqkhdQtBqdpzPI=; b=KHX95WU7kiPBScEOXUSis3Aazr1gva4Lj2qJH54VmErEmP9xzc1WSnq3g7YPppG+yu zj6C+A11QyEuaxLJ8tfi5jug25un19oYIxE00CgZ3osyrNS6ohjCG6lxx4OiSc0TZaXn 9yqaWo3iLglKAng7nIDyzXFVQ4dElbparwU3pwq9Svq6u43rm74NESxJudDkWP3WKjMR hFeMDnay5FkA12pk/1acsgcULIurBT8oeSMJF4JIeiQl9F9lD4cRzyMPPzOFHtL094v6 3kXqCW89GhipBtZ16TIHU+ZACRk6QmWsCbpSRrf5JGwPxshyhZKFS8Hk1+yazpDwfUaf YCOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uJ3nQ4Y6us/wlcVscPeFkoV3jmJREYqkhdQtBqdpzPI=; b=dpWYXKr5XS9k/WPvA/pfdz9sgnDAbBYPhLsoCZ95JnYIcvkrlpS1Cd0rq9wBKF2OHy tGETnO4eZeFG/DsRXUIXGR1yDLJXTnI62mVHMP5zH5IFdAhiPk9aRqZl6Z6ha2l7smPG xDZ3giCecQwE8cDgV8+IhnNuYq3E4UjI+0F8UbEHmqMI3YJ/K6qhjU6FHwzWRM7yFnXy gnTu2O1qidd2TuE5xasuVr9FkYJsj7udLjyXisWpfLq2CgcseHFUXhMefguTbSA3HOPb JwNSeIZPH6AsOPm0dz1ubKtmqjT4SbGLrP23pqUWcQL0i5n08E20vlZhOuSsXq/FY8HH +lRQ== X-Gm-Message-State: AOAM532khCa6z+pkayrctw+Y5NuBzx5ElzEP9nNeL+bTi89XcnaFISfo psPAX89jnRvjGN2GVG67pws= X-Google-Smtp-Source: ABdhPJzXEO0oX/lC4HJ6zTJn7nuujxkPOrwTQDD65QsTb0uMkAHYgJJZCMtg9w91YlXGytXYujK6kg== X-Received: by 2002:adf:ef8b:: with SMTP id d11mr6014332wro.196.1590020118260; Wed, 20 May 2020 17:15:18 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id u65sm4683292wmg.8.2020.05.20.17.15.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 17:15:17 -0700 (PDT) In-Reply-To: <4518e4d3-f33a-256f-bb8e-342050bc59c7@gmx.at> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=raaahh@gmail.com; helo=mail-wr1-x435.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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:251131 Archived-At: On 20.05.2020 12:06, martin rudalics wrote: > >> 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. I get the idea, but Emacs is not a whole computer, to try to keep running at all costs. The config can be fixed, and Emacs can usually be restarted. So whatever the original reasons are, a user option could still be doable. > 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. I've also noticed that initial blink during startup, but didn't know what to attribute it to. Would be great to be able to avoid it. > > 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 startup experience of pop-up-mini-mode. I can imagine two main scenarios: - The user installs the package and turns the mode one. If we can't disable the minibuffer, maybe just enable the rest of the functionality, and describe minibuffer-disabling-on-init functionality separately? It could even just be a line we'd tell the users to put in their init script. Alternatively, since you described what happens currently, pop-up-mini-mode could try to remember the current window configuration, create a new frame on the same position without a minibuffer, restore the window configuration there, and delete the original frame. Or is that something that could only happen during startup? - pop-up-mini-mode is enabled in the user's init script. Is that worse than early init? We could try to document the early init as the best option. > > 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. My x-gtk-resize-child-frames value is 'resize-mode. Blinking happens when it's resized. But not every single time. Here's what I do: 1. src/emacs -Q --eval "(setq x-gtk-resize-child-frames 'resize-mode)" -l ~/.emacs.d/site-lisp/pop-up-mini.el 2. M-x ido-mode. 3. C-x C-f, type 'e'. If you're inside Emacs source directory, the completions should span 2-3 lines. When the child frame is resized, it will blink. Sometimes it looks like the mode-line quickly moves up and back (or at least _something_ grey moves like that). Instead of ido-mode, fido-mode can be used with similar effect. Though blinking seems less frequent with it. Another issue: when the child frame covers the scroll bar, it renders some junk on it. > > 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. Do you mean the child frame problems? A package could declare that it only works on Emacs 28+, BTW. > > 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. I didn't understand what I needed to do from it, and I'm a fairly experienced user. When doing a package, we usually try to cater to even less experienced users. Not always succeed, but try to. BTW, here's a today's thread on Reddit with similar complaints by users: https://www.reddit.com/r/emacs/comments/gmsnoy/minibufferecho_area_ergonomics/ One suggestion option is this package: https://github.com/muffinmad/emacs-mini-frame. There are a few others with this goal as well. But none of them try to hide the minibuffer (or know that it's possible, looks like). They only create a child frame with an "effective" minibuffer, and position it to their liking. Whereas the minibuffer line is left untouched, and is only used as echo area.