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: Sun, 22 Sep 2019 15:56:04 -0700 (PDT) Message-ID: <9fb66923-b2ea-4df9-8d2b-2ecced6b302e@default> References: <<>> <<<871rwgt32h.fsf@gnus.org>>> <<>> <<<87tv99loqr.fsf@gnus.org>>> <<>> <<<780890ec-8e55-4829-942f-b9daf3513908@default>>> <<>> <<>> <<<837e60qt1f.fsf@gnu.org>>> <<8a2c1a21-5498-4e5d-a28c-88810ad7aa10@default>> <<83v9tkp8ui.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="206827"; mail-complaints-to="usenet@blaine.gmane.org" Cc: larsi@gnus.org, maurooaranda@gmail.com, 6755@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 23 00:57:15 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 1iCAn1-000rdQ-SW for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Sep 2019 00:57:12 +0200 Original-Received: from localhost ([::1]:51260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iCAn0-0000YL-1b for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Sep 2019 18:57:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41517) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iCAmt-0000Y1-Az for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2019 18:57:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iCAms-0001u0-5F for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2019 18:57:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54065) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iCAmr-0001tm-Ty for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2019 18:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iCAmr-000337-P8 for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2019 18:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Sep 2019 22:57:01 +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.156919298011670 (code B ref 6755); Sun, 22 Sep 2019 22:57:01 +0000 Original-Received: (at 6755) by debbugs.gnu.org; 22 Sep 2019 22:56:20 +0000 Original-Received: from localhost ([127.0.0.1]:34653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iCAmB-00032A-Nn for submit@debbugs.gnu.org; Sun, 22 Sep 2019 18:56:20 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:48452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iCAm9-00031s-6n for 6755@debbugs.gnu.org; Sun, 22 Sep 2019 18:56:18 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8MMsXnI190090; Sun, 22 Sep 2019 22:56:08 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=NZKNZRBAhqgyM8ukRSjzPabZHZ7wKnWbfbknRhCkv7o=; b=saSqgeLfZ/xakUirClPNhGft3GjMWDQLcSAY24Fqll6UBIambabZphgOqWaSIYeU8rmH p76mZc9djBM3q5m0uTG6p5v9smhoyJJ13pxySqzUeecST9Tbf2sCyGrECWiFDaZNfSgn 5XHev6yUJCT6/L3f32QuaCq5m2eGObPp8SfoXxcjx6OJHnmDhXqZ84VfI6/tnaHPmm7s vCtL9rUtDPy2kQgsLFCVIztla08HEfOK+XNz1Mh/c40IbrIyiPoy5MPI/AYoPTp5aDKA NnRSjSgDyGxjHYNCUOUZX5XOAtUX/XiOhlkFcnMAGFpDbnPYmV6xfmKUDyltKVqF5JyU oA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2v5cgqkkhn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 22 Sep 2019 22:56:08 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8MMrS8k059701; Sun, 22 Sep 2019 22:56:08 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 2v590j6g6h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 22 Sep 2019 22:56:08 +0000 Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x8MMu5CL014448; Sun, 22 Sep 2019 22:56:06 GMT In-Reply-To: <<83v9tkp8ui.fsf@gnu.org>> 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=9388 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-1909220244 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9388 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-1909220244 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:166951 Archived-At: > > It's about :tag lines. The screenshots and the > > defcustom provided make that clear, I believe. > > > > > Therefore, it makes no sense at all to start that text on a new line. > > > > Why do you think that follows logically? I don't. > > > > This bug report / enhancement request is precisely to > > put that text on its own line. >=20 > And that's exactly what makes no sense:=20 I disagree that it makes no sense. In fact I think it makes a lot of sense. Hence this enhancement request. > we would be artificially separating the value menu > button from the description of the current value. Look at the screenshots. I don't see why anyone would find it odd, let alone "make no sense") to show the doc for the current value just below button, on the next line. But there's no accounting for tastes, as they say. You have yours; I have mine. To me it's artificial to show the :tag text to the right of the button, especially when it is more than a few chars long. > So if you insist on doing this, I object to this proposal. That's what this enhancement request is about. Does that count as "insistence"? > > At least do so when the text would go past the conventional limit > > (70 chars or whatever) when placed after Customize constructs > > (boilerplate text, buttons, etc.). >=20 > No. It is up to the Lisp programmers to make sure the text is short > enough to not cause this. Exactly like with doc strings. Not the same at all. Why? because Customize sticks a variable amount of stuff before the :tag text. 1. You know where a doc string will be displayed, and it always starts in column 1. 2. But :tag text depends on the stuff that Customize adds to the buffer before it. In the case of the `Value Menu' button, that stuff includes the option (or face) name, which varies from option to option. That means that the longer the option name, the less room for the :tag string. There should be no such relation between their lengths. (Why would there be?) The :tag in the screenshot is 55 chars. Given the option name of 34 chars, plus the colon, `Value Menu' button, and spaces Customize adds, there is only room for a :tag of 30 chars. 3. Imagine if we did something similar for `C-h v': Put, say, the first line of the doc string (or some other descriptive text, if you don't like that hypothetical) to the right of the var name. That wouldn't make much sense, would it? Why? Because a long variable name would mean you'd have to use a short description. There's no reason to impose any relation between those lengths. Doing so "makes no sense", to me. =20 > > The problem is :tag lines. They should be moved to > > their own line - at least when combining them with > > widget artifacts makes the resulting displayed content > > too wide. >=20 > Disagree.