From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Proposal for an improved `help-for-help' Date: Thu, 8 Apr 2021 08:27:02 -0700 Message-ID: References: <838s7hxqkr.fsf@gnu.org> <83mtua9isw.fsf@gnu.org> <83zgy8997y.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="10652"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 08 17:29:14 2021 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 1lUWan-0002fY-4W for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 17:29:13 +0200 Original-Received: from localhost ([::1]:49304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUWam-0007Qs-76 for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 11:29:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60712) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUWYk-00068o-Ty for emacs-devel@gnu.org; Thu, 08 Apr 2021 11:27:06 -0400 Original-Received: from mail-pf1-f170.google.com ([209.85.210.170]:46912) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lUWYj-00048r-CY; Thu, 08 Apr 2021 11:27:06 -0400 Original-Received: by mail-pf1-f170.google.com with SMTP id d124so2046755pfa.13; Thu, 08 Apr 2021 08:27:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=P2ZWTQlRxRK/VGTqqzb5/vgn/1mih1QrCCfY6dqa6CA=; b=AUwOJAGNJUYk0KpEcCY39mCEv42DhsHw3nu9TN/+TB9fNtDPiXYU95dwixXh/N7kwU Q1y5Ob+BLSsq2dIwbzvGkB8xib4m1HLzduyfxZSOaUADTHAWUrASvtaO9LEFA+zpgqF7 81cUy9J3wP9zAvH+g1dy/1hFj6KVQYXKnhk+nyiykGhk9J/au4VDWtrw4InPYqhle0IQ QJjHFxuYQSK4BXsw4dA1rJWiQfWQ+zmDPYIevit6PfNnO3/eFZudgkVycFwIOzs4YrSD b9uLhuo2T0BFNJx3gt8k5U/KjS9IKEh7Ty1OL09RjMVcXiQZ7+e5XbEvHsHhiqM7sZhw BRYw== X-Gm-Message-State: AOAM533y98ZxHnLNAD5DTQrwHBk8M1F6zHNIYFHwQZ3t3ExNtvmczvZl zfs1ov47CdIW1fv12GKsXQeDTVkZP24jtTdE+Gv1v+D/ X-Google-Smtp-Source: ABdhPJw5mR6gGdRyFP7CNJDy2DxiNn+9jaMyrMJIqLZT0PC6WS6vf4JbPYl5Z+PFfil4w24fKe/aO1+j6L5ik/a7Mf8= X-Received: by 2002:a65:4046:: with SMTP id h6mr8371036pgp.345.1617895623193; Thu, 08 Apr 2021 08:27:03 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 8 Apr 2021 08:27:02 -0700 In-Reply-To: <83zgy8997y.fsf@gnu.org> Received-SPF: pass client-ip=209.85.210.170; envelope-from=stefankangas@gmail.com; helo=mail-pf1-f170.google.com 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.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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:267622 Archived-At: Eli Zaretskii writes: >> >> + '(("Getting Help" >> > >> > I'd use something like "Describe and Find Commands, Keys, Functions". >> >> That's fine, but it is a bit long. > > Why is it a problem to be long? Keeping it short is in line with common recommendations in UIX design, which strongly favours simplicity, in order not to burden the mental bandwidth of users with irrelevant detail. Having a long headline here weighs the entire screen down, makes it harder to read and more intimidating. > Both "getting Help" and "Basic Help" is too general to be useful, IMO. Things will be clear from context. No one risks being confused by "Basic Help" or "Getting Help". The main purpose is to give a quick overview of the most commonly used commands. "Most Commonly Used Help Commands" is more accurate but too pedantic. >> Do we need to speak of "top-level menu", or can we get away with the >> shorter "Show all installed manuals"? > > But "show a manual" could be interpreted as displaying the contents of > that manual, in which case "show all manuals" makes no sense. I don't see how anyone could take "show all manuals" as meaning anything other than some kind of _list_ of manuals. How else would they be shown? And if a user runs the command they will immediately see that they can indeed also select a manual. So I think the risk of confusion here is low. That said, this is not something I feel is very important. We can go with your preference if you feel strongly about it. > I think I explained elsewhere why I think using "Info" in that screen > is not the best idea: newbies won't know what that means. You did explain it, yes, but in a different context. The argument is different here as there is a mnemonic involved. The other drawback I see is that we miss an opportunity to educate our users in the existence of Info. That said, I'm fine with leaving it out, as long as we are conscious of the considerations involved.