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: Character literals for Unicode (control) characters Date: Sun, 6 Mar 2016 08:55:48 -0800 (PST) Message-ID: <2840a8a5-828b-4a3d-99c0-448ad76d0746@default> References: <87r3fsjenn.fsf@gnus.org> <56D8623F.6060806@cs.ucla.edu> <56DB0AB5.7000106@gmail.com> <56DB138D.6020605@cs.ucla.edu> <56DB1D06.7020401@gmail.com> <83ziucx02l.fsf@gnu.org> <87h9gjmwsy.fsf@fastmail.fm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1457283382 31603 80.91.229.3 (6 Mar 2016 16:56:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Mar 2016 16:56:22 +0000 (UTC) Cc: eggert@cs.ucla.edu, =?iso-8859-1?B?Q2zpbWVudCBQaXQtLUNsYXVkZWw=?= , emacs-devel@gnu.org To: Joost Kremers , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 06 17:56:09 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 1acbyS-0004YB-To for ged-emacs-devel@m.gmane.org; Sun, 06 Mar 2016 17:56:09 +0100 Original-Received: from localhost ([::1]:51190 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acbyS-0001Rd-96 for ged-emacs-devel@m.gmane.org; Sun, 06 Mar 2016 11:56:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acbyN-0001Ni-Sa for emacs-devel@gnu.org; Sun, 06 Mar 2016 11:56:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acbyM-0007AD-Ss for emacs-devel@gnu.org; Sun, 06 Mar 2016 11:56:03 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:45644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acbyJ-000795-1q; Sun, 06 Mar 2016 11:55:59 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u26GtpgC019002 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 6 Mar 2016 16:55:52 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u26GtpfH022155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 6 Mar 2016 16:55:51 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u26Gtod0012645; Sun, 6 Mar 2016 16:55:50 GMT In-Reply-To: <87h9gjmwsy.fsf@fastmail.fm> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201000 Archived-At: > > so M-q is just not up to the job, and shouldn't be used. >=20 > But there's no real alternative, is there? IOW, you might as well > use M-q, because if you use something like \\[my-function], you > never know if that'll display as a short key binding, a long key=20 > binding, or as `M-x my-function', which can actually be very long. You never know for sure. But usually you know what to _expect_. Often a doc string with \\[...] is for a command that is used in a given context, where you can have a good idea whether the command is likely to be bound to a key or not. But of course, it could be bound to another key than the default one, and the bound key could have a much longer description because of prefix keys. So no, there is no silver bullet here. You just need to use good, common sense, aiming for the most typical, expected, default use case/context. The reason for conventional doc strings, including a maximum line length, is for user convenience. This includes simply reading but also things like window and frame fitting to the buffer content (line lengths and number of lines). As with all attempts to help users at coding time, we can only either (1) try to address the most common expected use cases or (2) provide users a way to customize the behavior. For doc strings, this comes down mainly to #1. > (I guess the best way would be to custom-wrap doc strings before > displaying them, after constructs such as \\[...] have been > resolved.) It's not just about wrapping. You need to look at rendered doc strings to see what the effect is on embedded TAB chars also, e.g., to try to align text that is essentially tabular, such as key descriptions. It's really not a big deal to use `C-M-x' to reevaluate, and then use `C-h f' to see what the doc string looks like when rendered. And yes, you might need to first put the current buffer in the right mode, so it picks up the right keymaps. You might even need to set the font so that it displays each of the chars in the doc string correctly.