bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49742: 28.0.50; previous-single-property-change sometimes wrong?


From: T.V Raman
Subject: bug#49742: 28.0.50; previous-single-property-change sometimes wrong?
Date: Mon, 26 Jul 2021 10:19:13 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:


See below for the results you ask. It does not explain itself because
property 'face is nil at positions  30 and 29.

Contents of help buffer after describe-text-properties below:
Text content at position 28:


Here is a ??nil?? button labeled ??)??.


There are text properties here:
  button               (t)
  category             transient-button-button
  command              magit-log:-L

[back]

>> Date: Mon, 26 Jul 2021 08:47:07 -0700
>> From:  "T.V Raman" via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> 
>> This appears to a corner case where previous-single-property-change
>> breaks in a surprizing way.
>> 
>> 1. ;;; Evaluate the below to get a string with properties.
>> (setq s
>> 
>> #("-L Trace line evolution (-L)
>> 
>> History simplification" 0 2 (face transient-blue button (t) category 
>> transient-button-button command magit-log:-L) 2 25 (button (t) category 
>> transient-button-button command magit-log:-L) 25 27 (face 
>> transient-inactive-value button (t) category transient-button-button command 
>> magit-log:-L) 27 28 (button (t) category transient-button-button command 
>> magit-log:-L) 30 52 (face transient-heading)))
>> 
>> 
>> 2.;;; Insert into a new buffer
>> (switch-to-buffer "foo")
>> (insert s)
>> 
>> 4. ;;; Place point on the 'H' of "history"
>> 
>>    5. ;;; eval
>>    (previous-single-property-change (point 'face)
>> 
>>    Instead of returning value of point before the 'H', this returns a
>>    value that is unexpected, it returns point  past the ')'
>
> What does "M-x describe-text-properties RET" say at the position
> returned by the above previous-single-property-change call?  Does that
> value explain the result?  If not, why not?

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
?7?4 Id: kg:/m/0285kf1  ?0?8





reply via email to

[Prev in Thread] Current Thread [Next in Thread]