From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#40915: [PATCH] Make leaving Info-summary more intuitive Date: Tue, 28 Apr 2020 10:57:17 +0300 Message-ID: <83ftco2gbm.fsf@gnu.org> References: <83sggo2ik3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="115916"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40915@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 28 11:22:28 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jTMRg-000U2R-9Q for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Apr 2020 11:22:28 +0200 Original-Received: from localhost ([::1]:48364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTMRf-0003ao-1o for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Apr 2020 05:22:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59682) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTMOV-0001sm-Go for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 05:21:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTMKz-0004ox-UM for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 05:19:11 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55449) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jTL7y-0005XM-7g for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 03:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jTL7y-00076W-6b for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 03:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 07:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40915 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 40915-submit@debbugs.gnu.org id=B40915.158806066827286 (code B ref 40915); Tue, 28 Apr 2020 07:58:02 +0000 Original-Received: (at 40915) by debbugs.gnu.org; 28 Apr 2020 07:57:48 +0000 Original-Received: from localhost ([127.0.0.1]:38762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTL7j-000762-P2 for submit@debbugs.gnu.org; Tue, 28 Apr 2020 03:57:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTL7i-00075p-3P for 40915@debbugs.gnu.org; Tue, 28 Apr 2020 03:57:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53387) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTL7c-0005CS-Cm; Tue, 28 Apr 2020 03:57:40 -0400 Original-Received: from [176.228.60.248] (port=1727 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jTL7a-0000xx-AT; Tue, 28 Apr 2020 03:57:39 -0400 In-Reply-To: (message from Stefan Kangas on Tue, 28 Apr 2020 09:37:38 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179208 Archived-At: > From: Stefan Kangas > Date: Tue, 28 Apr 2020 09:37:38 +0200 > Cc: 40915@debbugs.gnu.org > > > I could understand that we'd like to have a single key to quit the > > help screen, perhaps even when 'q' is pressed (which would be a change > > in behavior), but even then it is IMO wrong to completely remove the > > pushing onto unread-command-events, because this command is set such > > that you could read about a key and execute it while still in the help > > screen. IOW, the fact that the key you pres is generally executed > > after exiting the help screen is an important feature: it avoids the > > need to remember the key you found in *Help* and retype it after you > > are back in the Info buffer. > > Thanks for explaining the motivation behind that feature. > > I'm fine with doing a less invasive change: treat 'q' as a special > case in Info-summary. Many users are hardwired to press 'q' to make a > "*Help*" buffer go away. > > However, there is an inconsistency between modes; in view-mode and > special-mode, '?' is bound to describe-major-mode. What is describe-major-mode? Did you mean describe-mode? > Would it be worth it to be more consistent? In other words, doing one of: > > (a) make 'Info-summary' into a general help command and use it in more > places, or > (b) deprecate 'Info-summary' in favour of 'describe-mode'. > > It seems to me that _if_ we think the 'Info-summary' behaviour is > useful, we would want to ensure more modes can benefit from it. Or, > to put it another way, I don't see why it would be uniquely useful to > Info-mode -- it should be useful either in many more modes or nowhere. > I haven't formed a strong opinion on this, but it would be interesting > to hear what people think. Info mode is special: it is used to read the manual, including the Emacs manual and the manual for the Info system itself. IOW, we have a kind-of "bootstrapping" problem here: we need to teach how to use the system/mode by using that same system/mode. describe-mode shows the same text for Info, but it also shows much more, which for the new user is pure clutter and source of confusion. It also pops up a new window, which is another problem: the user may not know at that point how to work with more than one window. This is not an important consideration for the general Help commands, but it is for Info. So I think the case of Info _is_ special, and consistency considerations are much less important here than an attempt to present a simple and effective help buffer to users who may not yet know any "advanced" features.