From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Interactive guide for new users Date: Mon, 14 Sep 2020 21:42:42 -0400 Message-ID: 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" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28242"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, Ergus , Emacs developers , Yuan Fu , Dmitry Gutov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 15 03:44:35 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 1kI01J-0007Fo-RZ for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Sep 2020 03:44:33 +0200 Original-Received: from localhost ([::1]:32942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kI01I-0000dz-Sz for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Sep 2020 21:44:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kHzzp-0000B1-0O for emacs-devel@gnu.org; Mon, 14 Sep 2020 21:43:02 -0400 Original-Received: from mail-lj1-f178.google.com ([209.85.208.178]:36045) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kHzzn-0007qF-1M; Mon, 14 Sep 2020 21:43:00 -0400 Original-Received: by mail-lj1-f178.google.com with SMTP id r24so1358564ljm.3; Mon, 14 Sep 2020 18:42:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AkpP6yG6orB5aUbgxo2o09LIXwhwy7pzGacuVhHoFh8=; b=O3xLTw0zLYlL8Jr+sLgFbx1+B5ywXqwLr2ZWDKkBq1EZvopeCXxMyTaHSjzd/nk/xV 11HO6s4DnsUR5gKcVCFLKtHo57ab/kJ0KAUI+EoO3EeryleqgGcoN9MVhb3jOgGbHjMr md83xYDBe6tuHHWFx0g4q2PC5pI3T9r3ipbEyR0aj8gbjbfXzXRsS6zaqLhWZ79jqvDO PAkclRwQe88ZRv0e/bVwxQ/gRs8xU00UT5CojgW/+YHHZy3b3MGrbQNdGeWjMc6qsEXV O3wSad4RGXOf/C7GKkDWHaabRjqzt0imIKqrUjsrcEv5qYPa9bGzQNGIa7uPOKKJqZU7 p3dw== X-Gm-Message-State: AOAM5325Vb6VTB9GWTkpO/l1zYJ79kDq06OAD4dYy4ZxvQaBW/g8nlGj vwkaXW+DEli+1mmtb+A6IKG0/2MKLyv9Fe7CNTRHcdoTzDEixA== X-Google-Smtp-Source: ABdhPJwktvxWkg5/Omn6z5ienmbwpBOjlDuAmHdntJAYGxJttXDwTsOljPsk2CZgavFbebPA//7vpcgRr3Btue+DDUE= X-Received: by 2002:a2e:7602:: with SMTP id r2mr6041082ljc.10.1600134174285; Mon, 14 Sep 2020 18:42:54 -0700 (PDT) In-Reply-To: <83pn6o9y2z.fsf@gnu.org> Received-SPF: pass client-ip=209.85.208.178; envelope-from=john.yates.sheets@gmail.com; helo=mail-lj1-f178.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/14 21:42:55 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:255697 Archived-At: On Mon, Sep 14, 2020 at 11:28 AM Eli Zaretskii wrote: > > From: John Yates > > > > * On growing the minibuffer, no attempt to keep point or windows visible > > 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. > > (i.e. a variable-height drop-down shade) > > Can you elaborate about this (and its relevance to growing the > mini-window)? I don't think I see the relation. Forgive me if I inaccurately conflate the minibuffer and the echo area. Let me try some pictures. Minibuffer in its minimal, collapsed, single line state: +=========================== Top of Frame ========================== | Minibuffer line 1 +------------------------ Top Edge Window 1 ------------------------ | Window 1 Mode line +------------------------------------------------------------------- | a | b | c | Window 1 contents | x | y | z +----------------------- Top Edge Window 2 ------------------------ | Window 2 Mode line +------------------------------------------------------------------- | p | q | r | Window 1 contents | u | v | w +-======================== Bottom of Frame ========================= Minibuffer grows by one line, "shading" the first mode line: +=========================== Top of Frame ========================== | Minibuffer line 1 | Minibuffer line 2 +------------------------------------------------------------------- | a | b | c | Window 1 contents | x | y | z +------------------------ Top Edge Window 2 ------------------------ | Window 2 Mode line +------------------------------------------------------------------- | p | q | r | Window 1 contents | u | v | w +========================= Bottom of Frame ========================= Minibuffer grows to five lines, "shading" 3 lines of window 1's contents: +=========================== Top of Frame ========================== | Minibuffer line 1 | Minibuffer line 2 | Minibuffer line 3 | Minibuffer line 4 | Minibuffer line 5 +------------------------------------------------------------------- | Window 1 contents | x | y | z +------------------------ Top Edge Window 2 ------------------------ | Window 2 Mode line +------------------------------------------------------------------- | p | q | r | Window 1 contents | u | v | w +========================= Bottom of Frame ========================= 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? /john