From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#6755: 24.0.50; Customize buffer is too wide. Put doc string on separate line. Date: Sat, 21 Sep 2019 22:36:23 +0000 (UTC) Message-ID: References: <871rwgt32h.fsf@gnus.org> <87tv99loqr.fsf@gnus.org> <780890ec-8e55-4829-942f-b9daf3513908@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="98414"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen , 6755@debbugs.gnu.org To: Mauro Aranda Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 22 00:37:12 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iBo07-000PT0-A8 for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Sep 2019 00:37:11 +0200 Original-Received: from localhost ([::1]:44060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBo06-0004uM-7S for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Sep 2019 18:37:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49400) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBnzz-0004uA-Tl for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 18:37:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iBnzy-0004Zx-KP for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 18:37:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52701) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iBnzy-0004Zt-FO for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 18:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iBnzy-0002sd-9X for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 18:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Sep 2019 22:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6755 X-GNU-PR-Package: emacs Original-Received: via spool by 6755-submit@debbugs.gnu.org id=B6755.156910539611025 (code B ref 6755); Sat, 21 Sep 2019 22:37:02 +0000 Original-Received: (at 6755) by debbugs.gnu.org; 21 Sep 2019 22:36:36 +0000 Original-Received: from localhost ([127.0.0.1]:33289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBnzX-0002ri-FD for submit@debbugs.gnu.org; Sat, 21 Sep 2019 18:36:35 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:37160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBnzV-0002rR-N0 for 6755@debbugs.gnu.org; Sat, 21 Sep 2019 18:36:34 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8LMYu3p087320; Sat, 21 Sep 2019 22:36:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=afLCyCIr3dUf995+TC2q5XzQNVS1iVmJlyhTR1R2KPA=; b=iFJiEYklQp7RpubyTM60DiwdsR/bhB2Occhk7C11/rm4xHadvLeSBVOnUeAl8sHVDyWc 5v/d9g4erD18uW3VTtsYeFiSJvpN52dtgb3XWrgiyx2ZKTz7koqlKMPV4G9s/jpOElw/ EA6eYLRYbyTmo26VyAv2cMpO4Pgt5Ml7ObuncQGQK8rbCODvCsa3DsBOULRdIhacRHu6 IzzTHsRbnu0ifCommjjHs4IBAIVHHMXc5lLb/R6hWM/UVv5+eUxsqZqPk0DxMolqmc1u zNnhVVmdopq4stsijgan3jyx7Bll4y3+YhetqkixGMrSXN9xOiZOFnRhYlm7hyS2e+YE qQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2v5btphug6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 21 Sep 2019 22:36:27 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8LMWkVx062050; Sat, 21 Sep 2019 22:36:27 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2v5b75uq6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 21 Sep 2019 22:36:26 +0000 Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x8LMaOqQ009603; Sat, 21 Sep 2019 22:36:24 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4888.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9387 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909210251 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9387 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909210251 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:166887 Archived-At: >> FWIW, this enhancement request (or bug report) >> did not ask for the doc string to be filled.=C2=A0 It >> asked for it to be moved to its own line.=C2=A0 Those >> are not at all the same thing. > > I see.=C2=A0 When I read the bug report, I thought it was just a suggesti= on to > fix the problem of the customize buffer getting too wide.=C2=A0 Perhaps I= was > wrong. The bug report just asks that the first line of a doc string be put on its own line, and likewise for :tag lines. >> But that's not a fulfillment of _this_ enhancement >> request (or bug fix).=C2=A0 What's needed for this report >> is to move the doc string to its own line.=C2=A0 Can that >> please be done, or at least considered? > > May I ask you then, what is the :format option missing for this situation= ? > > For example, if one of the const types of the defcustom you provided > had the following format-string: > (const=20 >=C2=A0:tag >=C2=A0"Update `*Completions*' incrementally if already displayed" >=C2=A0:format "\n%t\n%d" >=C2=A0t) > > then the tag would go to its own line.=C2=A0 And that avoids making the > customize buffer too wide. Maybe so, but defcustom writers should not need to worry about that. See above. Imagine if when you do `C-h f' the *Help* buffer stuffed a bunch of stuff in front of the first docstring line. That's just obstruction; it just gets in the way. And it's not necessary. Customize should just assume that a docstring has the honor of being shown starting in column 1. And the same for a :tag line. >> And if you _also_ want to consider filling the doc >> string (that should be a separate enhancement >> request), please do _not_ do so systematically.=C2=A0 Let >> users choose to do that (opt in), with a user option. > > I take all the points you raised about the filling option, but I think > it might be better to at least postpone that discussion. Filling is not part of this enhancement request (bug report). Please don't fill docstrings or :tag lines, at least not for this bug. If someone wants to consider doing that, and open a discussion about it, please file a separate enhancement request. When I spoke of authors carefully "formatting" doc strings I meant that they manually adjust the text and its line lengths, to fit the convention. That includes, e.g., taking `\\[...]', `\\<...>' and `\\{...}' into account. Whatever an author implements as the source for a doc string should be respected. Likewise, for a :tag line. If an author wants to use `:format' in this context she can do so. She should not be forced to do that systematically, just to get a docstring or :tag line to start in column 1, i.e., on its own line.