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: Sat, 21 Sep 2019 07:53:53 -0300 Message-ID: References: <871rwgt32h.fsf@gnus.org> <87tv99loqr.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000061469205930e016d" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="258444"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 6755@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 21 12:55:25 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 1iBd2y-00156r-CG for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Sep 2019 12:55:24 +0200 Original-Received: from localhost ([::1]:40836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBd2w-0002tR-ML for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Sep 2019 06:55:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48124) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iBd2e-0002tJ-3A for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 06:55:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iBd2c-000141-MI for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 06:55:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50422) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iBd2c-00013x-E0 for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 06:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iBd2c-0004oS-A5 for bug-gnu-emacs@gnu.org; Sat, 21 Sep 2019 06:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Sep 2019 10:55: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.156906325418438 (code B ref 6755); Sat, 21 Sep 2019 10:55:02 +0000 Original-Received: (at 6755) by debbugs.gnu.org; 21 Sep 2019 10:54:14 +0000 Original-Received: from localhost ([127.0.0.1]:59242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBd1q-0004nK-EQ for submit@debbugs.gnu.org; Sat, 21 Sep 2019 06:54:14 -0400 Original-Received: from mail-lf1-f68.google.com ([209.85.167.68]:44247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iBd1n-0004n5-Nv for 6755@debbugs.gnu.org; Sat, 21 Sep 2019 06:54:12 -0400 Original-Received: by mail-lf1-f68.google.com with SMTP id q11so6750105lfc.11 for <6755@debbugs.gnu.org>; Sat, 21 Sep 2019 03:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=27xub3Lenowp4iBA5AD3iwUtpvwKwbByju/pALPTwTg=; b=T8I4G0WmI5UOkrCnEnLSl7w0KnjyTjNiPnD2mRa9U3E9hvSkC60eNuVh5383CcEKKK QwMvRejViFWoLK4KnNE9kbL4pxndZXGmrBBl6W95o81SSAf8XO8w2mG8L1I1Ralcvbka +yHCJnodiniCGCcloZvynj0jDTXT+mpGXZQ7r7miAjwoaFOtmZsIPo1w+6TQnC30R0QN d5F301vX3ang/GRnxJvfcErOsn2KCUV7WkYs12OUmLE4fXJo9tyxFlyR0EaqLm6RTsCW D1daY/5aYWZRAK2ZKP7z35uxeGSPWCy0Y8aEHlvCesQwLYmXfw997P8jGquD6pxMJRz4 37SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=27xub3Lenowp4iBA5AD3iwUtpvwKwbByju/pALPTwTg=; b=sovXjTbigUv8uu0cptM7FBhPNM22vIdpBX4hiXhZr7D5uzVMvkf/1ESe6peMii/Zzf 7uhLUGG8QuUov4/63RM6lxlNrG/3MU++53UBAt/qnUxSnqNvnvkLf5lijKrHsY7LKBpI VH0JL03VBDFq110hjcyckUSF8rNmjLLCePiO9fhlBnZ+e4ENd1ktuLpQT6DLKmgrr/k6 ukOB2CotfSAxRnYT3yWCYcl3yNGER9NglRdnQV7KdOhJlimHoGtwg+CFpof26MvK30UG axVb51d0cwHgNg338ZQYHXaC7P77c2F3H2VYAF2WBRkcEejc1ebNJOeYAIvXeKgCIBV9 5qMg== X-Gm-Message-State: APjAAAXxMnYEstvpaQH63CkypGIJ7BmfTXvWcio2BHzWapBpGzZvV3GB 2+ADJDUI8fVx2OHIDsBC2KubYz2CI/NC/qNRceo= X-Google-Smtp-Source: APXvYqwBkcXOPHoxJNkY2N2pUwBjX5JFyE3cLMicEa4qNJptqdoulqR76AImC6PhzLCq+inK2Kx8tDyA2lrBObQSnqE= X-Received: by 2002:ac2:4253:: with SMTP id m19mr11334462lfl.34.1569063245529; Sat, 21 Sep 2019 03:54:05 -0700 (PDT) In-Reply-To: <87tv99loqr.fsf@gnus.org> 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:166871 Archived-At: --00000000000061469205930e016d Content-Type: text/plain; charset="UTF-8" Hello Lars, Lars Ingebrigtsen writes: > Mauro Aranda writes: > >> diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el >> index 8a8bad9..0c392ff 100644 >> --- a/lisp/cus-edit.el >> +++ b/lisp/cus-edit.el >> @@ -4833,6 +4833,7 @@ custom--initialize-widget-variables >> (setq-local widget-push-button-suffix "") >> (setq-local widget-link-prefix "") >> (setq-local widget-link-suffix "")) >> + (setq-local widget-fill-tag-string t) >> (setq show-trailing-whitespace nil)) > > Hm... what is the interface here? You set this variable > buffer-locally... > > > [...] > >> + (princ (widget-get widget :value) (current-buffer)))) >> + (when widget-fill-tag-string >> + (save-restriction >> + (widen) >> + (fill-region opoint (point) nil t))))) > > And then fill all the widgets of this type in this buffer? But doesn't > that mean that it's impossible to have two widgets, one with filling and > one without, in the same buffer? As it stands now, yes, all widgets in customize would get its tag filled, unless a different :create function is provided for that widget. I didn't thought of the case of wanting one widget with its tag filled and another one with its tag not filled, in a customize buffer. I didn't see the need in that. When would that be a good thing? If it makes sense, a widget could have a :fill property set to t, for example, and in the code that calls the widget creation functions (e.g., widget-create), widget-fill-tag-string would be bound to t. This goes, of course, for all other users of the widget library. Best regards, Mauro. --00000000000061469205930e016d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Lars,

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Mauro Aranda &l= t;maurooaranda@gmail.com> = writes:
>
>> diff --git a/lisp/cus-edit.el b/lisp/cus-edit.e= l
>> index 8a8bad9..0c392ff 100644
>> --- a/lisp/cus-edit= .el
>> +++ b/lisp/cus-edit.el
>> @@ -4833,6 +4833,7 @@ cu= stom--initialize-widget-variables
>> =C2=A0 =C2=A0 =C2=A0(setq-loc= al widget-push-button-suffix "")
>> =C2=A0 =C2=A0 =C2=A0= (setq-local widget-link-prefix "")
>> =C2=A0 =C2=A0 =C2= =A0(setq-local widget-link-suffix ""))
>> + =C2=A0(setq-= local widget-fill-tag-string t)
>> =C2=A0 =C2=A0(setq show-trailin= g-whitespace nil))
>
> Hm... =C2=A0what is the interface here?= =C2=A0 You set this variable
> buffer-locally...
>
>
&= gt; [...]
>
>> + (princ (widget-get widget :value) (curre= nt-buffer))))
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0(when widget-fill-tag-string
>> + =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(save-restriction>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0(widen)
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(fill-region opoint (point) nil t))))= )
>
> And then fill all the widgets of this type in this buffer= ?=C2=A0 But doesn't
> that mean that it's impossible to have = two widgets, one with filling and
> one without, in the same buffer?<= br>
As it stands now, yes, all widgets in customize would get its tagfilled, unless a different :create function is provided for that
widget= .

I didn't thought of the case of wanting one widget with its ta= g filled
and another one with its tag not filled, in a customize buffer.= =C2=A0 I didn't
see the need in that.=C2=A0 When would that be a goo= d thing?

If it makes sense, a widget could have a :fill property set= to t, for
example, and in the code that calls the widget creation funct= ions (e.g.,
widget-create), widget-fill-tag-string would be bound to t.= =C2=A0 This goes,
of course, for all other users of the widget library.<= br>
Best regards,
Mauro.
--00000000000061469205930e016d--