[BUG] widget-field-overlay becomes wrong

[BUG] widget-field-overlay becomes wrong

[Lars Hansen]

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

One for the bug-list :-)

When a widget-field-overlay goes all the way to the next or previous 
widget, it becomes wrong when that next or previous widget is changed.
A test case is attached.

Richard has written a comment in widget-default-value-set which probably 
is about the same thing.

I don't know how to fix this bug, it seems quite tricky.
Of cause a work-around is to never have a widget field adjacent to 
another widget.


[-- Attachment #2: widget-field-overlay-bug.el --]
[-- Type: text/plain, Size: 1169 bytes --]

;-----------------------------------------------------------------------------------------------
;  widget-field-overlay-bug.el
;-----------------------------------------------------------------------------------------------

(require 'wid-edit)

(defvar w1 nil)
(defvar w2 nil)
(defvar w3 nil)

(defun widget-field-overlay-bug ()
  (interactive)
  (switch-to-buffer "*test*")
  (setq w1 (widget-create 'editable-field :format "%v" :size 3 :value "xxx"))
  (setq w2 (widget-create 'editable-field :format " %v " :size 3 :value "foo"))
  (setq w3 (widget-create 'editable-field :format "%v" :size 3 :value "yyy"))
  (widget-setup)
  (message "w1: %s\nw2: %s\nw3: %s"
           (widget-get w1 :field-overlay)
           (widget-get w2 :field-overlay)
           (widget-get w3 :field-overlay))
  (when (y-or-n-p "Continue ")
    (widget-value-set w2 "bar")
    (widget-setup)
    ;; Markers are OK, but overlay of w1 and w3 are wrong!
    (message "w1: %s\nw2: %s\nw3: %s"
             (widget-get w1 :field-overlay)
             (widget-get w2 :field-overlay)
             (widget-get w3 :field-overlay))
    (display-buffer "*Messages*")
    (goto-char (point-max))))

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [BUG] widget-field-overlay becomes wrong

[Richard Stallman]

    Of cause a work-around is to never have a widget field adjacent to 
    another widget.

If that is an acceptable solution, we can document it as a
requirement.  Does anyone see a problem with that?

We could also add code to give an error when creating
the widget, if this case would occur.
Can you see how to write that error-check?

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

Richard Stallman wrote:

>    Of cause a work-around is to never have a widget field adjacent to 
>    another widget.
>
>If that is an acceptable solution, we can document it as a
>requirement.  Does anyone see a problem with that?
>  
>
I don't like that solution. What I meant to say is that it is not a 
serious bug, but it is a bug after all.
I would rather like to see if I can come up with a fix.

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

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

Lars Hansen wrote:

> I would rather like to see if I can come up with a fix.

The attached patch seems to fix the bug.


[-- Attachment #2: wid-edit.el.diff --]
[-- Type: text/plain, Size: 2369 bytes --]

*** wid-edit.el.~1.128.~	Tue Jun  8 21:50:16 2004
--- wid-edit.el	Fri Jul  2 07:49:46 2004
***************
*** 414,426 ****
      (widget-put widget :doc-overlay overlay)))
  
  (defmacro widget-specify-insert (&rest form)
!   "Execute FORM without inheriting any text properties."
    `(save-restriction
      (let ((inhibit-read-only t)
! 	  (inhibit-modification-hooks t))
        (narrow-to-region (point) (point))
        (prog1 (progn ,@form)
! 	(goto-char (point-max))))))
  
  (defface widget-inactive-face '((((class grayscale color)
  				  (background dark))
--- 414,443 ----
      (widget-put widget :doc-overlay overlay)))
  
  (defmacro widget-specify-insert (&rest form)
!   "Execute FORM without inheriting any text properties.
! Furthermore, ensure overlays ending at point or starting at point
! does not include text inserted."
    `(save-restriction
      (let ((inhibit-read-only t)
! 	  (inhibit-modification-hooks t)
!           overlays-before
!           overlays-after)
!       (mapc (lambda (overlay)
!               (when (= (point) (overlay-end overlay))
!                 (setq overlays-before (cons overlay overlays-before)))
!               (when (= (point) (overlay-start overlay))
!                 (setq overlays-after (cons overlay overlays-after))))
!             (overlays-in (if (= (point) (point-min)) (point) (1- (point)))
!                          (if (= (point) (point-max)) (point) (1+ (point)))))
        (narrow-to-region (point) (point))
        (prog1 (progn ,@form)
!         (mapc (lambda (overlay)
!                 (move-overlay overlay (overlay-start overlay) (point-min)))
!               overlays-before)
!         (mapc (lambda (overlay)
!                 (move-overlay overlay (point-max) (overlay-end overlay)))
!               overlays-after)
!         (goto-char (point-max))))))
  
  (defface widget-inactive-face '((((class grayscale color)
  				  (background dark))
***************
*** 1530,1538 ****
  		     (if (>= old-pos (1- to))
  			 (- old-pos to 1)
  		       (- old-pos from)))))
-     ;;??? Bug: this ought to insert the new value before deleting the old one,
-     ;; so that markers on either side of the value automatically
-     ;; stay on the same side.  -- rms.
      (save-excursion
        (goto-char (widget-get widget :from))
        (widget-apply widget :delete)
--- 1547,1552 ----

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [BUG] widget-field-overlay becomes wrong

[Richard Stallman]

If I understand what you've done, I think it doesn't work in all cases.
What will happen if the user deletes all the text in the editable field,
then inserts new text?  Will that newly inserted text be treated
as part of a neighboring widget?  It seems likely.

I don't think it is worth spending a lot of time to fix this,
because I think it is fundamentally impossible, and there are
more important things to do.  For instance, would you be interested
in working on making saving of text properties in files more
convenient?  That is more important.

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

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

Richard Stallman wrote:

>What will happen if the user deletes all the text in the editable field,
>then inserts new text?  Will that newly inserted text be treated
>as part of a neighboring widget?  It seems likely.
>  
>
You are right, zero-sized overlays cannot be ignored as I did. Such 
overlays should only go in overlays-after. This is done in the patch 
attached.

>I don't think it is worth spending a lot of time to fix this,
>because I think it is fundamentally impossible, and there are
>more important things to do.
>
I don't see why it should be fundamentally impossible to fix this bug. 
AFAICS a widget cannot have zero size, and if it has a zero-sized 
overlay at one end, it is at the start.

I want to fix this bug because it annoys me in some tests I am doing.
I suggest we install my patch. It can always be removed if it has 
undesirable consequences.

>For instance, would you be interested
>in working on making saving of text properties in files more
>convenient?  That is more important.
>
I would be happy to work much more on Emacs. However, that requires 
someone to finance it :-). Right now I don't have the time :-(.


[-- Attachment #2: wid-edit.el.diff --]
[-- Type: text/plain, Size: 2444 bytes --]

*** wid-edit.el.~1.128.~	Tue Jun  8 21:50:16 2004
--- wid-edit.el	Sun Jul  4 10:34:13 2004
***************
*** 414,426 ****
      (widget-put widget :doc-overlay overlay)))
  
  (defmacro widget-specify-insert (&rest form)
!   "Execute FORM without inheriting any text properties."
    `(save-restriction
      (let ((inhibit-read-only t)
! 	  (inhibit-modification-hooks t))
        (narrow-to-region (point) (point))
        (prog1 (progn ,@form)
! 	(goto-char (point-max))))))
  
  (defface widget-inactive-face '((((class grayscale color)
  				  (background dark))
--- 414,444 ----
      (widget-put widget :doc-overlay overlay)))
  
  (defmacro widget-specify-insert (&rest form)
!   "Execute FORM without inheriting any text properties.
! Furthermore, ensure overlays ending at point or starting at point
! does not include text inserted."
    `(save-restriction
      (let ((inhibit-read-only t)
! 	  (inhibit-modification-hooks t)
!           overlays-before
!           overlays-after)
!       (mapc (lambda (overlay)
!               (when (and (= (point) (overlay-end overlay))
!                          (not (= (point) (overlay-start overlay))))
!                 (setq overlays-before (cons overlay overlays-before)))
!               (when (= (point) (overlay-start overlay))
!                 (setq overlays-after (cons overlay overlays-after))))
!             (overlays-in (if (= (point) (point-min)) (point) (1- (point)))
!                          (if (= (point) (point-max)) (point) (1+ (point)))))
        (narrow-to-region (point) (point))
        (prog1 (progn ,@form)
!         (mapc (lambda (overlay)
!                 (move-overlay overlay (overlay-start overlay) (point-min)))
!               overlays-before)
!         (mapc (lambda (overlay)
!                 (move-overlay overlay (point-max) (overlay-end overlay)))
!               overlays-after)
!         (goto-char (point-max))))))
  
  (defface widget-inactive-face '((((class grayscale color)
  				  (background dark))
***************
*** 1530,1538 ****
  		     (if (>= old-pos (1- to))
  			 (- old-pos to 1)
  		       (- old-pos from)))))
