* [ghill@synergymicro.com: Re: Re: bug in field-string and field-string-no-properties]
@ 2003-08-27 22:12 Richard Stallman
2003-08-28 21:32 ` Fwd: Re: Re: bug in field-string and field-string-no-properties Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2003-08-27 22:12 UTC (permalink / raw)
Cc: emacs-devel
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 -------
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fwd: Re: Re: bug in field-string and field-string-no-properties 2003-08-27 22:12 [ghill@synergymicro.com: Re: Re: bug in field-string and field-string-no-properties] Richard Stallman @ 2003-08-28 21:32 ` Stefan Monnier 2003-08-29 2:20 ` Greg Hill 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2003-08-28 21:32 UTC (permalink / raw) Cc: auto-added, emacs-devel, monnier, miles > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fwd: Re: Re: bug in field-string and field-string-no-properties 2003-08-28 21:32 ` Fwd: Re: Re: bug in field-string and field-string-no-properties Stefan Monnier @ 2003-08-29 2:20 ` Greg Hill 2003-08-29 2:36 ` Miles Bader 0 siblings, 1 reply; 6+ messages in thread From: Greg Hill @ 2003-08-29 2:20 UTC (permalink / raw) Cc: emacs-devel, monnier, miles 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in field-string and field-string-no-properties 2003-08-29 2:20 ` Greg Hill @ 2003-08-29 2:36 ` Miles Bader 2003-08-29 18:53 ` Kevin Rodgers 2003-08-29 21:55 ` Greg Hill 0 siblings, 2 replies; 6+ messages in thread From: Miles Bader @ 2003-08-29 2:36 UTC (permalink / raw) Cc: emacs-devel, Stefan Monnier, monnier, Richard Stallman 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" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in field-string and field-string-no-properties 2003-08-29 2:36 ` Miles Bader @ 2003-08-29 18:53 ` Kevin Rodgers 2003-08-29 21:55 ` Greg Hill 1 sibling, 0 replies; 6+ messages in thread From: Kevin Rodgers @ 2003-08-29 18:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in field-string and field-string-no-properties 2003-08-29 2:36 ` Miles Bader 2003-08-29 18:53 ` Kevin Rodgers @ 2003-08-29 21:55 ` Greg Hill 1 sibling, 0 replies; 6+ messages in thread From: Greg Hill @ 2003-08-29 21:55 UTC (permalink / raw) Cc: emacs-devel, Stefan Monnier, monnier, Richard Stallman 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" ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-08-29 21:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-08-27 22:12 [ghill@synergymicro.com: Re: Re: bug in field-string and field-string-no-properties] Richard Stallman 2003-08-28 21:32 ` Fwd: Re: Re: bug in field-string and field-string-no-properties Stefan Monnier 2003-08-29 2:20 ` Greg Hill 2003-08-29 2:36 ` Miles Bader 2003-08-29 18:53 ` Kevin Rodgers 2003-08-29 21:55 ` Greg Hill
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).