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: Tue, 26 May 2020 10:06:09 +0200 Message-ID: <4b652904-9966-f0cd-d6f4-ea625e4fa1b1@gmx.at> References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <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> <3fa75ed3-52c1-be87-5af0-aa8aac4aca10@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="112935"; 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 Tue May 26 10:10:25 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 1jdUfJ-000TGV-Fa for ged-emacs-devel@m.gmane-mx.org; Tue, 26 May 2020 10:10:25 +0200 Original-Received: from localhost ([::1]:45828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdUfI-0005mA-BU for ged-emacs-devel@m.gmane-mx.org; Tue, 26 May 2020 04:10:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdUbh-0002wp-8j for emacs-devel@gnu.org; Tue, 26 May 2020 04:06:44 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:49627) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdUbc-0004oa-3i; Tue, 26 May 2020 04:06:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590480372; bh=fNPnSs4hI7nwbDEaL9BPWyj6lnuiJ5/YQqmzNooVzRQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=c9uqkjErVY7Ika08be1SrbmByhbiZAznqbpZKoabnUbMxp1X7q98m//VBw20ZiXhh OJABb97uRhHFA2Np0ZSMXoo+9qLwIjr8iQMMMBMLnZ2iZ3/VVe0SeqEY+b/gfc/RtC HNFky+UqKVEzVR+b2lGNlaexrnXrTTHh7nGdFUvk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.36]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0Fxf-1iqcy32V9z-00xHfI; Tue, 26 May 2020 10:06:12 +0200 In-Reply-To: <3fa75ed3-52c1-be87-5af0-aa8aac4aca10@yandex.ru> Content-Language: en-US X-Provags-ID: V03:K1:j75ehYayPUGRVnOQBBmiopXFW/DIFRPiOhMQQURz6MkW8zBvZMo 4FmNLdmd+qcEj03xpvcIKYOWv4sURNHIDEkXKZd4hzrac06kKK9MRgV8u3LJGoY66koQ+Xr 7Cye+eFhVik91d9yqbzVOu80aDtiiRPT0ieDX3EoGeDFzhhE4k+QWcdFOmYma443w5EFARt qAsa7Vqzjz0v9docVT97w== X-UI-Out-Filterresults: notjunk:1;V03:K0:j8lpMJPQWWE=:M9h4/FbJ9okxLRBEsZExOs U9351jZr7YQtU7ArioCQlVG8NykYV+uwdFOnhXWk8WJNXmVyaFNvNFSUkEyMNiR0gusP7w+pr V1hwjDD+JhxCwBbtz9XMAjhM3NWoy9BjW0vLAsb9kiLCzF6awlx0X3yGdnB4aa66yJFM5UUw7 +5PvrcbP3GBegEr46WHxBSSoBEi2cdvzDRc4TBwxcUo3cJ+6RVdtSSGmkNgIwrc17xj0s1sZf bps5EQQL7f1ORmIguBI2I5c/qyCm7PdaGlK8ihXK8WMnQ/A/5Bo5EYvdK/p0qxQA5sx81GTKb 17BHSClxNsctosWaDNSkvXY0+ckVEBaJjZQPeS66VyFoPfzwZ+5AyPU4erTSSpPpuajg/UdeQ T9OonVPifqWRdrUosNU7O7R5jErxwAsb0L4XdGoNSle5wMgfFsAlqreypT8d0kJqHypszyf/J ZA0I3IcQuFcfODX8e+uSrliQIxY1WAN7CLgu+3Vo57eJOF0Jx07mkKOWkXConcHBiqr2kQbEi cBN3IB91YVWtfQhuF16igxB8KgYnbibyx+zv/9y4/CNUV73X94kfOe6bbl7dZ2N8iA+DbQP3q rID62a3BATCUFARfEA3Zhr8ktsOM+ixwhPKnmt3mKSS61eNtbv19u+Uf07D8/M9Cuo02SeRxR qo1OZ5b9EMwYeko0WPMmYFM5l2WI/lFVd0FSBhgGTFcZ3jEkhqMzql1g4PObD7irsNIRTBYaB rYyP7ebaRIe0nkwkmgGWfvVPNvu6kVugROcMDDKZ/GR30sHtYTcSoxunMD8AFuTumXtt+nYo Received-SPF: pass client-ip=212.227.17.22; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/26 03:13:45 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:251440 Archived-At: >> I forgot to ask what "startup" means here. Invoking 'pop-up-mini-mode' >> itself or starting a dialogue as with 'ido-mode'? > > Neither. Emacs startup, and the blink that comes with re-creating the frame. I just meant that I was going to talk about this at some later point, but now I didn't have to. ... > >> >> > 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. I'm confused. When you do emacs -Q --eval "(setq initial-frame-alist '((minibuffer . nil)))" you do not see any "blink". Right? When instead you do emacs -Q --eval "(setq initial-frame-alist '((minibuffer . child-frame)))" do you see the blink? Finally, when you do emacs -Q --load ~/pop-up-mini.el you see a blink. Right? > One difference I noticed is that the child frame created by > pop-up-mini-mode is constant width, I don't understand. Here it changes its width together with its parent frame. > but the mini-frame created by the > above recipe updates its width dynamically as well Why "as well" if the pop-up-mini-mode child frame is _constant_ width? > . And always feels kinda cramped. Which one is cramped? The normal minibuffer-only frame? > In any case, it really seems like the blink is due to how updating the size of the popup works: first, the buffer is updated (and redrawn), then the timer resizes the popup, and the buffer is redrawn again. Not sure what the better implementation is going to do, though. There is one problem you cannot avoid: You have to know the size of the minibuffer text before resizing its frame and only after that you can determine its position (within the display or its parent frame). > Well, why else? It's the only real way we have to implement "popup" windows. Too bad they don't work in the terminal. We could do that just as we pop up menus in a terminal. But such popup windows would be modal - you cannot really pop them down to see the text beneath them. > Not sure how it's relevant to the package under discussion. The minibuffer frame I've tried with that default-frame-alist setup didn't really provide a good UI, looks or behavior-wise. The (minibuffer . nil) one or the (minibuffer . child-frame) one? >> > Is there a problem in creating a minibuffer child frame for every frame? >> >> I had that in an initial version but it's unlikely that I can still find >> the code. By design, you can create and use an arbitrary number of >> minibuffer frames. The only problem is to find the right frame you want >> to use ... > > Via... a frame parameter? OK, I'm probably not going to be very helpful here, at this level of discussion detail. If there are specific hard problems with repro senarios, I could try to take a look later, but I'm only interested in going in this direction if our goal is to make a package for a broad audience. Currently, every frame must have a corresponding minibuffer window. If you have more than one minibuffer window at hand, you have to decide which one to choose. For example, with (minibuffer . child-frame) the situation is clear - the minibuffer window of each frame is that of its minibuffer child frame. >> Agreed. And that's why users have to put the necessary customizations >> in their init files and not simply call 'pop-up-mini-mode' from a >> running session. Although the latter might be a seductive way to test >> it. > > Are you sure this customization couldn't be applied by pop-up-mini-mode? Alternatively, it could be a setup function. In practice 'pop-up-mini-mode' is simply not something that comes up without customizations in your init file or by calling it from the command line. The reason is the one explained before: You cannot convert a minibuffer-equipped frame into a minibuffer-less frame (or do the opposite). The same holds for (minibuffer . child-frame) and (minibuffer . nil) setups. >> > 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? >> >> You mean when Emacs starts in minibuffer-only mode, I presume. It >> should be possible but the following part >> >> ;; If the frame isn't visible yet, wait till it is. >> ;; If the user has to position the window, >> ;; Emacs doesn't know its real position until >> ;; the frame is seen to be visible. >> (while (not (cdr (assq 'visibility >> (frame-parameters frame-initial-frame)))) >> (sleep-for 1)) >> >> inhibits it currently. The problem perceived here is that one cannot >> derive the actual coordinates of a frame _before_ that frame was mapped >> by the WM and mapping always means to make it visible. > > What about full transparency, then? You mean we should come up with a fully transparent frame first, resize it and make it opaque then. I never played around with that but note that this would require a compositing window manager and not all of them support transparency of child frames. >> OTOH the actual >> coordinates of the minibuffer-equipped frame are needed to make the >> minibuffer-only frame appear at the same position and with the >> requested, properly modified size, taking the user customizations into >> account. > > The minibuffer-only frame which is immediately hidden itself while pop-up-mini-mode is active? The "normal" frame. Note that you have to delete the old minibuffer-equipped frame created initially and then replace it with an "as similar as possible" minibuffer-less frame. Look at the code of 'frame-notice-user-settings'. >> >> 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. >> >> These are user options a user can change any time in a running session. > > Perhaps we can say that they shouldn't. I think they do already. >> But you don't like such aborts ... > > I don't like abort which presume a lot of prior knowledge and/or manual setup. > > "Sorry, pop-up-mini-mode is not supported in a terminal" sounds just fine to me. There's nothing else to do anyway. It means that when you customize the minibuffer behavior in your init file, you will have to take into account whether you are going to work on a terminal or a GUI or maybe both. > With Lucid, the blink is the same. OK. IIRC you had some old machine somewhere with a non-mutter WM ... > I have just tried company-posframe, which renders its popup through the posframe package, and could find such artifacts, even when the popup overlapped the right scroll bar. "could find" or "could not find"? > The minibuffer child frame from pop-up-mini-mode seemed to show glitches like that when it was resized, to accommodate multiple lines. Glitches with the scroll bar? >> I'd still like to see a list of what people really would like to see wrt >> positioning and resizing the minibuffer window first. > > Does the list at the bottom here look useful? https://github.com/honmaple/emacs-maple-minibuffer/#maple-minibufferpostion-type You mean the list of positions? We can add that to 'pop-up-mini-mode' if we make sure that the child frame always fits into its parent. Although we do not care much about the size of the minibuffer window of a minibuffer-equipped frame when that frame gets very small either. > If we had something like that, as well as automatic resizing of the minibuffer popup without blinking, that would be great. Especially if the result worked fine with packages such as icomplete-vertical-mode. Since I already don't use icomplete investigating the latter would be quite demanding for me. Does 'icomplete-vertical-mode' have problems with Emacs' default minibuffer layout? martin