Re: make-field suggestion

[Jerry James]

Stefan <address@hidden> wrote:
> The only place where I've use fields is for minibuffer-like entry things
> with completion (where I reuse the minibuffer completion code, suitably
> fixed not to assume it's in a minibuffer).  In such cases, it's often
> important that if the user reduces the size of the field to 0 it can still
> grow it back later on by inserting text into it, i.e. I've had to use an
> overlay and it had to be created as:
>
>    (make-overlay from to nil nil t)
>
> so I suggest to at least make it possible to pass the front/rear stickiness
> as an argument.

Okay, that makes sense.  It looks like I can rip off much of the
make-overlay docstring in that case.  Hmmmm.... so is it true that
overlays are neither front- nor rear-sticky by default?  But the text
property API creates regions that are front-sticky but not rear-sticky
by default, doesn't it?  I want to make sure I get this right, because
the whole point of make-field is to hide the different Emacs and XEmacs
defaults.

Here's my latest attempt, which I think is wrong because the created
field has no stickiness at all.  I think.

(defun make-field (from to value &optional buffer front-advance rear-advance)
  "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
If omitted, BUFFER defaults to the current buffer.
FROM and TO may be integers or markers.
The fifth argument, FRONT-ADVANCE, if non-nil, makes the front delimiter
advance when text is inserted there.
The sixth argument, REAR-ADVANCE, if non-nil, makes the rear delimiter
advance when text is inserted there."
  (overlay-put (make-overlay from to buffer front-advance rear-advance)
               'field value))

Regards,
-- 
Jerry James
http://www.ittc.ku.edu/~james/