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: Fri, 22 May 2020 11:31:29 +0200 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: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="129715"; 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 Fri May 22 11:35:49 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 1jc45l-000XcF-HD for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 11:35:49 +0200 Original-Received: from localhost ([::1]:58714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jc45k-0001qz-C2 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 05:35:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc43L-0007QT-5F for emacs-devel@gnu.org; Fri, 22 May 2020 05:33:19 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:36973) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc43J-0004wI-Oa; Fri, 22 May 2020 05:33:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590139892; bh=r0OrwvfQwPhBjX3CePeCLchMhXDIkL1RPiFiHsDDOMY=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=WK32IMF/ia6ivo0iya9BmWBd8Q/5qHc2mdPc124dB2sFiAYYxOPEytYl3a3jP65Ht qpelNSIrk2TKKdiDlC3vbVJvzIJr+IZS5hAd9Za+TsCNAQ27oK94MKMC9om1MDa2uf 6umhoeH5TUoUKCMGBHQvZ7lWNNKeTCZVxN4jCaqM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.50]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mplbx-1jGlQH2lGn-00qCdO; Fri, 22 May 2020 11:31:32 +0200 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:gjyclFpXoqRcH24hcqXylRwpFrX9HRMn01m8kg+RgWT4GmsRl3w qjZLFTbiDjyACQrXrBycimsDEVMCloMYhB16T1gO5aPgMf7k1/MUqaaXldCwhjN2Q2Hp06+ Iimq8tkmU6W8VoujkabnDpQlZSD1ipPO9glPDd6H+uTMkLW7Xy0iNyxUnUwDAjVPImfkFVk dGJQnulGcUjIq66Wk0G6w== X-UI-Out-Filterresults: notjunk:1;V03:K0:+S4HO2ekXA0=:rRWh5rmC76aOVd+9/jlMUO OSeJ15+aq+n/XoJplUgjaMIw2OnfcAN6RqzlxEu0xQVNhcUlpWFgz29Ft62235hwF+E8yC+Nl X4zaFJIohLtCCg9uvih0eyN8Vp7dw31k1vn+/k96MACZx5ebfgwg+xHE0FdMcSY6P5l3xr608 HW+oAouEOq0GLGEbEalW7cWVNjieYjyNk2Q46pPdQM6uHHj2SAdOMcgI8S/l9UxRonc77H8F6 z8n8nqh5h5StrNP1qL5Z7j+crj/O7/XjJwEfYw0zCR/3CYv8x8/pwjmoxQVmUv2/8AiX8uu4/ tFElknz+dABXmi8p/3ljD360k0IGLv0E1w+x/uoSKq+szrx2knWzNeCqJkx3d+wMgCfwUPdrB SAqkecGH1oEl/sWTmjTXAvQ8K81R9o0CSQlShdAmwRH7Kj2MEzZnXUIUnz35nFqOcbc5iyxdZ hyFWUPm7TfBoxCz7nD4tETShIXH/Q3lxdRuKltIl3rj3KmdXscJ18Z3saMYGCCuR4M+6MCFJD xLFztUgU+AKO20T1tsnirneuOifrLENArxVwNDB1IeEF87wvkArLDh8sd17k8qdhcjGXOM4sZ 3hNLbcsVH8GpQ1YBQTvI1QN0+xNpRemMGniyKZIIwhnw/kJ0j4bUr9NGrrbVer1sYxuTgKrit 7DWpW893Of9ip5u1xD//ho7thg/j5ZuTmPOZj27vXAgLgz3BCwnID55mvYoH35E8pjuahwtrc ZlCcZlDsD7Mg7uSkslPyUc9NbRzeT4mSL5Q57ez681pnUh6CiKp7SQzkh8gew0PBXWBn1/7g Received-SPF: pass client-ip=212.227.17.20; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/22 05:31:26 X-ACL-Warn: Detected OS = Linux 3.11 and newer 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 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:251205 Archived-At: >> > 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'? >> > 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. >> 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. 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. Sometimes I'm not sure whether child frames are used only because they are there. 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. 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. >> 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 and transfer the text you want to show there to it. 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). >> 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. > 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. 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. >> 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. >> > - 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 ... > 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. > 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. >> > 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 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. > 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. >> 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. martin