From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: GNU Emacs raison d'etre Date: Sat, 16 May 2020 16:12:53 -0700 (PDT) Message-ID: <5d158a63-7173-424c-9d9f-ce7856f1eae7@default> References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <70bb51fd-447d-928c-4d69-1c9673a44471@online.de> <871rnnvmdx.fsf@red-bean.com> <87pnb7sira.fsf@red-bean.com> <83zha8tluq.fsf@gnu.org> <87v9kwi6ta.fsf@osv.gnss.ru> <83wo5ccgg4.fsf@gnu.org> <87lflshxtq.fsf@osv.gnss.ru> <83mu68cbbb.fsf@gnu.org> <87h7wghxdz.fsf@osv.gnss.ru> <87eerkgey1.fsf@osv.gnss.ru> <112aecd7-8165-6cae-ef69-08d14d843841@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125302"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, andreas.roehler@online.de, emacs-devel@gnu.org, kfogel@red-bean.com, homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, Eli Zaretskii To: Stefan Kangas , Dmitry Gutov , Sergey Organov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 17 01:15:52 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 1ja623-000WTr-B0 for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 01:15:51 +0200 Original-Received: from localhost ([::1]:52598 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ja622-0004B8-Dp for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 19:15:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51006) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ja61P-0003fR-0Q for emacs-devel@gnu.org; Sat, 16 May 2020 19:15:11 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:55554) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ja61L-0007Do-FU; Sat, 16 May 2020 19:15:10 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04GNCvjU155084; Sat, 16 May 2020 23:15:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=4eozUjxyPV8csusUyF0dyGGw7uy4dK7BR5BUNESbM+g=; b=vqku61CgHOZaQf0S2+dSZl0JVxhlyFlHLpykX9u10lmWv7ytoDaITHZ2ZcYMVhkcs8fR Yxz8SRWjDpKCB4NgMaE0aRltdazcZyJhWxSdBBGA2eYj/d0B3qzzIC4DBSH5u+XZFs3U fIck1zGS54sUKxkTbeaoiD07+rJUn/fKE5++8mQHeVAk4wUOsi3fCzlEPKvyKIcOryiG ZVjY6czQryeCOQX2v62gUe3rDAybQVzzTifRedeaaYVIqp0H8GqLdfqoPEgnKbOR2G2r PdOBMNHCU91zWsx20OUia8DZ7ICZ6Zwtaz0QDCufp7YmX6gKC6mwY4YsbjgK8JQmnVRs Dw== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 3127kqsw9e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 16 May 2020 23:14:59 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04GNCnqO192886; Sat, 16 May 2020 23:12:59 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 312801w88s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 16 May 2020 23:12:59 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 04GNCtLl029751; Sat, 16 May 2020 23:12:55 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9623 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 suspectscore=1 malwarescore=0 mlxscore=0 adultscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005160211 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9623 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 clxscore=1011 priorityscore=1501 mlxscore=0 impostorscore=0 suspectscore=1 mlxlogscore=999 malwarescore=0 cotscore=-2147483648 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005160211 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/16 19:15:02 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, 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:250534 Archived-At: > > I agree that the prompts could be positioned better, > > and the result could be better readability. After all, > > if one uses the minibuffer a lot, isn't it a shame > > that it resides somewhere down below, and uses > > the same font as the rest of Emacs? >=20 > I personally think it's a very good idea. > In combination with that, simple changes like > giving it a border or a different background,=20 ^^^^^^ ^^^^^^^^^^ > would also help make it more visible. FWIW, I use a separate minibuffer frame, which extends across the bottom of the screen (by default - size & position configurable). I took this idea from Epoch back in the mid-90s. The fact that Emacs doesn't provide this as an option out of the box, I've always thought is too bad. (Epoch had other UI innovations, but that's the one I missed most when I went back to GNU Emacs.) As a separate frame, `minibuffer-frame-alist' applies, which includes its own default font (size, color) and background color. And as a frame, it has a border. (By default, the text is larger, and red.) Wrt positioning, one option is for moving the frame so it's positioned near point whenever the minibuffer is activated: 1on1-move-minibuffer-frame-near-point is a variable defined in `oneonone.el'. Its value is nil Documentation: Whether to move `1on1-minibuffer-frame' near point, and just where. * nil means do not move it. =20 * A single whole number, Y, means offset `top' by Y pixels from point. The `left' frame position is unchanged. As always, positive is down (below point), negative is up (above point). * A cons of two whole numbers, (X . Y), means offset `left' by X and `top' by Y pixels from point. For example, (-200 . 30) moves the top left frame corner 200 pixels to the left and 30 pixels below point. This option has no effect if `1on1-minibuffer-frame' is nil. Personally, I prefer the default behavior, of remaining at the bottom of the screen. In particular, that way it doesn't interfere with any Emacs content, anywhere. > One frequent annoyance for me in more "modern" software > is that the popups hide the thing they are about. Exactly - see previous paragraph. But I can understand that, at least for some simple interactions, some users like it. That's also a problem in general for any popup frame, whether for completions, info/help, whatever. Some DWIM can be applied, but the problem is inherent: how to know just what is the most noticeable and near the previous focus of attention, and simultaneously avoids obscuring the info the user currently cares about. Beyond letting users configure such behavior to some extent, and giving some programmed positioning a bit of "intelligence", giving users quick, keyboard, ways to move frames around on the fly can help. > so maybe the top positioning is a better default than > in the center. Top positioning has either the same problem as near point (your annoyance: obscuring info) or the same problem as bottom-positioning. With my setup, other frames can be automatically resized to fit their content, by default, in which case they never overlap the minibuffer frame when it stays put (e.g. at screen bottom). (Auto-fitting of frames can take a stay-put standalone minibuffer frame into account, in effect reducing the available screen space to exclude it.) The problem with a minibuffer that stays put is that it can be far from where your eye might currently be focused. That's more of a problem for the echo area than the minibuffer, perhaps, because for the latter you're anyway expecting to change your attention to it. For a newbie, I think that having a separate frame, with larger and more noticeable text takes care of the problem of not being aware of the minibuffer or echo-area messages - not knowing where to look or what's expected of you. In addition, with my setup the minibuffer frame background changes hue slightly (configurable) when it's active (and for each recursive minibuffer), and also when Isearch is active. That too helps draw attention to it, and lets you know the interaction status/expectation. https://www.emacswiki.org/emacs/Dedicated_Minibuffer_Frame Finally, although recursive editing is disabled by default, to protect the innocent, I think it's underappreciated as a feature. The main problem with it is, once again, not being aware that you're in a recursive edit - which interaction level you're on. To help with that I have library `rec-edit.el'. It highlights the mode-line [[...]] indication, to make it clear when you're in a recursive edit, and what level it is. https://www.emacswiki.org/emacs/RecursiveEdit#rec-edit.el