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

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

bug#24179: 24179


From: Eli Zaretskii
Subject: bug#24179: 24179
Date: Thu, 11 Aug 2016 20:15:15 +0300

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Thu, 11 Aug 2016 18:39:54 +0200
> 
> (with-current-buffer (get-buffer-create "demo")
>   (pop-to-buffer (current-buffer))
>   (erase-buffer)
>   (insert "one\ntwo\nthree")
>   (backward-word 2)
>   (let ((ov (make-overlay (point)
>                           (save-excursion
>                             (forward-line 1)
>                             (point))))
>         (heading "before two\n"))
>     (put-text-property 0 1 'cursor (length heading) heading)
>     (overlay-put ov 'before-string heading)
>     (overlay-put ov 'the-value "two")
>     (overlay-put ov 'evaporate t)))
> 
> However I would then expect that it would become possible for the cursor
> to be displayed "on" the "b" because of this: "In other words, the
> string character with the ‘cursor’ property of any non-‘nil’ value is
> the character where to display the cursor.  The value of the property
> says for which buffer positions to display the cursor there."
> 
> one
> *efore two
> two
> three
> 
> That would be a change in behavior* but I am not seeing any change so I
> am unsure whether I am doing this all wrong.  If so, then please correct
> the above code.

It looks like I misremembered: before-strings cannot benefit from this
feature, because they don't conceal any buffer positions.  Emacs only
considers the cursor property when the buffer position of point is not
visible on the screen, so you need to use 'display' properties.  Sorry
about that.

Here's an example that will allow you to experiment:

 (setq s1 "<dot>")
 (setq s2 (concat "<c" (propertize "o" 'cursor t) "mma>"))
 (setq c1 (propertize "..." 'display s1))
 (setq c2 (propertize ",,," 'display s2))
 (insert "abc" c1 "def" c2 "xyz" c1 c2 "123" c2 "456" c1 c2 c1 "789" c2 "end\n")


> * However if that is possible, I would prefer to use the `cursor'
> property to provide the hint to the display engine that the cursor
> should keep ending up here (as it does without fiddling with `cursor' at
> all):
> 
> one
> before two
> *wo
> three

That already happens, doesn't it?





reply via email to

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