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: Fri, 22 May 2020 02:16:08 +0300 Message-ID: References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <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> <244b139e-cd5a-729c-4979-436571a6b1a2@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="84033"; 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 Fri May 22 01:16:48 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 1jbuQh-000Lir-Fq for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 01:16:47 +0200 Original-Received: from localhost ([::1]:51100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbuQg-0001C1-G6 for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 19:16:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbuQB-0000kV-EF for emacs-devel@gnu.org; Thu, 21 May 2020 19:16:15 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:33602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbuQ9-00044J-TD; Thu, 21 May 2020 19:16:15 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id l11so8381689wru.0; Thu, 21 May 2020 16:16:12 -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=6Dw9SNATPKt5CJjCC41Vq5PjQgo/i1P5YzFpFPf8KnA=; b=L8Ds3XIxLCKg2noQNkYTGmhgQA2aGOPfGslypNgtZFudixesgNbFQFf1XPI/sKPceU IpkBrzbxt9Q91ki0r3sYBbm4SkvYZS9DfHYix3S1v95Ud1Iksi0AWX7hw7RxCLwfwYB7 DzFAXco36iKYkuPQapTAVfgLvjgAt+yPc7BOPGOA5pxkS7cLh6ZUgqZy67NlNZCyZbYD pOq8s5JNq6vgg5+Ua6nNxgp34M6Ry5aJNch7oGOHYt1avNILRPOY6rz8WvKiZx8PfJyZ vb7uDhaREuoBtYMUBydze5LmV3RCcAOA7tPebwzJ+tDqW/pVSP8owOTCrsm3eobOdWNF KtZg== 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=6Dw9SNATPKt5CJjCC41Vq5PjQgo/i1P5YzFpFPf8KnA=; b=K5kDnCbn3+tLTHepNptvRFSQG86VH5VXoYmpT5ZmGLTMdVesctMfOhsWIe5X5CAOjJ KMkovuDyMRdAmW4hFSY3WYHwsmQLE56wvq6ojP1V5DCelpz8cKMZii/NhUZkVaKiBdB0 hZgjNfAJm5XHsXaY3w2/xeW9vV+5/ocPY+r8186sXeIASzjRXx2vsXa6OUkok1tNxNkD zaAtqv7iAJBFo/poWl73PQOPwqsOqVSckYtJVxcMxNuhfQp7AXSaSPDoWherFeAD7T7X dIF9cwQhwEzbmc+IjsFr44Jj8mzK8c4edYJwNy3eGxxLcgFYGe/aKqKUSRqHOtczwiex 53VA== X-Gm-Message-State: AOAM533ue0SgoZIQnuzKM2qlE8Dn472E/1VoQPpMMSjbfy2iqB5d+hj/ mGt7SMoGccmsSiLy1PZHwR4= X-Google-Smtp-Source: ABdhPJzvE67Ew08I1DpLOQIi9j8KuQnm5Axkr5A/tjFVAqRdWG6tn7LyMzTlVseiRHJQnKQs4YP5Tw== X-Received: by 2002:a5d:6cd1:: with SMTP id c17mr696170wrc.380.1590102971686; Thu, 21 May 2020 16:16:11 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 1sm8245832wmz.13.2020.05.21.16.16.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 16:16:10 -0700 (PDT) In-Reply-To: <244b139e-cd5a-729c-4979-436571a6b1a2@gmx.at> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42f.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:251191 Archived-At: On 21.05.2020 12:07, martin rudalics wrote: > 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. Hmm, okay. > > 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? I couldn't manage to reproduce the bug there. Even with resize-mini-frames=t. But then, it doesn't resize as responsively as your code. > > - 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. Please, no. You know the reason why we only fixed child frames under GNOME now? Or why packages using child frames only started to become popular? This is arcane stuff, and it took someone really motivated to turn the child frames support you created into a library every Emacs developer can use. There are a few other authors who understand it, but we can't expect the average user to know these details. > 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. Is there a problem in creating a minibuffer child frame for every 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. We don't have to support every possible intention, just the most likely one. The rest can be left for future development, or available as a customization option. BTW, when you delete the initial frame at startup, is there a possibility to make in invisible at the start, so that it's actually never displayed, and when it's deleted, that blink doesn't happen? > 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. These are implementation options, right? Just pick the most appropriate. > > - 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. So pop-up-mini-mode would check if it's running on a terminal, and if so, abort with a message. > >> 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. A full reinstall of a distro and/or switch to another one is out of the question, I take it? I'm not sure it's a GNOME issue. It doesn't update itself: package managers do it. > > 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. With Mutter only, or with GTK3 toolkit build only? I can make a build using a different toolkit, at least. > > 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. The vertical one. The child frame spans the whole width of the frame, and its right end overlaps the parent frame's scroll bar. > >> 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. I agree it's a problem, just don't see how it is a problem for this particular endeavor. > 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. Sounds like we're talking about low-level code only, right? Like prin1. I suspect there's a limited number of functions like that. > > 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. Right. That's a similar reason why I really want minibuffer out of the current frame: as soon as it gets multiline, window borders start jumping up and down. > > 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. Behavior-wise, I think we're fairly close already, but "the user has to get familiar with both, minibuffer windows and child frames, first" sounds like a deal-breaker.