make-field suggestion

make-field suggestion

[Jerry James]

I have been porting the Emacs field interface to XEmacs.  I ran into a
small hassle when I discovered that the default front/back-stickiness of
XEmacs extents is reversed from that of Emacs overlays.  In order to
hide the differences, I wrote a make-field function that makes an
extent, then reverses the stickiness (open/closedness, in XEmacs
terminology) to match Emacs.

I would like to suggest the make-field interface for Emacs.  The Emacs
version would look something like this, if defaulting to text properties
is okay:

(defun make-field (from to value &optional buffer)
  "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
BUFFER defaults to the current buffer."
  (with-current-buffer (or buffer (current-buffer))
    (put-text-property from to 'field value)))

If you would rather default to overlays, then perhaps something along
these lines would be suitable:

(defun make-field (from to value &optional buffer)
  "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
BUFFER defaults to the current buffer."
  (overlay-put (make-overlay from to buffer) 'field value))

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

Re: make-field suggestion

[Stefan]

> (defun make-field (from to value &optional buffer)
>   "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
> BUFFER defaults to the current buffer."
>   (overlay-put (make-overlay from to buffer) 'field value))

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.


        Stefan

Re: make-field suggestion

[Jerry James]

Stefan <monnier@iro.umontreal.ca> 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/

Re: make-field suggestion

[Stefan]

> make-overlay docstring in that case.  Hmmmm.... so is it true that
> overlays are neither front- nor rear-sticky by default?  But the text

No, AFAIK they're front-sticky ("not front-advance") and
rear-non-sticky ("not rear-advance").


        Stefan

Re: make-field suggestion

[Jerry James]

Stefan <monnier@iro.umontreal.ca>, on 31 Aug 2004 at 22:48:14 -0400 you
wrote:
>> make-overlay docstring in that case.  Hmmmm.... so is it true that
>> overlays are neither front- nor rear-sticky by default?  But the text
>
> No, AFAIK they're front-sticky ("not front-advance") and
> rear-non-sticky ("not rear-advance").

I'm misunderstanding something then.  The docstring for make-overlay
says:

  Create a new overlay with range BEG to END in BUFFER.
  If omitted, BUFFER defaults to the current buffer.
  BEG and END may be integers or markers.
  The fourth arg FRONT-ADVANCE, if non-nil, makes the
  front delimiter advance when text is inserted there.
  The fifth arg REAR-ADVANCE, if non-nil, makes the
  rear delimiter advance when text is inserted there.

Since front-advance and rear-advance are both optional, they default to
nil, no?  Which means that (make-overlay 10 20) makes an overlay that is
front-non-sticky and rear-non-sticky.  The code in buffer.c seems to
bear this out:

  if (!NILP (front_advance))
    XMARKER (beg)->insertion_type = 1;
  if (!NILP (rear_advance))
    XMARKER (end)->insertion_type = 1;

Where have I gone wrong?  Is there some other function I should be
looking at instead of make-overlay?

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

Re: make-field suggestion

[Stefan]

>> No, AFAIK they're front-sticky ("not front-advance") and
>> rear-non-sticky ("not rear-advance").
> I'm misunderstanding something then.

Yes you are.  Read again: (eq front-sticky (not front-advance))


        Stefan

Re: make-field suggestion

[Jerry James]

Stefan <monnier@iro.umontreal.ca>, on Tue, 07 Sep 2004 at 11:56:34 -0400
you wrote:
>>> No, AFAIK they're front-sticky ("not front-advance") and
>>> rear-non-sticky ("not rear-advance").
>> I'm misunderstanding something then.
>
> Yes you are.  Read again: (eq front-sticky (not front-advance))

<* A light bulb suddenly appears over Jerry's head *>

Thank you!
-- 
Jerry James
http://www.ittc.ku.edu/~james/

Re: make-field suggestion

[Richard Stallman]

    I would like to suggest the make-field interface for Emacs.  The Emacs
    version would look something like this, if defaulting to text properties
    is okay:

    (defun make-field (from to value &optional buffer)
      "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
    BUFFER defaults to the current buffer."
      (with-current-buffer (or buffer (current-buffer))
	(put-text-property from to 'field value)))

We can certainly install something like this, once it is clear what is
best.  It depends, I suppose, on how someone would plan to use it.

Re: make-field suggestion

[Jerry James]

Richard Stallman <rms@gnu.org>, on Wed, 01 Sep 2004 at 00:57:24 -0400
you wrote:
>     I would like to suggest the make-field interface for Emacs.  The Emacs
>     version would look something like this, if defaulting to text properties
>     is okay:
>
>     (defun make-field (from to value &optional buffer)
>       "Make a field with value VALUE over the range [FROM, TO) in BUFFER.
>     BUFFER defaults to the current buffer."
>       (with-current-buffer (or buffer (current-buffer))
> 	(put-text-property from to 'field value)))
>
> We can certainly install something like this, once it is clear what is
> best.  It depends, I suppose, on how someone would plan to use it.

The reason for having a make-field function is to complete the
abstraction.  It is almost possible to treat fields as abstract data
types using field-beginning, etc., but it is not possible to create them
without breaking the abstraction.

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

Re: make-field suggestion

[Miles Bader]

Jerry James <james@xemacs.org> writes:
> The reason for having a make-field function is to complete the
> abstraction.  It is almost possible to treat fields as abstract data
> types using field-beginning, etc., but it is not possible to create them
> without breaking the abstraction.

I think some attention should be paid to the issue of creating
text-property fields vs. overlay fields -- both are useful in different
circumstances, so any `make-field' function should allow creating both
(or there should be multiple `make...field' functions).

For instance, in my `button' package, I have both `make-button', which
makes an overlay button, and `make-text-button', which makes a
text-property button (and the interface is otherwise the same).

The documentation for `make-text-button' says in part:

   This function is like `make-button', except that the button is actually
   part of the text instead of being a property of the buffer.  Creating
   large numbers of buttons can also be somewhat faster using
   `make-text-button'.

I'll try to look at some code and get an idea in what cases different
types of fields are created.

-Miles
-- 
自らを空にして、心を開く時、道は開かれる

Re: make-field suggestion

[Jerry James]

Miles Bader <miles@lsi.nec.co.jp> wrote:
> I think some attention should be paid to the issue of creating
> text-property fields vs. overlay fields -- both are useful in different
> circumstances, so any `make-field' function should allow creating both
> (or there should be multiple `make...field' functions).

That makes sense.  How about something like this?

(defun make-field (from to value &optional buffer front-advance rear-advance
		   use-text-props)
  "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.
If USE-TEXT-PROPS is non-nil, then the field is created using text properties.
Otherwise, it is created using an overlay."
  (if use-text-props
      (add-text-properties from to
			   (list 'field value
				 'front-sticky (not front-advance)
				 'rear-nonsticky (not rear-advance))
			   buffer)
    (overlay-put (make-overlay from to buffer front-advance rear-advance)
		 'field value))
  value)

I'm not sure what this function could usefully return.  It ought to
return a reference to a field object, but there is no such thing.

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

Re: make-field suggestion

[Stefan]

> I'm not sure what this function could usefully return.  It ought to
> return a reference to a field object, but there is no such thing.

For the overlay case, it should very clearly return the new overlay.


        Stefan

Re: make-field suggestion

[Miles Bader]

On Wed, Sep 08, 2004 at 05:26:22PM -0500, Jerry James wrote:
> > I think some attention should be paid to the issue of creating
> > text-property fields vs. overlay fields -- both are useful in different
> > circumstances, so any `make-field' function should allow creating both
> > (or there should be multiple `make...field' functions).
> 
> That makes sense.  How about something like this?
> 
> (defun make-field (from to value &optional buffer front-advance rear-advance
> 		   use-text-props)

The question remains which should be the default -- most current uses of
fields use text properties; perhaps this is not the right thing, but it's
worth considering.

> I'm not sure what this function could usefully return.  It ought to
> return a reference to a field object, but there is no such thing.

In the button package the text-property variants just return the position of
the first character, since for text properties that's usable as a handle to
get at the properties (the various abstract button- operations know how to
deal with both positions and overlays).

Since all current field functions use the buffer position anyway, this should
work for both overlays and text-properties.

-Miles
-- 
`Life is a boundless sea of bitterness'