Re: Fwd: Re: Re: bug in field-string and field-string-no-properties

[Stefan Monnier]

> Would you please give me your thoughts on this issue?  What he says
> seems logical; at the same time, I'm concerned that changing the spec
> of field-string could easily break something that depends on the
> current behavior.
> 
> (Everyone else is welcome to discuss it too, but I particularly
> am looking for Stefan's and Miles' thoughts.)

I remember replying, but I can't find the reply any more.
Here is a short summary: I think the current behavior is correct and as
for bugs, I don't know any right now (and since the code is used for the
minibuffer, it's unlikely that we'll see bugs in situations similar
to the minibuffer).

> ------- Start of forwarded message -------
> In-Reply-To: <address@hidden>
> Date: Thu, 14 Aug 2003 18:00:38 -0700
> To: John Paul Wallington <address@hidden>
> From: Greg Hill <address@hidden>
> Cc: address@hidden
> Subject: Re: Re: bug in field-string and field-string-no-properties
> Sender: address@hidden
> 
> >  > There appears to be a bug in field-string and
> >>  field-string-no-properties.  When (point) or the POS argument is at
> >>  the first character of a field, the function returns an empty
> >>  string. The following fragment of code, executed in the scratch
> >>  buffer, illustrates the problem.
> >>
> >  > (progn
> >>     (set-buffer (get-buffer-create "junk"))
> >>     (erase-buffer)
> >>     (insert "Test")
> >>     (put-text-property (point-min) (point-max) 'field 1)
> >>     (message "field-string at 1 = '%s'\nfield-string at 2 = '%s'"
> >>     (field-string-no-properties 1) (field-string-no-properties 2)))
> >
> >>From (elisp) Fields Info node:
> >
> >"When the characters before and after POS are part of the same field,
> >there is no doubt which field contains POS: the one those characters
> >both belong to.  When POS is at a boundary between fields, which field
> >it belongs to depends on the stickiness of the `field' properties of
> >the two surrounding characters (see *note Sticky Properties::).  The
> >field whose property would be inherited by text inserted at POS is the
> >field that contains POS."
> 
> If stickiness is the issue, then the default rear-stickiness of the
> last character of a field should identify the field-string "to the
> left of" a point; but as the example below shows, it does not.  It

I don't see how the example shows that.

> seems to me that for a four-character field there ought to be at 
> least four places at which field-string will return it.

There are.  At positions 2, 3, 4, and 5.
For non-sticky, there'll only be 3 positions and for red and front sticky
properties, there will be 5 positions where field-string will return
the field.

> As it stands, field-string returns a string only if the character to
> the left AND the character to the right of POS both have the same
> field property.

Can you show a precise test case that shows that ?
It works correctly in my tests (and in actual use by `customize' it also
seems to work).


        Stefan