From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?R8O2a3R1xJ8=?= Kayaalp Newsgroups: gmane.emacs.devel Subject: Re: Interactive guide for new users Date: Tue, 15 Sep 2020 10:00:43 +0300 Message-ID: <87bli7sew4.fsf@gkayaalp.com> References: <83lfhjkq0r.fsf@gnu.org> <8620B5CD-CA92-46BF-80A8-DBE7052F4CA6@gmail.com> <83d02re2uk.fsf@gnu.org> <838sdfdzxo.fsf@gnu.org> <20200912121603.bsp53vgfwj3y62in@Ergus> <831rj7dvhg.fsf@gnu.org> <20200912131802.fiowctrzc2yx4ozu@Ergus> <83y2lfcdq2.fsf@gnu.org> <83d02pdb7b.fsf@gnu.org> <0deb5f7b-43f1-2611-b99d-327520eae158@yandex.ru> <83pn6o9y2z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18082"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.2.0; emacs 28.0.50 Cc: ghe@sdf.org, Eli Zaretskii , Yuan Fu , Ergus , Dmitry Gutov To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 15 09:02:18 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 1kI4yo-0004Zd-7j for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Sep 2020 09:02:18 +0200 Original-Received: from localhost ([::1]:36926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kI4yn-0001Ml-Aj for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Sep 2020 03:02:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI4xX-0000tH-Ad for emacs-devel@gnu.org; Tue, 15 Sep 2020 03:00:59 -0400 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]:50779) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI4xR-0001II-Ns; Tue, 15 Sep 2020 03:00:57 -0400 X-Originating-IP: 31.177.204.112 Original-Received: from localhost (unknown [31.177.204.112]) (Authenticated sender: self@gkayaalp.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 172C6C0013; Tue, 15 Sep 2020 07:00:44 +0000 (UTC) In-reply-to: Received-SPF: none client-ip=217.70.183.198; envelope-from=self@gkayaalp.com; helo=relay6-d.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/15 02:41:42 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no 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:255713 Archived-At: On 2020-09-15 04:42 +03, John Yates wrote: >> That'd be a misfeature, no? The text you were working on or reading >> will disappear from view. To say nothing about the fact this would >> mean a major surgery of the display code. > I do not feel so. In most other UIs to which I have been exposed, > when a dialog box pops up, there is usually no attempt to preserve > visibility of any particular portion of the underlying application. > Sometimes the dialog box can be dragged but my impression is that > an increasing number of frameworks are foregoing that nicity. My > guess is that this is because, with properly designed interactions, > it is exceedingly rare to need to refer back to the underlying > application in order to complete the dialog box interaction. Emacs supports far richer interactions than usual desktop applications (some examples in the questions below). It=E2=80=99s more than just =E2=80= =98referring back=E2=80=99 in Emacs=E2=80=99 case. > Minibuffer in its minimal, collapsed, single line state: [... snip ...] > Minibuffer grows by one line, "shading" the first mode line: [... snip ...] > Minibuffer grows to five lines, "shading" 3 lines of window 1's contents: [... snip ...] > It is this minibuffer growing from the top of the frame downward and > obscuring whatever it encounters that I describe as a "drop down shade". > > I understand that this is a new display behavior. That said, is it > not simpler and entirely independent of how resizing the minibuffer > works today? 1) How does this interact with a scenario where user goes back and forth between editing the minibuffer vs. some displayed buffer? 2) One might be looking at their notes while editing the minibuffer. E.g. imagine reading some docs and M-xing some commands from it, or naming an Org link, etc. 3) Would it be possible to revert this back to the current behaviour with a user option? 4) How is this better than how other editors do their =E2=80=98command palettes=E2=80=99? Isn=E2=80=99t it better to just pop up a centered fra= me and do completions there? With the added benefit of being able to move the thing around and focus back to the buffer. 5) While a command palette at the bottom of the application is somewhat obscure, one up top is probably novel. Frankly I don=E2=80=99t like the= idea of having a single empty line right in the line of my sight, constantly, taking up space right where my eyes go by default when reading stuff. -- =C4=B0. G=C3=B6ktu=C4=9F Kayaalp / @cadadr / pgp: 024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427