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: Thu, 21 May 2020 11:07:32 +0200 Message-ID: <244b139e-cd5a-729c-4979-436571a6b1a2@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> <4518e4d3-f33a-256f-bb8e-342050bc59c7@gmx.at> <71896546-9110-3b00-1b12-40bc60c181e3@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="81314"; 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 Thu May 21 11:11:07 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 1jbhEI-000KyS-WB for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 11:11:07 +0200 Original-Received: from localhost ([::1]:60868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbhEH-0003wj-NX for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 05:11:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbhBT-0002Av-4C for emacs-devel@gnu.org; Thu, 21 May 2020 05:08:11 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:40801) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbhBR-0004kF-0n; Thu, 21 May 2020 05:08:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590052056; bh=ZdCyxaQq4TxMAjepzDt3yFZwokkIBj/qMOb5ZoeTAPQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=JHwtsKhBAAdGTKOvYWyNJ85z54kd0kXEUfstPmAHG/46sfi0IbfNCQrCI5FQanNfO wBal3vXRiFdBO1UG6OeL2gPdPQY+uE5nLUkV1wNMucNsGKMWrRg3IbSgHaaLpqkvD7 pP61G5wkoOaJaDBXdOTCxa06aiA0VK51a3FV28z0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.19]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLzBj-1jKIsj1GfR-00Hw4q; Thu, 21 May 2020 11:07:36 +0200 In-Reply-To: <71896546-9110-3b00-1b12-40bc60c181e3@yandex.ru> Content-Language: en-US X-Provags-ID: V03:K1:dTWVHjKtfar6yXANcYNyemHkBLfxHOR75yoJliCSQFuoz7zO8Z8 H4SboeI84xTMkjds9JY2gp8r6U+m4qZm6ZVvYMUWPsnxky0zBXFSaLow8cvQ8Z7owBZr7fW RujLgdwDsDxCtQZNXM+EFCqn3CYLq0T1VLE07+CfhGXYEup4Fk+wcsFVX+yDl0xGbo83b7T fWy+3werAEdXdszoyXGIw== X-UI-Out-Filterresults: notjunk:1;V03:K0:JX2kp8+Ck/0=:DHAKyQK+J+9M9GCGaUIT+V bdcsX7qGctb3J4u4jYMrZvhmOr1ojC4jowUptwI8BSQy8GDgymNl/VWGPP+0gGof9HeWeTXLE DIgwI4JT2Tt0QQ/SG203FDPHGCLHoHRrXnAU3puG5hTjUj5lTZ3M/G6Hke6qtG424jCk2ZKlh UpN/8jZrKiLMC/3sBKc3CKmiBqFFHfFtaxXuaLNHr0r+PqHchQ1xjynoV4aqP5ZlmOGijepKW d5W/JdjM4alqQaHyD18o4XDG6tNX8xNmnlHY43Gvl1ydPwc1WXpuiXUqcqQw+JWpLZaSDH9CI e95vxxtuJWLGTneh8VhqOdhkozyaysQXh3SDTFWWEWNN+jC7d+VHWsds3dnbnLMCQNdGuz4Mq ROK7zvbZaX/q2dvzZTaS8GVcF1hCEEmtBinpeJRm2bF9J3qJfvRsO6V0wPmT4sYwMKMV8AUqK gQkdBaUl6eGAttuMITHeBz+vJ2/jIQooXHIzqylSBrw9k1Gk6qB9dZhq6OwSS6NosLCELajcB AMMvW+1dLtylXMsFEuf3l20Zcb13fg4lWo4db+klDi/QRj6T1cqBiBUecHOfJyV9ofZ+I9ebQ JRxXOeMWrqn0PZUuR4djE/snyo0thkWG+oNrkQfG45ZFmjg5eSmGcKv7eWrGxb15UXUXN2CfE gY0GNIwCJkow3YveLGPvv2EYsPMz9ufFe1TeXOFvk8Cz/Ygi2uZJZDoYptDGREZ8JaPOxb2ZI eVokr4Ko4iUpZvg4t2QnM0cuy85keAtKPfOWYochJ0dkvs4MqR27fGNnrHg7LSQ6DwE+kUH4 Received-SPF: pass client-ip=212.227.15.18; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/21 03:30:44 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, 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:251157 Archived-At: > 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. Not really. There's C code that relies on the invariant that a minibuffer/echo area window exists at each and every moment of execution (I know because I once spent some time to find them all). If we manage to remove that single window, Emacs may just crash. > 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. Is this a blink that happens also when you do emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" or does it require the presence of a child frame? > - 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. It's not as simple as that. Users who want to use that mode have to make themselves familiar with child frames and minibuffer-only frames first. And even after that there may be glitches, especially when working with multiple frames. For example, transferring focus from one frame to another, while a minibuffer interaction is in progress, is a hairy operation regardless of whether you use the standard setup, a top-level minibuffer(-only) frame or a minibuffer child frame. > 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? I would have to guess the user's intention here. 'pop-up-mini-mode' does not forbid a mixed mode where one frame uses its own minibuffer window for interaction and other frames want to use the more "global" minibuffer-only window 'pop-up-mini-mode' found when it started. Also note that we have various strategies to assign the minibuffer window ('set-minibuffer-window', the 'minibuffer' frame parameter) so all this is more convoluted than it appears at first sight. > - 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. It's not a good option if it fails for some reason. On a TTY, say. >> 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). I can't reproduce that here. But I'm on xfce and currently can't test with GNOME shell which disabled itself during its never-ending attempts of unattended upgrades. > Instead of ido-mode, fido-mode can be used with similar effect. Though > blinking seems less frequent with it. Again, it would be interesting to know whether this happens with mutter only. > Another issue: when the child frame covers the scroll bar, it renders some junk on it. The horizontal scroll bar? That's where it is here all the time. >> 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? No. I spent a couple of months in the intestines of the minibuffer window implementation and came to the conclusion that sooner or later it will break down under the load people are piling up on it. Nobody here can tell you how many messages go by unnoticed in a session because one last message hides all the ones that were emitted earlier. And as soon as we start a minibuffer interaction, we enter an area where a message may temporarily obscure (or amend to?) parts of the text we just entered. And all this happens because we got used to it over the decades like the frog being boiled alive. What should be reformed here are two things: - Break up the conflation of minibuffer and echo area you mentioned earlier. - Provide the possibility to make the minibuffer window temporarily nonexistent (invisible or dead). Both are hard to achieve. The conflation was a premature optimization. People got used to it with the consequence that it will be very hard to dissolve it. Having a minibuffer window always present is a restriction that is now "built in". Dissolving it is hard because it would require to amend lots of code used to the fact that that window is always here. > A package could declare that it only works on Emacs 28+, BTW. pop-up-mini.el has ;; Package-Requires: ((emacs "27.1")) >> 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. As I explained above: If you want to use 'pop-up-mini-mode' you have to get familiar with both, minibuffer windows and child frames, first. > 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/ IIUC this one's about using Emacs on a TTY. In that case minibuffer-only frames won't help anyway. > One suggestion option is this package: https://github.com/muffinmad/emacs-mini-frame. Years ago I wrote the code to put the minibuffer window on top of a frame - something which should work on TTYs as well. But it's annoying: When resizing the minibuffer, the entire text in the windows beneath has to move up or down. When the minibuffer window is at the bottom, the text in the windows above usually only gets truncated. > 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. It would be interesting to see a list of requirements for a practical solution to this problem. martin