bug#6755: 24.0.50; Customize buffer is too wide. Put doc string on separate line.

[Mauro Aranda <maurooaranda@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

Hello Lars,

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Mauro Aranda <maurooaranda@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 2188 bytes --]