From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Improving describe-mode and discoverability Date: Thu, 23 Jun 2016 15:07:49 -0700 (PDT) Message-ID: References: <576C2A6C.3090908@gmail.com> <576C59AF.7080902@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1466719700 1011 80.91.229.3 (23 Jun 2016 22:08:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jun 2016 22:08:20 +0000 (UTC) To: =?utf-8?B?Q2zDqW1lbnQgUGl0LS1DbGF1ZGVs?= , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 24 00:08:06 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bGCn7-0000Yf-Rf for ged-emacs-devel@m.gmane.org; Fri, 24 Jun 2016 00:08:05 +0200 Original-Received: from localhost ([::1]:39647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGCn7-000758-0V for ged-emacs-devel@m.gmane.org; Thu, 23 Jun 2016 18:08:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGCn1-0006yW-6f for emacs-devel@gnu.org; Thu, 23 Jun 2016 18:08:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGCmw-00070O-Ud for emacs-devel@gnu.org; Thu, 23 Jun 2016 18:07:58 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:21299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGCmw-0006yc-N2 for emacs-devel@gnu.org; Thu, 23 Jun 2016 18:07:54 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5NM7pK4018975 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jun 2016 22:07:51 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u5NM7oIw021086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jun 2016 22:07:51 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u5NM7nnN009286; Thu, 23 Jun 2016 22:07:50 GMT In-Reply-To: <576C59AF.7080902@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:204710 Archived-At: > my proposal is to keep displaying mode docstrings. However, when a > mode docstring includes a \\{mode-map} (which seems to be a very common > thing to do), my proposal is to enhance the rendering of that \\{mode-map= } > construct to print an actually useful table. So you are proposing a change to how \\{mode-map} is handled - a replacement for the current behavior. Personally, I don't have a problem with the way it is handled now. I think that what you should do perhaps is to propose a new (different) such construct, which produces the key binding plus a one-line description instead of the key binding plus the command. In that case, I probably wouldn't use that new construct, but maybe others will. To me, the key and the command name are the most important. And the command names are linked to the full doc for the commands. (And in my own code, keys between `..' are also so linked.) > Of course, we could put this behaviour behind a flag. If it is a new construct instead of a replacement for \\{...} then there is no need for a flag.