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: Mon, 25 May 2020 05:37:06 +0300 Message-ID: <3fa75ed3-52c1-be87-5af0-aa8aac4aca10@yandex.ru> 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> 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="81531"; 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 Mon May 25 04:37:46 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 1jd2zp-000L2P-5p for ged-emacs-devel@m.gmane-mx.org; Mon, 25 May 2020 04:37:45 +0200 Original-Received: from localhost ([::1]:56944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jd2zo-0003NZ-7h for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 22:37:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jd2zL-0002xO-Gk for emacs-devel@gnu.org; Sun, 24 May 2020 22:37:15 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:53196) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jd2zJ-00041w-RE; Sun, 24 May 2020 22:37:15 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id r9so3689464wmh.2; Sun, 24 May 2020 19:37: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=w4DF1Rtp1LDXo3nrcrenXNKLhXMudv+k53Wr90hbSkM=; b=axANsY8lQBLncCUQtIg5xzQ31MGY5MWTbyIkoGWVXWGkr29MfRrvcvBqtWqOZvy0zw gNVYD6eaVL9VUUw4y0JbszI6l8rJR4EaI+QGHXtjIPyTWiFWVjY6x9kawwl7B+b1B+Px io05hblUx4txratlznLBF5Nifdiqe6KABCCisSAXDD8eAd0hiZ7ySBwZ8YcsrsIVOCVr PH5VkojPBCuPwYYIr8YeJppUr3OL6o8wbcqcZ4igtn3n0x5Jj+XQAxFsfjdSh1VkX+sK dKqI6Z25huAiiFVTC6VLUxNq06D0P/uJraiCqxDay+UxrNzgsGwCTTGgnRXfCYXpBn7V 9YjA== 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=w4DF1Rtp1LDXo3nrcrenXNKLhXMudv+k53Wr90hbSkM=; b=dOS+lD5xBHhdQPeQYYzVXcXYOIhxE1nq2lvcYkNM715ku9STrLc2htG2SAZwLGMxqm HTGk+snEUwbiNNNHTPP12RgUoJ4Ad2p7d+ZGVARlpak6CJsoGZOBdiyalAdp4V1xxy0c cCoBqWEE4wvb7QU+J2ZM8LidsQ008sbI/qZRP1/9VVc61X+kLaKMh7HFjJWZBb2ek4VW gW8hBLla6i9nsiCt9OoKFmNuVZbLF1njI32ZRu6N8eyi+kTNg6CWvxaKqgOxfblaXdtD N5lWRYyQnvi7iyaooBDcR5sWcwt2/OInDrJlSocozN2B8WV66WyRSZwTRNTCFIuyUAlo MZ+g== X-Gm-Message-State: AOAM530XdxbdFDdvhXItfFDcf3JD7++z5DDRfun6ozltvfyJDrznTmyI m85B7IxtSeMlUPwHH5UcvRg= X-Google-Smtp-Source: ABdhPJwCDjGh6YR7z04GS+2CLM/bR3PkY9a+VGWmZ5lbDwakxzSJPqlM6QGZhmfMWbURhMwYxibw8Q== X-Received: by 2002:a1c:5683:: with SMTP id k125mr12545704wmb.55.1590374231117; Sun, 24 May 2020 19:37:11 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 88sm14662338wre.45.2020.05.24.19.37.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 May 2020 19:37:10 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=raaahh@gmail.com; helo=mail-wm1-x334.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:251337 Archived-At: On 22.05.2020 12:31, martin rudalics wrote: > >>  > I've also noticed that initial blink during startup, > > 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. Even with > >>  > resize-mini-frames=t. But then, it doesn't resize as responsively > as your code. > > Why not?  The resizing step is quite the same. One difference I noticed is that the child frame created by pop-up-mini-mode is constant width, but the mini-frame created by the above recipe updates its width dynamically as well. And always feels kinda cramped. 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. > > 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. > > This is not about understanding the details.  If you want to use a mode > that is based on child frames and minibuffer-only frames, you first have > to know what kind of advantages these offer.  And both, package > developers and users, should be aware of the basic glitches that are to > be expected in this area. That could be described in the README, I suppose. And it's one thing to grasp the benefits/drawbacks, and another thing to know in advance how to set up a minibuffer-only frame for your own setup. > Sometimes I'm not sure whether child frames are used only because they > are there. Well, why else? It's the only real way we have to implement "popup" windows. Too bad they don't work in the terminal. > Basically, child frames make sense only if any changes the > window manager applies to the parent frame (like deletion, iconifying, > changes of visibility, size or position including the z-order) should > automatically (without Emacs intervention) apply to the child frame too. > I added child frame support mainly because the handling of the signals > that come with any of these changes can be cumbersome and occasionally > even daunting. Makes sense. > Things a package could handle with a normal frame or a tooltip frame > should probably be done without child frames because, for example, > reparenting a child frame and fitting its size and position to the new > frame can be tricky. 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. > >> 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? > > 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. Anyway, having glitches could be fine if they are outside of the main usage scenarios and/or well-understood and documented. > Note also that IIRC the text you see in a minibuffer window is sometimes > only available there and bears no relationship to any text stored in any > buffer (or at least the buffer whose contents the minibuffer window is > supposed to display).  The display engine automagically handles the > display and sometimes cancels the traces of the source it used (Eli will > correct me if I'm wrong). That's um, sounds like space for improvement. > >> 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. > > 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. > > 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? > 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? > >> 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. > >>  > - 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. > > 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. > > 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. > > Maybe it's a also just a GNOME on Debian (unstable) issue.  Installing > GNOME shell here as additional desktop forced me to install all sorts of > additional software amounting in sum to around one GB of code.  This > included games and horrific applications like tracker which I had a hard > time to switch off.  I'll eventually try to remove and reinstall it but > it's nothing for the faint at heart. There's also the option to use a virtual machine. Provided the "physical" machine is fast enough. > > With Mutter only, or with GTK3 toolkit build only? I can make a build > > using a different toolkit, at least. > > Try both, if you can. With Lucid, the blink is the same. > >>  > 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. > > I faintly recall to have seen this with GNOME shell.  Which means you > have to put it on the mode line or the horizontal scroll bar there.  Do > other child frames too have problems when covering the scroll bar?  What > happens with the scroll bar at the right?  What happens when the > minibuffer window has a scroll bar itself? 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. The minibuffer child frame from pop-up-mini-mode seemed to show glitches like that when it was resized, to accommodate multiple lines. > > I agree it's a problem, just don't see how it is a problem for this > particular endeavor. > > Because "this particular endeavor" would then only serve to cover an > underlying, deeper-rooted problem and possibly postpone fixing that. I wonder if anyone would be working on it at all, if we weren't talking about it 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. > > High-level code - for example, code that wants to know the width of the > minibuffer window before putting things there. OK. I've seen problems of this sort. > >> 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. > > 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 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.