From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#40915: [PATCH] Make leaving Info-summary more intuitive Date: Tue, 28 Apr 2020 09:37:38 +0200 Message-ID: References: <83sggo2ik3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="81966"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40915@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 28 09:45:30 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 1jTKvp-000LCE-LP for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Apr 2020 09:45:29 +0200 Original-Received: from localhost ([::1]:44760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTKvo-0008Me-KJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Apr 2020 03:45:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43182) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTKqr-0005cy-6M for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 03:45:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTKoc-0001QT-Bq for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 03:40:20 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55423) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jTKob-0001QO-W9 for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 03:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jTKob-0006c5-Rz for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 03:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Apr 2020 07:38:01 +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.158805947725409 (code B ref 40915); Tue, 28 Apr 2020 07:38:01 +0000 Original-Received: (at 40915) by debbugs.gnu.org; 28 Apr 2020 07:37:57 +0000 Original-Received: from localhost ([127.0.0.1]:38736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTKoW-0006bl-MQ for submit@debbugs.gnu.org; Tue, 28 Apr 2020 03:37:56 -0400 Original-Received: from mail-yb1-f169.google.com ([209.85.219.169]:42172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTKoV-0006bY-0n for 40915@debbugs.gnu.org; Tue, 28 Apr 2020 03:37:55 -0400 Original-Received: by mail-yb1-f169.google.com with SMTP id i16so10910042ybq.9 for <40915@debbugs.gnu.org>; Tue, 28 Apr 2020 00:37:54 -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=LPium4AqdoyKbNTNRiZDQxZ2jsXNvGqAZmEDmfKBJ+Q=; b=r4DL0nOtqbTvKOJHy+t2VzxadmwLKQ61dfbFgkgnMqNJhSz5ch7l6OEuEyaKztlrtS I1b/vkl0pex6TR3/5VBRKdWlvAURRs5aaGlkDspWia3RdUQowMMVKOmo2AkROE+v10Ti KgtVZpBlsSS3Dx7jPfN0LMu0JjE/a4YhP9JOtVVtFXyw23IiJzWe7/YnVtkofSQmMdh0 rUdNV+x73JcjWfn2shEw5mJysmDG2fVJGCziB9q6sTppBvFGLl+rWhx57E+9Mzd2MLRs akdDCtaaOYRHQ8/v9rbu/4K4fBFXqpRzr4Xmx4+TEQm3Q1gh2VrnN0PxDL47WYN1QfCf pLGA== X-Gm-Message-State: AGi0PuaaddglKrDXN12CXMpnsOKCKzFjqgRj5PEw2sg8lKzkwUq1iTEy 4k4UFiODLTk/ae0Rppc7+tKmtPN9IR6tUlXeWf3SUJHgrqc= X-Google-Smtp-Source: APiQypJVnXtkv5UqBuINiha3ZbGiDPaFyz2owOFfKA9Q3xcOkbmG9bMOSMjC8iHlv1rvKwkm37De0jYj5ZeLHvEADH8= X-Received: by 2002:a25:e907:: with SMTP id n7mr41283591ybd.85.1588059469412; Tue, 28 Apr 2020 00:37:49 -0700 (PDT) In-Reply-To: <83sggo2ik3.fsf@gnu.org> 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:179202 Archived-At: Eli Zaretskii writes: > I'm not sure I understand the expected result. The help buffer > displayed when you press '?' says: > > q Quit Info: reselect previously selected buffer. > > So it seems Info behaves as documented? The way to exit the help > screen and return to the Info manual is by repeatedly pressing SPC > until you wind up in the original Info buffer. Sure, the result is formally correct. It's just counter-intuitive. Normally when I say 'q' in the "*Help*" buffer, I bury it. But here, 'q' buries two buffers. > 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. 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. Best regards, Stefan Kangas