From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#6755: 24.0.50; Customize buffer is too wide. Put doc string on separate line. Date: Mon, 16 Sep 2019 11:54:27 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007aa3e70592acc8d7" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="216376"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen To: 6755@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 16 18:13: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 1i9tco-000uBw-JQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Sep 2019 18:13:14 +0200 Original-Received: from localhost ([::1]:36568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9tcl-0006jf-Lz for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Sep 2019 12:13:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55751) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9sPC-0001aV-H8 for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 10:55:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i9sPA-0003n6-Rb for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 10:55:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41954) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i9sPA-0003mp-IZ for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 10:55:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i9sP7-00082w-QS for bug-gnu-emacs@gnu.org; Mon, 16 Sep 2019 10:55:04 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Sep 2019 14:55: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.156864568930902 (code B ref 6755); Mon, 16 Sep 2019 14:55:01 +0000 Original-Received: (at 6755) by debbugs.gnu.org; 16 Sep 2019 14:54:49 +0000 Original-Received: from localhost ([127.0.0.1]:50775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9sOt-00082K-1U for submit@debbugs.gnu.org; Mon, 16 Sep 2019 10:54:48 -0400 Original-Received: from mail-lj1-f169.google.com ([209.85.208.169]:38775) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9sOr-000823-Ad for 6755@debbugs.gnu.org; Mon, 16 Sep 2019 10:54:45 -0400 Original-Received: by mail-lj1-f169.google.com with SMTP id y23so225866ljn.5 for <6755@debbugs.gnu.org>; Mon, 16 Sep 2019 07:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=VFKblkGgAdc8lrFZd0EThzwVsszSnXN03+BwvIsGGEc=; b=NZKBCGNqFO6OW7H/MG0YyEwop/SGkPD5fX1xeNU/atzRxhKISFgacqxy1gNS0Ml6ty fU7G4o6hPGyEp4xyqy3NQLfoacpqK8CO/VSVgHsXId/3Ygc8sHBcrpXsZBAuPmIdvK5i uCccftwKwGUEWwtNRIk/+7HaHl6h44Ex5Hij3nbjNo4TcT/CQIINOo8P717TnR3Dc5rg SqbDCCUyrQQx5hciXvCwblex9QtlExE2rU2O0nQM+nmDLqnmlUmBdUvc97X/+8faKHuX yk758VlvChAPnNub0rr48HgKWBT+3GhT5hRpZIdwxRGTvKtq2nbtIei8lTN/rhCAyeHQ vDEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VFKblkGgAdc8lrFZd0EThzwVsszSnXN03+BwvIsGGEc=; b=I80S1ak+Su8DBScr+MOItTrC4tfW45W5duDoDGVLOIZY5eKt4gHZE2OwGQzj66mpUW ++K5sdrHZ1Gp3YHAfKr7fZscsmrdQVww5BG5K9io9fsHNWqvNgRqUXVi+b/FsBFLCCc1 Y/2qxPm3y1VIfl5cXMN4FaYFrY8HJNKyJNjt0uxnPCm1+tnUSt+Y7WpEWvmWjcGgy060 NadOd4JZGyf6CPyFP6d7U0b/5/RNK+FNZYOvDgyFfORwLrcRGDxxiK17yWmhfkpkdOmY LbeRdK2ZhxW/+JIGFsN/8HBBLZTOe/XaQndAO/cnkjgRD8Uj5LP+KKvZ3hz178FZGYno dBzQ== X-Gm-Message-State: APjAAAVChVY4o3nRI/gGzjj/zCo8/PbjdQmjG34NmI2xl1BFs+bThdOx EMczUcznk+i0SaFo8oP4WIpzAgTyKQboJi98T1iLOQE2dfg= X-Google-Smtp-Source: APXvYqwUvtvG+yDnrO6X3oxJLiu5Mei9HUUmbVqnczecXDtvoIkWacxg+BbMsP59HNkeEyCAUDfqTSuGn5rQY8XGLDE= X-Received: by 2002:a2e:8744:: with SMTP id q4mr30668ljj.77.1568645679062; Mon, 16 Sep 2019 07:54:39 -0700 (PDT) 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:166561 Archived-At: --0000000000007aa3e70592acc8d7 Content-Type: text/plain; charset="UTF-8" Lars Magne Ingebrigtsen writes: > "Drew Adams" writes: > >>> So now the question is how the text should be formatted. Perhaps >>> folding it after inserting it is the right way? Anybody know >>> how? :-) >>> (I mean, without breaking the widget machinery...) >> >> Not sure if this is what you are asking, but just make sure it starts >> on a new line. That would take care of this problem and similar. >> IOW, start with a newline. > > Starting with a newline didn't look very nice. Most of the option > values are short, and moving them away from the button made the > interface less understandable. > > I think the right solution is to output the string where it is now, but > to fill it if it's too long. I have an idea on how to implement the solution proposed by Lars. I think filling after inserting the :tag property of a widget would be enough. But I wanted to ask first, do we really want to make this behavior unconditional in the widget library? Or would it be better to provide it as an option, for customize (and possibly other clients) to set it? Best regards, Mauro. --0000000000007aa3e70592acc8d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> "Drew Adams" <<= a href=3D"mailto:drew.adams@oracle.com">drew.adams@oracle.com> write= s:
>
>>> So now the question is how the text should be fo= rmatted.=C2=A0 Perhaps
>>> folding it after inserting it is the= right way?=C2=A0 Anybody know
>>> how? =C2=A0:-)
>>&= gt; (I mean, without breaking the widget machinery...)
>>
>&= gt; Not sure if this is what you are asking, but just make sure it starts>> on a new line.=C2=A0 That would take care of this problem and si= milar.
>> IOW, start with a newline.
>
> Starting with= a newline didn't look very nice.=C2=A0 Most of the option
> valu= es are short, and moving them away from the button made the
> interfa= ce less understandable.
>
> I think the right solution is to ou= tput the string where it is now, but
> to fill it if it's too lon= g.

I have an idea on how to implement the solution proposed by Lars.=
I think filling after inserting the :tag property of a widget would be<= br>enough.

But I wanted to ask first, do we really want to make this= behavior
unconditional in the widget library?=C2=A0 Or would it be bett= er to provide
it as an option, for customize (and possibly other clients= ) to set it?

Best regards,
Mauro.
--0000000000007aa3e70592acc8d7--