GNU bug report logs - #31309
26.1; Customize widget :type 'text reports "bad format"

Previous Next

Package: emacs;

Reported by: Phil Sainty <psainty <at> orcon.net.nz>

Date: Sun, 29 Apr 2018 09:22:02 UTC

Severity: normal

Tags: fixed

Found in version 26.1

Fixed in version 27.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31309 in the body.
You can then email your comments to 31309 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#31309; Package emacs. (Sun, 29 Apr 2018 09:22:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Phil Sainty <psainty <at> orcon.net.nz>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 29 Apr 2018 09:22:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; Customize widget :type 'text reports "bad format"
Date: Sun, 29 Apr 2018 21:21:32 +1200
It seems that the multi-line `text' widget is broken.  e.g.:

(defcustom foo
  "Text value\nspanning multiple\nlines."
  "Multi-line text field."
  :type 'text)

M-x customize-option RET foo RET

Message: custom-variable-value-create: Bad format


wid-edit.el defines the `text' widget like so:

(define-widget 'text 'editable-field
  "A multiline text area."
  :keymap widget-text-keymap)


The `string' widget (an 'editable-field derivative which works fine)
is defined as:

(define-widget 'string 'editable-field
  "A string"
  :tag "String"
  :format "%{%t%}: %v"
  :complete-function 'ispell-complete-word
  :prompt-history 'widget-string-prompt-value-history)

I also see that the parent `editable-field' widget says:
"Note: In an ‘editable-field’ widget, the ‘%v’ escape must be preceded
by some other text in the ‘:format’ string (if specified)."

If I redefine `text' as follows (by copying the :format from `string')
then the widget seems to work correctly.

(define-widget 'text 'editable-field
  "A multiline text area."
  :format "%{%t%}: %v"
  :keymap widget-text-keymap)


I'm not familiar with the internals of widgets, so I don't know if
this is the best fix, but I see that all the other `define-widget'
derivatives of `editable-field' do have explicit :format strings.

However I would have thought that in the absence of an explicit
:format, a *valid* default would be used, so I think the main bug
is in `editable-field' itself, which does not follow its own rule
when defining its own :format, which is simply "%v" (testing confirms
that this value is used by default for derivative widgets which do
not override :format).

(define-widget 'editable-field 'default
  "An editable text field.
Note: In an `editable-field' widget, the `%v' escape must be preceded
by some other text in the `:format' string (if specified)."
  :convert-widget 'widget-value-convert-widget
  :keymap widget-field-keymap
  :format "%v"
  ...)

Changing that to :format "%{%t%}: %v" proves to successfully resolve
the original problem when the `text' widget definition is reverted.

n.b. In the process of testing I noticed that "preceded by some other
text" is not entirely accurate, as a value of " %v" (with a leading
space) continued to trigger the bug.


I also note that grepping for 'editable-field in general turns up a
pile of uses of (widget-create 'editable-field) which also do not
follow the same rule; either omitting the format:

(setq widget (widget-create 'editable-field :size 15))

or setting a :format which begins with "%v":

(setq comment-widget
      (widget-create 'editable-field
                     :size 60
                     :format "%v "
                     :value (or (image-dired-get-comment file) "")))

I've not attempted to test any of that code, so I don't know
whether the same problem would occur.





In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll 
bars)
 of 2018-04-15 built on shodan
Windowing system distributor 'The X.Org Foundation', version 
11.0.11804000
System Description:	Ubuntu 16.04.4 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set [2 times]
drush-php-psysh-config
Creating customization items...
custom-variable-value-create: Bad format

Configured using:
 'configure --prefix=/home/phil/emacs/26.1rc1/usr/local
 --with-x-toolkit=lucid --without-sound'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 THREADS
LCMS2

Important settings:
  value of $LANG: en_NZ.UTF-8
  locale-coding-system: utf-8

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  minibuffer-depth-indicate-mode: t
  winner-mode: t
  global-hl-line-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv format-spec rfc822 mml mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils thingatpt help-fns radix-tree help-mode cus-edit cus-start
cus-load wid-edit cl-loaddefs cl-lib dired-x easymenu paren mb-depth
winner ring hl-line dired dired-loaddefs advice elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 120787 7713)
 (symbols 48 22375 1)
 (miscs 40 156 240)
 (strings 32 34344 1244)
 (string-bytes 1 884748)
 (vectors 16 15684)
 (vector-slots 8 507442 10438)
 (floats 8 66 51)
 (intervals 56 302 0)
 (buffers 992 15)
 (heap 1024 33490 1603))





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31309; Package emacs. (Sat, 13 Jul 2019 15:25:02 GMT) Full text and rfc822 format available.

Message #8 received at 31309 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 31309 <at> debbugs.gnu.org
Subject: Re: bug#31309: 26.1; Customize widget :type 'text reports "bad format"
Date: Sat, 13 Jul 2019 17:24:14 +0200
Phil Sainty <psainty <at> orcon.net.nz> writes:

> If I redefine `text' as follows (by copying the :format from `string')
> then the widget seems to work correctly.
>
> (define-widget 'text 'editable-field
>   "A multiline text area."
>   :format "%{%t%}: %v"
>   :keymap widget-text-keymap)

I've now done this change on the Emacs trunk.

> I'm not familiar with the internals of widgets, so I don't know if
> this is the best fix, but I see that all the other `define-widget'
> derivatives of `editable-field' do have explicit :format strings.
>
> However I would have thought that in the absence of an explicit
> :format, a *valid* default would be used, so I think the main bug
> is in `editable-field' itself, which does not follow its own rule
> when defining its own :format, which is simply "%v" (testing confirms
> that this value is used by default for derivative widgets which do
> not override :format).

Yes, the widget code is a bit convoluted...  I think what you're saying
makes sense, but I'm not sure of the ramifications, so I think the
minimal fix is perhaps best here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 13 Jul 2019 15:25:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 27.1, send any further explanations to 31309 <at> debbugs.gnu.org and Phil Sainty <psainty <at> orcon.net.nz> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 13 Jul 2019 15:25:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 11 Aug 2019 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 231 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.