Other potential problem with :format.

Other potential problem with :format.

[Luc Teirlinck]

Is the following a bug or is one just not supposed to use %h before %v
in the 'integer choice in the file below?  Putting the %v in front of
the %h makes the problem go away.  I do not know whether there is a
relation with the other problem we are discussing.

Do:

emacs-21.3.50 -q --eval "(blink-cursor-mode 0)" &

and load:

===File ~/editable-field.el=================================
(defgroup nifty nil
  "Single item group"
  :group 'convenience)

(defcustom nifty-var 0
  "*Nifty doc string."
  :group 'nifty
  :type '(choice (const :tag "True"
                        :format "%t\n%h"
                        :doc
                        "True stuff.
Second line of true stuff."
                        t)
                 (integer :tag "Number"
			  :format "%t\n%h%v"
			  :doc
			  "Some integer.
Choose it wisely."
			  0)))

============================================================

M-x customize-group 'nifty

Click on the "More" next to: "Some integer".

Result: the documentation is now part of the editable field.

Does not happen if one replaces the :format string of "integer" with
"%t\n%v%h", that is, if one switches %h and %v.  Is the above a bug or
is one just supposed to _always_ put %h _after_ &v, except in `defface'?

Sincerely,

Luc.

Re: Other potential problem with :format.

[Per Abrahamsen]

Editable fields should in general be surrounded by static text, as
they need the text to "anchor" themselves as we have little control of
what happens inside the field.

Re: Other potential problem with :format.

[Richard Stallman]

    Editable fields should in general be surrounded by static text, as
    they need the text to "anchor" themselves as we have little control of
    what happens inside the field.

Could you please look at the manual and see if this could use being
stated more clearly?

Re: Other potential problem with :format.

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     Editable fields should in general be surrounded by static text, as
>     they need the text to "anchor" themselves as we have little control of
>     what happens inside the field.
>
> Could you please look at the manual and see if this could use being
> stated more clearly?

*** widget.texi.~1.19.~	Thu Aug 21 14:18:07 2003
--- widget.texi	Mon Aug 25 15:01:36 2003
***************
*** 10,16 ****
  @c %**end of header
  
  @copying
! Copyright @copyright{} 2000, 2002 Free Software Foundation, Inc.
  
  @quotation
  Permission is granted to copy, distribute and/or modify this document
--- 10,16 ----
  @c %**end of header
  
  @copying
! Copyright @copyright{} 2000, 2002, 2003 Free Software Foundation, Inc.
  
  @quotation
  Permission is granted to copy, distribute and/or modify this document
***************
*** 211,217 ****
  For example, capitalizing all text from the middle of one field to the
  middle of another field is prohibited.
  
! Editing text fields are created by the @code{editable-field} widget.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
--- 211,225 ----
  For example, capitalizing all text from the middle of one field to the
  middle of another field is prohibited.
  
! Editable text fields are created by the @code{editable-field} widget.
! 
! An editable fields must be surrounded by static text on both sides, that
! is, text that does not change in the lifetime of the widget.  If the
! field extend to the end of the line, the terminating line-feed character
! will count as the necessary static text on that end.  You will have to
! provide the static text before the field yourself.  The @code{:format}
! keyword is useful for that, if you give it a value of e.g.  @code{"Name:
! %v"} the "Name: " part will count as the static text.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.

Re: Other potential problem with :format.

[Richard Stallman]

    ! An editable fields must be surrounded by static text on both sides, that
    ! is, text that does not change in the lifetime of the widget.  If the
    ! field extend to the end of the line, the terminating line-feed character
    ! will count as the necessary static text on that end.  You will have to
    ! provide the static text before the field yourself.  The @code{:format}
    ! keyword is useful for that, if you give it a value of e.g.  @code{"Name:
    ! %v"} the "Name: " part will count as the static text.

It would be clearer with this small rewrite.

    ! An editable fields must be surrounded by static text on both
    ! sides, that is, text that does not change in the lifetime of the
    ! widget.  If the field extend to the end of the line, the
    ! terminating line-feed character will count as the necessary
    ! static text on that end, but you will have to provide the static
    ! text before the field yourself.  The @code{:format} keyword is
    ! useful for generating the static text; for instance, if you give
    ! it a value of @code{"Name: %v"}, the "Name: " part will count as
    ! the static text.

Can you install it?

Re: Other potential problem with :format.

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> Can you install it?

I have commited the new text.

Re: Other potential problem with :format.

[Robert J. Chassell]

Minor typos: `field' is a singular noun in the first sentence and
`extends' is a singular verb in the second sentence.

From

    ! An editable fields must be surrounded by static text on both
    ! sides, that is, text that does not change in the lifetime of the
    ! widget.  If the field extend to the end of the line, the

to

    ! An editable field must be surrounded by static text on both
    ! sides, that is, text that does not change in the lifetime of the
    ! widget.  If the field extends to the end of the line, the

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com