* set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
@ 2005-12-28 21:59 Drew Adams
2005-12-29 3:18 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Drew Adams @ 2005-12-28 21:59 UTC (permalink / raw)
1. The set-text-properties doc string should say what the function returns.
2. Wouldn't it be more useful for set-text-properties,
remove-set-properties, and add-text-properties to return the modified OBJECT
(or nil if no modification occurred)? In case OBJECT is a buffer (or nil),
the modified buffer substring could be returned.
Perhaps it's too late to make the change in #2, if existing code depends on
the current value - but maybe not:
- In the case of set-text-properties, that value is not even documented.
- In the case of remove-set-properties and add-text-properties, perhaps
existing code only tests whether the returned value is null (instead of
testing equality with t).
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-28 21:59 set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value Drew Adams
@ 2005-12-29 3:18 ` Stefan Monnier
2005-12-29 4:15 ` Drew Adams
2005-12-29 11:10 ` Kim F. Storm
0 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier @ 2005-12-29 3:18 UTC (permalink / raw)
Cc: Emacs-Devel
> 1. The set-text-properties doc string should say what the function returns.
Why?
> 2. Wouldn't it be more useful for set-text-properties,
> remove-set-properties, and add-text-properties to return the modified
> OBJECT (or nil if no modification occurred)? In case OBJECT is a buffer
> (or nil), the modified buffer substring could be returned.
Why would that be useful?
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-29 3:18 ` Stefan Monnier
@ 2005-12-29 4:15 ` Drew Adams
2005-12-30 2:18 ` Richard M. Stallman
2005-12-29 11:10 ` Kim F. Storm
1 sibling, 1 reply; 14+ messages in thread
From: Drew Adams @ 2005-12-29 4:15 UTC (permalink / raw)
> 1. The set-text-properties doc string should say what the
> function returns.
Why?
I should have said, "Does the value of set-text-properties change, or is it
always the same? If it changes, then the value is significant and it should
be documented."
> 2. Wouldn't it be more useful for set-text-properties,
> remove-set-properties, and add-text-properties to return the modified
> OBJECT (or nil if no modification occurred)? In case OBJECT
> is a buffer (or nil), the modified buffer substring could be returned.
Why would that be useful?
Why is it useful for `push' and `pop' to return values that correspond to
the updated list and the removed car?
It would be convenient to say
(setq foo (or (remove-text-properties start end props toto) ...))
Of course, you can always write
(setq foo (if (remove-text-properties start end props toto)
toto
...))
As for `push' and `pop' and many other "functions", returning a richer value
offers only a slight convenience, but why not?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-29 3:18 ` Stefan Monnier
2005-12-29 4:15 ` Drew Adams
@ 2005-12-29 11:10 ` Kim F. Storm
2005-12-29 16:03 ` Drew Adams
1 sibling, 1 reply; 14+ messages in thread
From: Kim F. Storm @ 2005-12-29 11:10 UTC (permalink / raw)
Cc: Drew Adams, Emacs-Devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 2. Wouldn't it be more useful for set-text-properties,
>> remove-set-properties, and add-text-properties to return the modified
>> OBJECT (or nil if no modification occurred)? In case OBJECT is a buffer
>> (or nil), the modified buffer substring could be returned.
>
> Why would that be useful?
Even if it was useful in some cases, it would be extremely wasteful in general.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-29 11:10 ` Kim F. Storm
@ 2005-12-29 16:03 ` Drew Adams
2005-12-29 19:41 ` Kevin Rodgers
2005-12-29 22:41 ` Kim F. Storm
0 siblings, 2 replies; 14+ messages in thread
From: Drew Adams @ 2005-12-29 16:03 UTC (permalink / raw)
>> 2. Wouldn't it be more useful for set-text-properties,
>> remove-set-properties, and add-text-properties to return the modified
>> OBJECT (or nil if no modification occurred)? In case OBJECT
>> is a buffer (or nil), the modified buffer substring could be
returned.
>
> Why would that be useful?
Even if it was useful in some cases, it would be extremely
wasteful in general.
I believe you, but could you explain why, so I can learn? I don't know much
about how C interfaces with Lisp. Is it because a new OBJECT would in fact
need to be created? I was thinking that the operation could just return (the
equivalent of) a pointer to the original OBJECT. IOW, where is the waste?
I guess, in the case of a buffer, a new string would need to be created. Is
that what you meant, or is there also a problem when the OBJECT (string)
argument is explicitly supplied?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-29 16:03 ` Drew Adams
@ 2005-12-29 19:41 ` Kevin Rodgers
2005-12-30 0:57 ` Juri Linkov
2005-12-29 22:41 ` Kim F. Storm
1 sibling, 1 reply; 14+ messages in thread
From: Kevin Rodgers @ 2005-12-29 19:41 UTC (permalink / raw)
Drew Adams wrote:
> >> 2. Wouldn't it be more useful for set-text-properties,
> >> remove-set-properties, and add-text-properties to return the modified
> >> OBJECT (or nil if no modification occurred)? In case OBJECT
> >> is a buffer (or nil), the modified buffer substring could be
> returned.
> >
> > Why would that be useful?
>
> Even if it was useful in some cases, it would be extremely
> wasteful in general.
>
> I believe you, but could you explain why, so I can learn? I don't know much
> about how C interfaces with Lisp. Is it because a new OBJECT would in fact
> need to be created? I was thinking that the operation could just return (the
> equivalent of) a pointer to the original OBJECT. IOW, where is the waste?
>
> I guess, in the case of a buffer, a new string would need to be created. Is
> that what you meant, or is there also a problem when the OBJECT (string)
> argument is explicitly supplied?
Exactly. I think it should just return OBJECT, whether that is a buffer
(or the current buffer, when nil) or a string.
--
Kevin Rodgers
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-29 16:03 ` Drew Adams
2005-12-29 19:41 ` Kevin Rodgers
@ 2005-12-29 22:41 ` Kim F. Storm
1 sibling, 0 replies; 14+ messages in thread
From: Kim F. Storm @ 2005-12-29 22:41 UTC (permalink / raw)
Cc: Emacs-Devel
"Drew Adams" <drew.adams@oracle.com> writes:
> I guess, in the case of a buffer, a new string would need to be created.
Exactly -- and a string with all properties duplicated. Very wasteful, since
the value would be discarded in most (all) cases.
> Is
> that what you meant, or is there also a problem when the OBJECT (string)
> argument is explicitly supplied?
Not performancewise, but IMO it is not worth the efforts to change this just
for the string case.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-29 19:41 ` Kevin Rodgers
@ 2005-12-30 0:57 ` Juri Linkov
2006-02-18 19:37 ` Drew Adams
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2005-12-30 0:57 UTC (permalink / raw)
Cc: emacs-devel
> Exactly. I think it should just return OBJECT, whether that is a buffer
> (or the current buffer, when nil) or a string.
I agree. `propertize' returns its input argument with added properties.
So why `add-text-properties', `set-text-properties' can't do the same.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-29 4:15 ` Drew Adams
@ 2005-12-30 2:18 ` Richard M. Stallman
2005-12-30 3:47 ` Luc Teirlinck
2005-12-30 3:57 ` Luc Teirlinck
0 siblings, 2 replies; 14+ messages in thread
From: Richard M. Stallman @ 2005-12-30 2:18 UTC (permalink / raw)
Cc: emacs-devel
I can see from the C source that set-text-properties returns t
if that text had any properties before, nil if it had none.
I am not sure whether this is useful to document.
Now is not the time to consider changing the return value.
This is not a new feature, and the current value is not a bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-30 2:18 ` Richard M. Stallman
@ 2005-12-30 3:47 ` Luc Teirlinck
2005-12-30 3:57 ` Luc Teirlinck
1 sibling, 0 replies; 14+ messages in thread
From: Luc Teirlinck @ 2005-12-30 3:47 UTC (permalink / raw)
Cc: drew.adams, emacs-devel
Richard Stallman wrote:
I can see from the C source that set-text-properties returns t
if that text had any properties before, nil if it had none.
Well, it is a little bit more complex than that. It returns nil if
the _entire_ string or buffer had no text properties and the
PROPERTIES arg is nil. But it also returns nil if set-text-properties
specifies an empty interval. I believe that the function returns nil
if it _knows_ that no text properties were changed, but that it makes
no effort to determine reliably whether any text properties were
changed.
There is an inconsistency. If a string has no text properties and
set-text-properties wants to remove all text-properties from _part_ of
the string, the return value is nil (makes sense). If it wants to
remove them from the entire string, the return value is t (makes no
sense):
ELISP> (setq str "123456789")
"123456789"
ELISP> (set-text-properties 0 9 nil str)
t
ELISP> (set-text-properties 0 8 nil str)
nil
This appears to be a small buglet. The patch below fixes the buglet
and documents, I believe, the return value more accurately. I can
install if desired.
===File ~/textprop.c-diff===================================
*** textprop.c 07 Aug 2005 10:28:42 -0500 1.143
--- textprop.c 29 Dec 2005 21:04:56 -0600
***************
*** 1316,1323 ****
properties PROPERTIES. OBJECT is the buffer or string containing
the text. OBJECT nil means use the current buffer.
SIGNAL_AFTER_CHANGE_P nil means don't signal after changes. Value
! is non-nil if properties were replaced; it is nil if there weren't
! any properties to replace. */
Lisp_Object
set_text_properties (start, end, properties, object, signal_after_change_p)
--- 1316,1323 ----
properties PROPERTIES. OBJECT is the buffer or string containing
the text. OBJECT nil means use the current buffer.
SIGNAL_AFTER_CHANGE_P nil means don't signal after changes. Value
! is nil if the function _knows_ that it did not replace any
! properties, non-nil otherwise. */
Lisp_Object
set_text_properties (start, end, properties, object, signal_after_change_p)
***************
*** 1341,1347 ****
&& XFASTINT (end) == SCHARS (object))
{
if (! STRING_INTERVALS (object))
! return Qt;
STRING_SET_INTERVALS (object, NULL_INTERVAL);
return Qt;
--- 1341,1347 ----
&& XFASTINT (end) == SCHARS (object))
{
if (! STRING_INTERVALS (object))
! return Qnil;
STRING_SET_INTERVALS (object, NULL_INTERVAL);
return Qt;
============================================================
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-30 2:18 ` Richard M. Stallman
2005-12-30 3:47 ` Luc Teirlinck
@ 2005-12-30 3:57 ` Luc Teirlinck
2005-12-30 11:24 ` David Kastrup
1 sibling, 1 reply; 14+ messages in thread
From: Luc Teirlinck @ 2005-12-30 3:57 UTC (permalink / raw)
Cc: drew.adams, emacs-devel
Richard Stallman wrote:
I am not sure whether this is useful to document.
I do not believe that the return value is very useful (given that only
a nil return value provides any reliable info). But since the return
value is sometimes nil and sometimes t, it might be good to document
it, just to avoid a situation where a user _believes_ that he
understands the return value and writes code relying on his mistaken
belief.
I could add:
This function returns nil if it _knows_ that it did not replace any
properties, non-nil otherwise.
to both the docstring and the Elisp manual, if desired.
Sincerely,
Luc.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-30 3:57 ` Luc Teirlinck
@ 2005-12-30 11:24 ` David Kastrup
0 siblings, 0 replies; 14+ messages in thread
From: David Kastrup @ 2005-12-30 11:24 UTC (permalink / raw)
Cc: rms, drew.adams, emacs-devel
Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> I could add:
>
> This function returns nil if it _knows_ that it did not replace any
> properties, non-nil otherwise.
>
> to both the docstring and the Elisp manual, if desired.
Since the programmer has no way of guessing what a function might or
might not know (interesting word choice, anyway), this sounds like the
worst of all solutions.
I'd rather have "no useful value is returned".
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2005-12-30 0:57 ` Juri Linkov
@ 2006-02-18 19:37 ` Drew Adams
2006-02-19 15:14 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Drew Adams @ 2006-02-18 19:37 UTC (permalink / raw)
> Exactly. I think it should just return OBJECT, whether that
> is a buffer (or the current buffer, when nil) or a string.
I agree. `propertize' returns its input argument with added
properties. So why `add-text-properties', `set-text-properties'
can't do the same.
Sorry to stir this pot again. I have the same question now for
`put-text-property'. It seems to always return nil (true? - the doc string
says nothing about its return value).
What about giving some meaning to the value returned by `put-text-property'?
What about using a return value like `propertize' uses - that is, return the
OBJECT?
As Richard mentioned for `set-text-properties', this would be a new feature,
not a bug fix, so it would be for after the release.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value
2006-02-18 19:37 ` Drew Adams
@ 2006-02-19 15:14 ` Stefan Monnier
0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2006-02-19 15:14 UTC (permalink / raw)
Cc: emacs-devel
> What about giving some meaning to the value returned by `put-text-property'?
> What about using a return value like `propertize' uses - that is, return the
> OBJECT?
What for? How often would that be useful?
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-02-19 15:14 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-28 21:59 set-text-properties, remove-set-properties, add-text-properties: 1) doc string 2) return value Drew Adams
2005-12-29 3:18 ` Stefan Monnier
2005-12-29 4:15 ` Drew Adams
2005-12-30 2:18 ` Richard M. Stallman
2005-12-30 3:47 ` Luc Teirlinck
2005-12-30 3:57 ` Luc Teirlinck
2005-12-30 11:24 ` David Kastrup
2005-12-29 11:10 ` Kim F. Storm
2005-12-29 16:03 ` Drew Adams
2005-12-29 19:41 ` Kevin Rodgers
2005-12-30 0:57 ` Juri Linkov
2006-02-18 19:37 ` Drew Adams
2006-02-19 15:14 ` Stefan Monnier
2005-12-29 22:41 ` Kim F. Storm
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.