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: pop-up-mini-mode, was Re: GNU Emacs raison d'etre Date: Fri, 5 Jun 2020 05:40:03 +0300 Message-ID: References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <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> <4b652904-9966-f0cd-d6f4-ea625e4fa1b1@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="59379"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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 Jun 05 04:40:47 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 1jh2Hm-000FKT-4O for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 04:40:46 +0200 Original-Received: from localhost ([::1]:35224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jh2Hl-0005dv-3D for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jun 2020 22:40:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jh2HD-0005Cu-5M for emacs-devel@gnu.org; Thu, 04 Jun 2020 22:40:11 -0400 Original-Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:38988) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jh2HB-0005jA-Cg; Thu, 04 Jun 2020 22:40:10 -0400 Original-Received: by mail-wm1-x32d.google.com with SMTP id k26so7582567wmi.4; Thu, 04 Jun 2020 19:40:08 -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=A9gVjWBYNKpb7a/NKDo0XvJcg/239hL2zrOVwaTzqZc=; b=COqloHZjUDZwhfjNLT+xez7M3nIYR24wDKNp7nyc7XE9UPtHp4u4HSqkCKprhFLQuC Ak5jJidFcRgTdLrT2MEmn8IbtktXAvJmZoE6fYXb68lfuHDzwjxyblxyFU/HVvLoXu74 dlXT0ikM/0dkIIBAUuYQp5c/c8TfwjdMHFFqOxeMdHMTmAT/Y8tY899ygfgnd0xNnx1k HYUmevka3Q7l/WY+bXVI4gRsMqavxpWc+jUfQbJRrwUCgsPVIIlo9YsT4bl4rLbAqZ0V o+PJmyx/N26+O5xAu8QvWEky481JTn6lRI49tt9VvMAZ38Ey/JrzXVxLgYwTNKye4PfE H58Q== 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=A9gVjWBYNKpb7a/NKDo0XvJcg/239hL2zrOVwaTzqZc=; b=skk3nh0ShesgpXZwBA08AWG2ff5BXVStC9gjNdDwR9J1kiYxnJm+MRmHnxFWlskbG7 hkXXYA7mxS6kojnyn6YVk7IvzveU87xBLLg+lJXQJB8OzTnybM0Ws0CVnXxrlUf4sLI9 7t1xMjxOz8terRc4ip/IAhZPbGzlUtFMAFqKaN/vCRygXiySS1SR2AqCHzEy7oyyCBtO pHw9pVERuPvLTKroI76WmcO/O1QdQ3IJb1dnXu8pSKHloEqo4tlj/tp7rrEsGx2DQY3z hD4EfvwpTObTi6LlDnvSV/TDH6+9y4JXgHj1ElptB9PEAWg2bl8b9QSVxrGos7kT9ENl pi7Q== X-Gm-Message-State: AOAM533Epuomvxd2dygvl9txOwqIxihJx7lu9nU3cDXypH190RhByZVJ wKJJwfeWnwQ5SSz+/8hLCpY= X-Google-Smtp-Source: ABdhPJxWb3lRm48vkpH9jtZPCR6uPr9OAo7TeyOx2cIhRf/Ldoze2VlM++V5gDobq+5NRQJNlEmwrw== X-Received: by 2002:a1c:1d16:: with SMTP id d22mr368702wmd.174.1591324806494; Thu, 04 Jun 2020 19:40:06 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id z8sm10054517wru.33.2020.06.04.19.40.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 19:40:05 -0700 (PDT) In-Reply-To: <4b652904-9966-f0cd-d6f4-ea625e4fa1b1@gmx.at> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32d.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:251878 Archived-At: Hi Martin, Sorry for the late response. A detailed reply below. On 26.05.2020 11:06, martin rudalics wrote: > >> 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? The "blink" is present in all cases. They all delete the original frame to create one without minibuffer, 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. Okay, it's "constant" width. I don't really change the width of the frame often. It's the with of the 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? Updates its width "as well as" its height, sorry, that was probably unclear. Either resize-mini-frames is nil, and neither dimension updates automatically (meaning the height always stays = 1), or both dimensions update automatically, and the width follows the width of the prompt + input, and that... > > . And always feels kinda cramped. > > Which one is cramped?  The normal minibuffer-only frame? ...feels "cramped". Yes, the (minibuffer . nil) case. Setting this variable to 't' also has the effect of the minibuffer frame starting to "drift" across the desktop. It's probable the same issue we've seen with moving frames in GNOME Shell. > > 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). I have run with pop-up-mini-mode for a few days, and not I think I have a different conclusion: there must be at least one other bug in there, and that one could be contributing the most annoying part of the effect: When the aforementioned "blink" happens, it looks like the mode-line itself "blinks" (the one that resides just below the child frame). It's too fast to see for sure, but it seems like it travels up and then back (meaning, the window dimensions change briefly, making the window shorter by the same several lines). Maybe it tries to "give way" to the phantom minibuffer which used to be below it? When it doesn't, the resizing of the child frame happens fairly smoothly. So if the aforementioned effect is fixed, that would be a significant win. > > 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. Perhaps Someone (sorry) could start working on that? Then we could finally have a popup library that can be used both in terminal and graphical Emacs. That would be a significant win. I would certainly > But such popup > windows would be modal - you cannot really pop them down to see the text > beneath them. IME child frames are also always used to create modal popups. > > 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? I meant the first one, but neither really works well as a minibuffer replacement. The latter is also not very usable without the tweaks in popup-up-mini.el. > > 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. I don't know the low level details, but as long as the child frames themselves don't get focus (hopefully all window managers we want to support have provisions to enable that), switching the focus between frames should be doable. At least in theory. > >> 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. Even if you can't get all the benefits of pop-up-mini-mode for old frames (ones that were created before it was enabled), it would be better to enable customizations inside the mode. They would apply transparently when the mode is enabled, but otherwise stay out of the user's custom file. Also, I think I suggested the trick of re-creating existing frames with minibuffers disabled (following what Emacs already does when the minibuffer is customized to be in a dedicated frame)? That should work, and even the ensuing "blinking" shouldn't be much of annoyance, given it will happen in response to an explicit user command. > >> 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. Something like that. Given that this blinking happens only once per "real" frame, and it's a purely visual annoyance, I think it might be okay even if only a fraction of our users will benefit. I kinda managed to get used to this particular blinking after a few days. > >> 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'. Makes sense, yes. The "full transparency" idea could help, I think. > >>  >> 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. The users that do, will read the fine print in the package's description. The majority doesn't touch these functions (I haven't, in the many years of using Emacs), and if the package is going to work for them out of the box, it's a win. > >> 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. Again, I wish we could do it more automatically. Otherwise the fraction of our users who can benefit from this is going to be severely limited. > > With Lucid, the blink is the same. > > OK.  IIRC you had some old machine somewhere with a non-mutter WM ... Okay, booted it up. The machine has Unity installed, which uses Compiz. And a last year's build of Emacs 27. The "mode-line traveling" blinking is there. Just barely perceptible, because apparently Compiz is faster at rendering (on an older machine) than GNOME Shell released last year. It also happens less frequently there: I only managed to reproduce it like 5 times out of 30 tries (with my init script). And with 'emacs -Q', it's harder to catch, I manage to see this like 3 times out of 20 tries. The scenario, to recap: 1. cd ~/vc/emacs-master (adjust your directory accordingly) 2. M-x ido-mode. 3. C-x C-f e (the minibuffer should grow in size to like 3 lines; if it doesn't, change the size of the window). 4. If you saw the mode-line blink, good, if not, C-g and repeat. And hot on the heels of this scenario, another annoyance: When I do press C-g on step 4, first the child frame resizes to 1 line height, then some text flashes on it (the previous contents of the minibuffer? the current ones?), and only then it finally settles on the empty line with the word "Quit". That happens every time. I wonder if that could be improved, too. > > 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"? Sorry, 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? Yes. They weren't there with posframe. But I just tried to reproduce these scroll bar glitches with with x-gtk-resize-child-frames=resize-mode, and couldn't, in ant of the configurations. And posframe sets up this variable's value, so that's probably it. > >> 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. I meant, does that list answer your question? The one about "what people really would like to see wrt positioning and resizing the minibuffer window". > > 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. What do you use? M-x icomplete-mode is a trivial command, and it should be unobtrusive even if you're used to the default completion. > Does 'icomplete-vertical-mode' have problems > with Emacs' default minibuffer layout? It has problems with every child frame based minibuffer emulation package that I have tried. But no problems with Emacs' default minibuffer.