[ghill@synergymicro.com: Re: Re: bug in field-string and field-string-no-properties]

[ghill@synergymicro.com: Re: Re: bug in field-string and field-string-no-properties]

[Richard Stallman]

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.)

------- Start of forwarded message -------
In-Reply-To: <3F3BA301.4522.6E53D5@localhost>
Date: Thu, 14 Aug 2003 18:00:38 -0700
To: John Paul Wallington <jpw@gnu.org>
From: Greg Hill <ghill@synergymicro.com>
Cc: bug-gnu-emacs@gnu.org
Subject: Re: Re: bug in field-string and field-string-no-properties
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org

>  > 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 
seems to me that for a four-character field there ought to be at 
least four places at which field-string will return it.

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.  That means, of course, that for a field that is one 
character long, there is no way you can ever get field-string to 
return anything but an empty string.

(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'\nfield-string at (point-max) = '%s'"
	    (field-string-no-properties 1)
	    (field-string-no-properties 2)
	    (field-string-no-properties (point-max)) ) )

- --Greg


_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

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: <3F3BA301.4522.6E53D5@localhost>
> Date: Thu, 14 Aug 2003 18:00:38 -0700
> To: John Paul Wallington <jpw@gnu.org>
> From: Greg Hill <ghill@synergymicro.com>
> Cc: bug-gnu-emacs@gnu.org
> Subject: Re: Re: bug in field-string and field-string-no-properties
> Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org
> 
> >  > 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

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

[Greg Hill]

At 5:32 PM -0400 8/28/03, Stefan Monnier wrote:
<snip>
>
>  > 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).

(progn
   (set-buffer (get-buffer-create "junk"))
   (erase-buffer)
   (insert "xXyY")
   (put-text-property 1 3 'field 'X)
   (put-text-property 3 5 'field 'Y)
   (message (concat "At 1, field-property = %s, field-string = '%s'\n"
		   " At 2, field-property = %s, field-string = '%s'\n"
		   " At 3, field-property = %s, field-string = '%s'\n"
		   " At 4, field-property = %s, field-string = '%s'\n"
		   " At 5, field-property = %s, field-string = '%s'\n")
	   (get-text-property 1 'field) (field-string-no-properties 1)
	   (get-text-property 2 'field) (field-string-no-properties 2)
	   (get-text-property 3 'field) (field-string-no-properties 3)
	   (get-text-property 4 'field) (field-string-no-properties 4)
	   (get-text-property 5 'field) (field-string-no-properties 5)))

produces:

"At 1, field-property = X, field-string = ''
  At 2, field-property = X, field-string = 'xX'
  At 3, field-property = Y, field-string = ''
  At 4, field-property = Y, field-string = 'yY'
  At 5, field-property = nil, field-string = ''
"

The kind of function I would find useful wouldn't depend on 
stickiness at all.  For a given buffer position, the value of the 
field property returned by get-text-property would determine the 
string returned by field-string when it is passed the same buffer 
position.  Thus, in the example above, since the characters at 
positions 3 and 4 both have the same value, 'Y, for their field 
property, field-string would return the same string, "yY", for both 
of those positions.  If this were the case, the `buffer-pos' in the 
event caused by mouse-clicking on the "y" at position 3 in the 
example above would always return "yY" as the field-string, not an 
empty string, and certainly not "xX" just because the "X" happened to 
be rear-sticky.

--Greg

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

[Miles Bader]

Greg Hill <ghill@synergymicro.com> writes:
> "At 1, field-property = X, field-string = ''
>   At 2, field-property = X, field-string = 'xX'
>   At 3, field-property = Y, field-string = ''
>   At 4, field-property = Y, field-string = 'yY'
>   At 5, field-property = nil, field-string = ''
> "

What version of emacs are you using?  My emacs (roughly CVS HEAD),
returns:

   "At 1, field-property = X, field-string = ''
    At 2, field-property = X, field-string = 'xX'
    At 3, field-property = Y, field-string = 'xX'
    At 4, field-property = Y, field-string = 'yY'
    At 5, field-property = nil, field-string = 'yY'
   "

which makes sense since the default for text-properties is rear-stickyness.

> The kind of function I would find useful wouldn't depend on stickiness
> at all.  For a given buffer position, the value of the field property
> returned by get-text-property would determine the string returned by
> field-string when it is passed the same buffer position.

There _is_ a reason why fields use stickiness for ambiguous locations:
it yields consistent result with what happens when a user inserts text,
and fields are fundamentally about inserting text.

Text insertion happens _between_ characters, and field operators
reflect that.

Perhaps mouse operations require some different operators, I don't know.

-Miles
-- 
"1971 pickup truck; will trade for guns"

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

[Kevin Rodgers]

Miles Bader wrote:

> Greg Hill <ghill@synergymicro.com> writes:
> 
>>"At 1, field-property = X, field-string = ''
>>  At 2, field-property = X, field-string = 'xX'
>>  At 3, field-property = Y, field-string = ''
>>  At 4, field-property = Y, field-string = 'yY'
>>  At 5, field-property = nil, field-string = ''
>>"
>>
> 
> What version of emacs are you using?

I get the same results as Greg on

GNU Emacs 21.3.1 (i386-pc-solaris2.7, X toolkit) of 2003-04-24 on briard

-- 
Kevin Rodgers

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

[Greg Hill]

At 11:36 AM +0900 8/29/03, Miles Bader wrote:
>Greg Hill <ghill@synergymicro.com> writes:
>>  "At 1, field-property = X, field-string = ''
>>    At 2, field-property = X, field-string = 'xX'
>>    At 3, field-property = Y, field-string = ''
>>    At 4, field-property = Y, field-string = 'yY'
>>    At 5, field-property = nil, field-string = ''
>>  "
>
>What version of emacs are you using?


GNU Emacs 21.2.2 (sparc-sun-solaris2.7, X toolkit) of 2002-12-17


>   My emacs (roughly CVS HEAD),
>returns:
>
>    "At 1, field-property = X, field-string = ''
>     At 2, field-property = X, field-string = 'xX'
>     At 3, field-property = Y, field-string = 'xX'
>     At 4, field-property = Y, field-string = 'yY'
>     At 5, field-property = nil, field-string = 'yY'
>    "
>
>which makes sense since the default for text-properties is rear-stickyness.
>
>>  The kind of function I would find useful wouldn't depend on stickiness
>>  at all.  For a given buffer position, the value of the field property
>>  returned by get-text-property would determine the string returned by
>>  field-string when it is passed the same buffer position.
>
>There _is_ a reason why fields use stickiness for ambiguous locations:
>it yields consistent result with what happens when a user inserts text,
>and fields are fundamentally about inserting text.
>
>Text insertion happens _between_ characters, and field operators
>reflect that.
>
>Perhaps mouse operations require some different operators, I don't know.
>
>-Miles
>--
>"1971 pickup truck; will trade for guns"