[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
address@hidden: Re: Re: bug in field-string and field-string-no-properti
From: |
Richard Stallman |
Subject: |
address@hidden: Re: Re: bug in field-string and field-string-no-properties] |
Date: |
Wed, 27 Aug 2003 18:12:37 -0400 |
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: <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
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
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------
- address@hidden: Re: Re: bug in field-string and field-string-no-properties],
Richard Stallman <=