-     ;;??? Bug: this ought to insert the new value before deleting the old one,
-     ;; so that markers on either side of the value automatically
-     ;; stay on the same side.  -- rms.
      (save-excursion
        (goto-char (widget-get widget :from))
        (widget-apply widget :delete)
--- 1548,1553 ----

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [BUG] widget-field-overlay becomes wrong

[Per Abrahamsen]

I could not make fields work correctly unless they were separated by
some text, so that was a a basic restriction in the design.  It should
be documented as such. 

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

Per Abrahamsen wrote:
> I could not make fields work correctly unless they were separated by
> some text, so that was a a basic restriction in the design.  It should
> be documented as such. 

It is. So the only problem is that I didn't read it.
Sorry for the noise.

Re: [BUG] widget-field-overlay becomes wrong

[Richard Stallman]

    I could not make fields work correctly unless they were separated by
    some text, so that was a a basic restriction in the design.  It should
    be documented as such. 

Can you tell us where in widget.texi this needs to be stated?
I coud easily write the necessary text once I know where.

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

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

Per Abrahamsen wrote:
> I could not make fields work correctly unless they were separated by
> some text, so that was a a basic restriction in the design.  It should
> be documented as such. 

One more comment on the subject.

 From what you write, and from what is in the manual, it suffices that 
"fields are surrounded by static text". However that is not enough.
The text may not be part of another widget. Even worse, in the 
programming example, this rule is broken! So if you run the example, you 
will see the "bug" i reported (click the Choose button).

The patch attached should correct these problems.

[-- Attachment #2: widget.texi.diff --]
[-- Type: text/plain, Size: 1711 bytes --]

*** emacs/LH-work/widget/widget-1.26.texi	Thu Apr 29 21:25:31 2004
--- cvsroot/emacs/man/widget.texi	Fri Jul  9 22:54:45 2004
***************
*** 213,219 ****
  
  Editable text fields are created by the @code{editable-field} widget.
  
! 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 terminating line-feed character
  will count as the necessary static text on that end, but you will have
--- 213,220 ----
  
  Editable text fields are created by the @code{editable-field} widget.
  
! In an @code{editable-field} widget, the 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 terminating line-feed character
  will count as the necessary static text on that end, but you will have
***************
*** 221,226 ****
--- 222,229 ----
  @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.
+ Observe that static text belonging to another widget does @emph{not}
+ count, however text inserted with @code{widget-insert} does.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
***************
*** 345,350 ****
--- 348,354 ----
    (widget-insert "Here is some documentation.\n\nName: ")
    (widget-create 'editable-field
  		 :size 13
+ 		 :format "%v " ; Static text after the field!
  		 "My Name")
    (widget-create 'menu-choice
  		 :tag "Choose"

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [BUG] widget-field-overlay becomes wrong

[Per Abrahamsen]

Lars Hansen <larsh@math.ku.dk> writes:

>  From what you write, and from what is in the manual, it suffices that
> "fields are surrounded by static text". However that is not enough.
> The text may not be part of another widget. 

I think the problem in the example is that the "menu-choice" widget is
not "static text".  Whenever you make a new choice, the widget rewrite
itself from scratch.   

> Even worse, in the
> programming example, this rule is broken! So if you run the example,
> you will see the "bug" i reported (click the Choose button).

Yes, the example in my own directory already has this fix.

The second part of your patch should be applied.

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

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

Per Abrahamsen wrote:

>I think the problem in the example is that the "menu-choice" widget is
>not "static text".  Whenever you make a new choice, the widget rewrite
>itself from scratch.   
>
Exactly. And that goes for editable text fields too. But never the less, 
text generated by :format is called "static text" in the manual.
I may be a good idea to avoid the term "static text"; it is misleading.

>The second part of your patch should be applied.
>  
>
We need changes in the first part as well because it is incorrect as it 
is now.
What about the attached rewrite without the term "static text"?


[-- Attachment #2: widget.texi.diff --]
[-- Type: text/plain, Size: 2061 bytes --]

*** widget-1.26.texi	Thu Apr 29 21:25:30 2004
--- /home/lh/cvsroot/emacs/man/widget.texi	Wed Jul 14 08:52:33 2004
***************
*** 213,226 ****
  
  Editable text fields are created by the @code{editable-field} widget.
  
! 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 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.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
--- 213,228 ----
  
  Editable text fields are created by the @code{editable-field} widget.
  
! In an @code{editable-field} widget, the editable field is not allowed
! to be adjacent to a neighbouring widget, there must be some text in
! between.  This text must be part of the @code{editable-field} widget
! itself or inserted with @code{widget-insert}.  The @code{:format}
! keyword is useful for generating the necessary text; for instance, if
! you give it a value of @code{"Name: %v "}, the "Name: " part will
! provide the text before the field and the trailing space will provide
! the text after the field.  If no @code{:size} argument is given the
! field will extends to the end of the line, and then the terminating
! line-feed character will count as the necessary text after the field.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
***************
*** 345,350 ****
--- 347,353 ----
    (widget-insert "Here is some documentation.\n\nName: ")
    (widget-create 'editable-field
  		 :size 13
+ 		 :format "%v " ; Static text after the field!
  		 "My Name")
    (widget-create 'menu-choice
  		 :tag "Choose"

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [BUG] widget-field-overlay becomes wrong

[Per Abrahamsen]

Lars Hansen <larsh@math.ku.dk> writes:

> ! In an @code{editable-field} widget, the editable field is not allowed
> ! to be adjacent to a neighbouring widget, there must be some text in
> ! between.

That's not true.  There can be a widget next to it, as long as the
text is static.  

Re: [BUG] widget-field-overlay becomes wrong

[Richard Stallman]

    > ! In an @code{editable-field} widget, the editable field is not allowed
    > ! to be adjacent to a neighbouring widget, there must be some text in
    > ! between.

    That's not true.  There can be a widget next to it, as long as the
    text is static.  

Could you try rewriting this text?
If you use terms like "static", it's important to state
which widget types involve non-static text at the edges.

Re: [BUG] widget-field-overlay becomes wrong

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     > ! In an @code{editable-field} widget, the editable field is not allowed
>     > ! to be adjacent to a neighbouring widget, there must be some text in
>     > ! between.
>
>     That's not true.  There can be a widget next to it, as long as the
>     text is static.  
>
> Could you try rewriting this text?
> If you use terms like "static", it's important to state
> which widget types involve non-static text at the edges.

My only idea would be a specific warning about the "choice" widget.

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

Per Abrahamsen wrote:

>My only idea would be a specific warning about the "choice" widget.
>  
>
I don't think you understand the problem. The menu-choice widget is not 
special, any widget type can give the problem! At least I don't know of 
any type that can't.
As you noted yourself, the problem comes when a widget rewrites itself 
"from scratch". Any widget does that if you change it's value with 
widget-value-set from some lisp program.

So I still suggest to install my latest patch to the manual.

Re: [BUG] widget-field-overlay becomes wrong

[Per Abrahamsen]

Lars Hansen <larsh@math.ku.dk> writes:

> As you noted yourself, the problem comes when a widget rewrites itself
> "from scratch". Any widget does that if you change it's value with
> widget-value-set from some lisp program.

Yes, from a Lisp program.  But then it is under programmer control.

Only the menu-choice, coding-system and color widgets[1] call
widget-value-set as a result of a user action, so only those are
inherently unsafe.

Footnotes: 
[1]  The radio-button-choice widget also call widget-value-set, but it
doesn't rewrite itself when that happens.

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

Per Abrahamsen wrote:

>Only the menu-choice, coding-system and color widgets[1] call
>widget-value-set as a result of a user action, so only those are
>inherently unsafe.
>
>Footnotes: 
>[1]  The radio-button-choice widget also call widget-value-set, but it
>doesn't rewrite itself when that happens.
>  
>
Try to evaluate

(progn
  (switch-to-buffer "*test*")
  (widget-create 'editable-field :format "%v" :size 3)
  (widget-create 'checkbox)
  (use-local-map widget-keymap)
  (widget-setup))

or

(progn
  (switch-to-buffer "*test*")
  (widget-create 'editable-field :format "%v" :size 3)
  (widget-create 'radio-button-choice :value "1" '(item "1") '(item "2"))
  (use-local-map widget-keymap)
  (widget-setup))

The problem shows up here as well.

Re: [BUG] widget-field-overlay becomes wrong

[Per Abrahamsen]

Lars Hansen <larsh@math.ku.dk> writes:

> (progn
>   (switch-to-buffer "*test*")
>   (widget-create 'editable-field :format "%v" :size 3)
>   (widget-create 'checkbox)
>   (use-local-map widget-keymap)
>   (widget-setup))

Yes, the toggle widget also call widget-value-set.  I missed that one.

> (progn
>   (switch-to-buffer "*test*")
>   (widget-create 'editable-field :format "%v" :size 3)
>   (widget-create 'radio-button-choice :value "1" '(item "1") '(item "2"))
>   (use-local-map widget-keymap)
>   (widget-setup))
>
> The problem shows up here as well.

Not if you put some static text first:

 (progn
   (switch-to-buffer "*test*")
   (widget-create 'editable-field :format "%v" :size 3)
   (widget-create 'radio-button-choice :format "Radio: %v"
                  :value "1" '(item "1") '(item "2"))
   (use-local-map widget-keymap)
   (widget-setup))

Re: [BUG] widget-field-overlay becomes wrong

[Richard Stallman]

    > If you use terms like "static", it's important to state
    > which widget types involve non-static text at the edges.

    My only idea would be a specific warning about the "choice" widget.

Could you take a stab at writing a patch to the manual?
If you write something that I can understand, I can polish it.

Re: [BUG] widget-field-overlay becomes wrong

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     > If you use terms like "static", it's important to state
>     > which widget types involve non-static text at the edges.
>
>     My only idea would be a specific warning about the "choice" widget.
>
> Could you take a stab at writing a patch to the manual?
> If you write something that I can understand, I can polish it.

You cannot place an editable field next to a widget that which is
going to be deleted (with @code{widget-delete}), or whose value is
changed from with the function @code{widget-value-set}.  The
@code{menu-choice}, @code{coding-system} and @code{color} widgets call
@code{widget-value-set} when the user change their value, so these
widgets (or widgets derived from them) should never be places next to
an editing field.

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

Per Abrahamsen wrote:

>You cannot place an editable field next to a widget that which is
>going to be deleted (with @code{widget-delete}), or whose value is
>changed from with the function @code{widget-value-set}.  The
>@code{menu-choice}, @code{coding-system} and @code{color} widgets call
>@code{widget-value-set} when the user change their value, so these
>widgets (or widgets derived from them) should never be places next to
>an editing field.
>  
>
Also checkbox and radio-button-choice give problems. And even if these 
were the only cases, it is a bad idea to place _any_ widget next to an 
editable field. It is not sound to create a widget for witch 
widget-value-set will lead to errors. Somebody else's code might call 
widget-value-set!

IMO the manual should not bother the reader with unnecessary technical 
details. Instead it should tell the reader that an editable field is not 
allowed to be adjacent to a neighbouring widget. That is simpler and 
leads to sound code.

Re: [BUG] widget-field-overlay becomes wrong

[Richard Stallman]

    IMO the manual should not bother the reader with unnecessary technical 
    details. Instead it should tell the reader that an editable field is not 
    allowed to be adjacent to a neighbouring widget. That is simpler and 
    leads to sound code.

I too think this is the wisest idea, because it is simple to explain.
We could add that some cases of this will actually work ok
but it would be too much trouble to try to explain which.

Where in widget.texi is a good place to say this?

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

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

Richard Stallman wrote:

>We could add that some cases of this will actually work ok
>but it would be too much trouble to try to explain which.
>
>Where in widget.texi is a good place to say this?
>  
>
I don't see much point in that, so I don't know where it would fit in.
I suggest the attached patch.


[-- Attachment #2: widget.texi.diff --]
[-- Type: text/plain, Size: 2049 bytes --]

*** widget.texi.~1.26.~	Sun May  2 07:30:17 2004
--- widget.texi	Tue Aug  3 22:39:21 2004
***************
*** 213,226 ****
  
  Editable text fields are created by the @code{editable-field} widget.
  
! 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 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.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
--- 213,229 ----
  
  Editable text fields are created by the @code{editable-field} widget.
  
! @strong{Warning:} In an @code{editable-field} widget, the editable
! field is not allowed to be adjacent to another widget, there must be
! some text in between.  This text must be part of the
! @code{editable-field} widget itself or inserted with
! @code{widget-insert}.  The @code{:format} keyword is useful for
! generating the necessary text; for instance, if you give it a value of
! @code{"Name: %v "}, the "Name: " part will provide the text before the
! field and the trailing space will provide the text after the field.
! If no @code{:size} argument is given the field will extends to the end
! of the line, and then the terminating line-feed character will count
! as the necessary text after the field.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
***************
*** 345,350 ****
--- 348,354 ----
    (widget-insert "Here is some documentation.\n\nName: ")
    (widget-create 'editable-field
  		 :size 13
+ 		 :format "%v " ; Static text after the field!
  		 "My Name")
    (widget-create 'menu-choice
  		 :tag "Choose"

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

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

Lars Hansen wrote:

> I suggest the attached patch.

Oops, I didn't delete the word "static" in the programming example.
This is corrected in the attachment.




[-- Attachment #2: widget.texi.diff --]
[-- Type: text/plain, Size: 2042 bytes --]

*** widget.texi.~1.26.~	Sun May  2 07:30:17 2004
--- widget.texi	Tue Aug  3 23:20:28 2004
***************
*** 213,226 ****
  
  Editable text fields are created by the @code{editable-field} widget.
  
! 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 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.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
--- 213,229 ----
  
  Editable text fields are created by the @code{editable-field} widget.
  
! @strong{Warning:} In an @code{editable-field} widget, the editable
! field is not allowed to be adjacent to another widget, there must be
! some text in between.  This text must be part of the
! @code{editable-field} widget itself or inserted with
! @code{widget-insert}.  The @code{:format} keyword is useful for
! generating the necessary text; for instance, if you give it a value of
! @code{"Name: %v "}, the "Name: " part will provide the text before the
! field and the trailing space will provide the text after the field.
! If no @code{:size} argument is given the field will extends to the end
! of the line, and then the terminating line-feed character will count
! as the necessary text after the field.
  
  The editing text fields are highlighted with the
  @code{widget-field-face} face, making them easy to find.
***************
*** 345,350 ****
--- 348,354 ----
    (widget-insert "Here is some documentation.\n\nName: ")
    (widget-create 'editable-field
  		 :size 13
+ 		 :format "%v " ; Text after the field!
  		 "My Name")
    (widget-create 'menu-choice
  		 :tag "Choose"

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [BUG] widget-field-overlay becomes wrong

[Richard Stallman]

Thanks for writing this.  Now I can polish it up.

    ! @strong{Warning:} In an @code{editable-field} widget, the editable
    ! field is not allowed to be adjacent to another widget, there must be
    ! some text in between.

"Is not allowed to be" is not just passive, it is contorted.

			     This text must be part of the
    ! @code{editable-field} widget itself or inserted with
    ! @code{widget-insert}.

A single "be" is used for a passive verb and in another way.
That's not just passive, but confusing too.

Here's how I would write it more readably:

    @strong{Warning:} In an @code{editable-field} widget, the editable
    field must not be adjacent to another widget---that won't work.
    You must put some text in between.  Either make this text part of
    the @code{editable-field} widget itself, or insert it with
    @code{widget-insert}.
    
    The @code{:format} keyword is useful for generating the necessary
    text; for instance, if you give it a value of @code{"Name: %v "},
    the @samp{Name: } part will provide the necessary separating text
    before the field and the trailing space will provide the
    separating text after the field.  If you don't include the
    @code{:size} keyword, the field will extend to the end of the
    line, and the terminating newline will provide separation after.

I split the paragraph for readability too.  Long paragraphs are
hard to read.

Could somene please install the change, with this modification?

Re: [BUG] widget-field-overlay becomes wrong

[Lars Hansen]

Richard Stallman wrote:

>Could somene please install the change, with this modification?
>  
>
Done.