3:06 p.m.
XEmacs 21.5 has next-single-char-property-change that behaves
differently from the version in emacs. When there is no
next-single-char-property-change, XEmacs returns nil. But Emacs
(according the docstring) returns the end of the object. Similarly,
previous-single-char-property-change has the same problem.
Is this difference intentional? FWIW, it breaks slime, which assumes
Emacs' behavior. For right now, I'm just doing
(or (next-single-char-property-change <args>) (point-max))
which works for slime.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:36 a.m.
Ar an deichiú lá de mí Feabhra, scríobh Raymond Toy:
XEmacs 21.5 has next-single-char-property-change that behaves
differently from the version in emacs. When there is no
next-single-char-property-change, XEmacs returns nil. But Emacs
(according the docstring) returns the end of the object. Similarly,
previous-single-char-property-change has the same problem.
Is this difference intentional? FWIW, it breaks slime, which assumes
Emacs' behavior. For right now, I'm just doing
It’s not intentional, as far as I can see.
http://hg.debian.org/hg/xemacs/xemacs/rev/8c96bdabcaf9 is the changeset
where Ben implemented the {next,previous}-single-char-property-change, and
the intention seems to have been to be compatible with GNU.
(or (next-single-char-property-change <args>) (point-max))
which works for slime.
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:09 p.m.
Raymond Toy writes:
Is this difference intentional? FWIW, it breaks slime, which
assumes
Emacs' behavior. For right now, I'm just doing
(or (next-single-char-property-change <args>) (point-max))
Is this behavior actually useful?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:57 p.m.
On 2/11/11 8:09 AM, Stephen J. Turnbull wrote:
Raymond Toy writes:
> Is this difference intentional? FWIW, it breaks slime, which assumes
> Emacs' behavior. For right now, I'm just doing
>
> (or (next-single-char-property-change <args>) (point-max))
Is this behavior actually useful?
Yes. Slime basically does (goto-char (next-single-char-property-change
<args>)), which obviously breaks with xemacs when n-s-c-p-c returns
nil. The args don't include the object parameter, and thus defaults to
the current buffer. (point-max) should be the right thing, then, I
think. At least emacs says n-s-c-p-c is supposed to return the end of
the object when there is no more n-s-c-p-c.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:29 p.m.
Raymond Toy writes:
> Is this behavior actually useful?
Yes. Slime basically does (goto-char
(next-single-char-property-change
<args>)), which obviously breaks with xemacs when n-s-c-p-c returns
nil.
Sure. But my question is, "is it useful to end up at the end of the
buffer if there are no more property changes?" This is basically a
search function, and there are four behaviors I can think of here:
error, go to end of text, wrap around, do nothing. The first is worse
than useless, but it's not obvious a priori that "return end of text"
has an advantage over the other two except to avoid a trivial change:
;; the "or" is a no-op in Emacs
(goto-char (or (next-single-char-property-change ...)
(the-place-slime-really-wants-to-be)))
At least emacs says n-s-c-p-c is supposed to return the end of the
object when there is no more n-s-c-p-c.
It's arguable this is not very useful, since that behavior is already
available in XEmacs:
(next-single-char-property-change POS PROP nil (point-max))
So the question is really, is the code of the form
(while (not (eobp))
(goto-char (next-single-char-property-change (point) PROP))
;; It's useful to do something at eob! Do it there too!
(do-something))
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:03 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Raymond Toy writes:
> > Is this behavior actually useful?
> Yes. Slime basically does (goto-char (next-single-char-property-change
> <args>)), which obviously breaks with xemacs when n-s-c-p-c returns
> nil.
Sure. But my question is, "is it useful to end up at the end of the
buffer if there are no more property changes?" This is basically a
search function, and there are four behaviors I can think of here:
error, go to end of text, wrap around, do nothing. The first is worse
than useless, but it's not obvious a priori that "return end of text"
has an advantage over the other two except to avoid a trivial change:
;; the "or" is a no-op in Emacs
(goto-char (or (next-single-char-property-change ...)
(the-place-slime-really-wants-to-be)))
> At least emacs says n-s-c-p-c is supposed to return the end of the
> object when there is no more n-s-c-p-c.
It's arguable this is not very useful, since that behavior is already
available in XEmacs:
(next-single-char-property-change POS PROP nil (point-max))
So the question is really, is the code of the form
(while (not (eobp))
(goto-char (next-single-char-property-change (point) PROP))
;; It's useful to do something at eob! Do it there too!
(do-something))
It may be worth pointing out that for XEmacs, text properties and
overlays are the same.
Emacs has (for just text properties):
next-single-property-change is a built-in function in `C source code'.
(next-single-property-change POSITION PROP &optional OBJECT LIMIT)
Return the position of next property change for a specific property.
[...]
Return nil if the property is constant all the way to the end of OBJECT.
and it has for either text properties and overlays (namely as something
with purportedly more compatibility to XEmacs):
next-single-char-property-change is a built-in function in `C source
code'.
(next-single-char-property-change POSITION PROP &optional OBJECT
LIMIT)
Return the position of next text property or overlay change for a
specific property.
If the property is constant all the way to the end of OBJECT, return the
last valid position in OBJECT.
As well as
next-overlay-change is a built-in function in `C source code'.
(next-overlay-change POS)
Return the next position after POS where an overlay starts or ends.
If there are no overlay boundaries from POS to (point-max),
the value is (point-max).
If you ask me, it might make sense to ask the Emacs camp whether there
any plans for improving the coherence of the above before deciding how
to mimic what.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:02 p.m.
Raymond Toy <toy.raymond(a)gmail.com> writes:
When there is no next-single-char-property-change, XEmacs returns
nil.
But Emacs (according the docstring) returns the end of the object.
Not sure if I fully understood the mechanics behind extents and
text-properties, but wouldn't it make sense to be able to tell the
difference between a text-property whose proper end-position happens to
be the end of an object, and a text-property that was cut off? In a
narrowed region for instance?
Marcus
--
(an unmatched left parenthesis will leave an unresolved tension
that will stay with you all day
-- http://xkcd.com/859/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:18 a.m.
Marcus Harnisch <marcus.harnisch(a)xemacs.org> writes:
Raymond Toy <toy.raymond(a)gmail.com> writes:
> When there is no next-single-char-property-change, XEmacs returns nil.
> But Emacs (according the docstring) returns the end of the object.
Not sure if I fully understood the mechanics behind extents and
text-properties, but wouldn't it make sense to be able to tell the
difference between a text-property whose proper end-position happens to
be the end of an object, and a text-property that was cut off? In a
narrowed region for instance?
Well, the Emacs equivalents are different here: text properties are
(surprise, surprise) properties of the individual characters, not of the
enclosing object. So this "difference" between "end-position" and
"cut
off" does not make sense here. In contrast, overlays are properties of
the enclosing object (supported only for buffers and, in some limited
sense, windows).
There is some limited approximation of that "difference" available by
looking at the question "would inserting a character here inherit the
text properties from the preceding character?".
But it is an approximation.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:22 p.m.
David Kastrup writes:
Well, the Emacs equivalents are different here: text properties are
(surprise, surprise) properties of the individual characters,
Conceptually they are in XEmacs as well; the implementation is
different (heavier weight).
not of the enclosing object. So this "difference" between
"end-position" and "cut off" does not make sense here.
IMO it does. If the fact that text properties are conceptually
properties of single characters means that "end position" vs. "cut
off" doesn't make sense for text properties, then ISTM the whole "next
change" idea doesn't make sense for text properties.
I don't know if it's useful to make that distinction, though.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5030
days inactive
5034
days old
8 comments
5 participants
participants (5)
-
Aidan Kehoe -
David Kastrup -
Marcus Harnisch -
Raymond Toy -
Stephen J. Turnbull