bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry]

(let ((pt (point)))
  (insert (propertize "a" 'display "bbb"))
  (let ((o (make-overlay pt (point))))
    (overlay-put o 'invisible t)
    (overlay-put o 'after-string "foo\nbar")))

The result looks like this:

foo
barbbbfoo
bar

It's the same if I use `before-string' instead of `after-string', but
not `display'.

If I don't set the `invisible' property, it's just

bbbfoo
bar

If I replace (make-overlay pt (point)) with (make-overlay (1- pt)
(point)), the result it, expectedly:

foo
bar

This bug is present in Emacs 24.3, too (so not a regression).

In GNU Emacs 24.3.92.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-08-06 on axl
Repository revision: 117425 eliz@gnu.org-20140805133406-w7477hyd1gl9h1d7
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

bug#18285: Acknowledgement (24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice)

[Dmitry Gutov]

Clarification: this part -

   If I replace (make-overlay pt (point)) with (make-overlay (1- pt)
   (point)), the result it, expectedly...

- is only true when (> pt (point-min)), e.g. when we started at the end 
of a non-empty buffer.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> From: Dmitry <dgutov@yandex.ru>
> Date: Mon, 18 Aug 2014 02:35:06 +0400
> 
> (let ((pt (point)))
>   (insert (propertize "a" 'display "bbb"))
>   (let ((o (make-overlay pt (point))))
>     (overlay-put o 'invisible t)
>     (overlay-put o 'after-string "foo\nbar")))
> 
> The result looks like this:
> 
> foo
> barbbbfoo
> bar

Believe it or not, but this is how the code was written 14 years ago,
although perhaps this particular consequence wasn't intended.  But it
follows logically from how the display engine works.

The fundamental issue here is that the 'invisible' property makes all
the character positions between the start and the end of the overlay
indistinguishable.  Therefore, the display engine considers the
'before-string' and 'after-string' of an overlay that spans invisible
text to be applicable to both the start and the end of the overlay,
something it wouldn't do if the 'invisible' property were not present.

So what happens is this:

 . we find the 'display' property and arrange for it to be displayed

 . before displaying the 'display' property string, we check for
   overlay strings, and find the 'after-string' whose overlay starts
   at the same position; since its overlay has the 'invisible'
   property, we consider the 'after-string' in effect for the start of
   the overlay, and display that string

 . we display the 'display' string

 . we are going to continue display of the buffer starting at the
   position where the 'display' property ends

 . we check for overlays at that position, and again find the same
   'after-string' because its overlay _ends_ at that buffer position,
   so we display that string again

So you are actually shooting yourself in the foot by using the
'invisible' property here.  Doing that is redundant here, because the
'display' property already makes the text it "covers" invisible.

I think it's not worth to try to fix this (by complicating the heck
out of the display engine) on the account of this use case.

If you have other similar use cases, where simply refraining from
using 'invisible' won't help, please show them.

> It's the same if I use `before-string' instead of `after-string', but
> not `display'.
> 
> If I don't set the `invisible' property, it's just
> 
> bbbfoo
> bar

My crystal ball says you get

 bbbfoo
 bar

only with 'after-string'.  With 'before-string', you should get

 foo
 barbbb

instead.  IOW, without the 'invisible' property getting in the way,
the 'before-string' is displayed before the display property, and
the 'after-string' is displayed after it.

Btw, there was a discussion of a similar issue starting at

  http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00674.html

It was inconclusive.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/18/2014 07:07 PM, Eli Zaretskii wrote:

> Believe it or not, but this is how the code was written 14 years ago,
> although perhaps this particular consequence wasn't intended.  But it
> follows logically from how the display engine works.

I can believe it all right. I guess the question is, could there be a 
modification of the current logic that would preserve most of the 
current behavior, except for the weird situations like this one.

If not, that's all right by me. The workaround of replacing 
`before-string' + `invisible' with just `display' seems to function just 
fine so far. For some reason, Nikolaj opted to render the completion 
tooltip in Company with the former option, so I tried not to change it 
too much. Maybe that worked around some bugs in older Emacs, which we 
don't support anymore.

> The fundamental issue here is that the 'invisible' property makes all
> the character positions between the start and the end of the overlay
> indistinguishable.  Therefore, the display engine considers the
> 'before-string' and 'after-string' of an overlay that spans invisible
> text to be applicable to both the start and the end of the overlay,
> something it wouldn't do if the 'invisible' property were not present.

Hmm. Maybe the fix could be to make the `invisible' property disable 
`display': as long as former is present, the latter won't work.

After all, that was the intention behind the code I encountered this bug 
in. And with the current logic, like you say, if `display' is set, 
`invisible' is redundant.

> I think it's not worth to try to fix this (by complicating the heck
> out of the display engine) on the account of this use case.

Maybe so, but see above.

> My crystal ball says ...
> ... IOW, without the 'invisible' property getting in the way,
> the 'before-string' is displayed before the display property, and
> the 'after-string' is displayed after it.

Yes, sure. I just meant that the bug is the same with `invisible' on.

> Btw, there was a discussion of a similar issue starting at
>
>    http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00674.html
>
> It was inconclusive.

Thanks. That looks very much like a bug as well, though maybe again, too 
expensive to fix. FWIW, for that issue, if myov2 has higher priority 
than myov1 (if only by virtue of being inside and shorter), I'd display 
just "STRING2" ("STRING1" would not be visible at all). But that's just 
going by logic; maybe there's a use case that would break.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> Date: Thu, 21 Aug 2014 18:07:07 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> On 08/18/2014 07:07 PM, Eli Zaretskii wrote:
> 
> > Believe it or not, but this is how the code was written 14 years ago,
> > although perhaps this particular consequence wasn't intended.  But it
> > follows logically from how the display engine works.
> 
> I can believe it all right. I guess the question is, could there be a 
> modification of the current logic that would preserve most of the 
> current behavior, except for the weird situations like this one.

Not easily.  This is one of the most complicated spots in the display
engine, with "many similar passages all alike".  Each display feature
(faces, display properties, invisible, overlays, etc.) is handled by
its own handler, which knows nothing about the other handlers.  On top
of that, you could have a display property on an overlay string, so
the potential combinations are countless.

> > The fundamental issue here is that the 'invisible' property makes all
> > the character positions between the start and the end of the overlay
> > indistinguishable.  Therefore, the display engine considers the
> > 'before-string' and 'after-string' of an overlay that spans invisible
> > text to be applicable to both the start and the end of the overlay,
> > something it wouldn't do if the 'invisible' property were not present.
> 
> Hmm. Maybe the fix could be to make the `invisible' property disable 
> `display': as long as former is present, the latter won't work.

That would undoubtedly cause complaints from heavy users of those,
like Org, magit, etc.

The current code does it the other way around: the invisible property
is almost ignored when there's a display property on the same text.
"Almost" because, as I explained, the mere fact of the presence of
invisible text affects how before-string and after-string are handled.

> After all, that was the intention behind the code I encountered this bug 
> in. And with the current logic, like you say, if `display' is set, 
> `invisible' is redundant.

Yes, but not the other way around.

> >    http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00674.html
> >
> > It was inconclusive.
> 
> Thanks. That looks very much like a bug as well, though maybe again, too 
> expensive to fix. FWIW, for that issue, if myov2 has higher priority 
> than myov1 (if only by virtue of being inside and shorter), I'd display 
> just "STRING2" ("STRING1" would not be visible at all). But that's just 
> going by logic; maybe there's a use case that would break.

I'm quite sure there's some use case somewhere that will break.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/21/2014 06:57 PM, Eli Zaretskii wrote:

>> Hmm. Maybe the fix could be to make the `invisible' property disable
>> `display': as long as former is present, the latter won't work.
>
> That would undoubtedly cause complaints from heavy users of those,
> like Org, magit, etc.

Some change in code might be required, but the resulting code can be 
made backward-compatible, aside from the pathological examples, which 
might improve.

>> After all, that was the intention behind the code I encountered this bug
>> in. And with the current logic, like you say, if `display' is set,
>> `invisible' is redundant.
>
> Yes, but not the other way around.

If the `invisible' starts even one character earlier, it *is* the other 
way around. So one might say that in general case it already disables 
`display'. Try this small modification of the original example:

(let ((pt (point)))
   (insert (propertize "a" 'display "bbb"))
   (let ((o (make-overlay (1- pt) (point))))
     (overlay-put o 'invisible t)
     (overlay-put o 'after-string "foo\nbar")))

The result looks like:

foo
bar

>> Thanks. That looks very much like a bug as well, though maybe again, too
>> expensive to fix. FWIW, for that issue, if myov2 has higher priority
>> than myov1 (if only by virtue of being inside and shorter), I'd display
>> just "STRING2" ("STRING1" would not be visible at all). But that's just
>> going by logic; maybe there's a use case that would break.
>
> I'm quite sure there's some use case somewhere that will break.

Maybe. But at least it's consistent with the overlay priority rules.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> Date: Thu, 21 Aug 2014 19:40:58 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> >> After all, that was the intention behind the code I encountered this bug
> >> in. And with the current logic, like you say, if `display' is set,
> >> `invisible' is redundant.
> >
> > Yes, but not the other way around.
> 
> If the `invisible' starts even one character earlier, it *is* the other 
> way around.

Yes, because then there's no doubt about the order of evaluating the
various properties and acting upon them.  By contrast, when they all
begin at the same buffer position, the order is
implementation-defined.  The code is written to examine display
properties before the invisible properties.

> >> Thanks. That looks very much like a bug as well, though maybe again, too
> >> expensive to fix. FWIW, for that issue, if myov2 has higher priority
> >> than myov1 (if only by virtue of being inside and shorter), I'd display
> >> just "STRING2" ("STRING1" would not be visible at all). But that's just
> >> going by logic; maybe there's a use case that would break.
> >
> > I'm quite sure there's some use case somewhere that will break.
> 
> Maybe. But at least it's consistent with the overlay priority rules.

The priority is _per_buffer_position_.  We tend to forget that text
properties and overlays in Emacs are _character_ properties, but the
display engine is designed and implemented to support that, and in
some obscure cases, like this one, it is impossible to understand its
logic, unless one remembers this simple fact.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/21/2014 08:06 PM, Eli Zaretskii wrote:

>> If the `invisible' starts even one character earlier, it *is* the other
>> way around.
>
> Yes, because then there's no doubt about the order of evaluating the
> various properties and acting upon them.  By contrast, when they all
> begin at the same buffer position, the order is
> implementation-defined.  The code is written to examine display
> properties before the invisible properties.

Okay, but I'll take this to mean that hitting the changed behavior in 
existing code would be pretty rare.

Anyway, how about the other way around? I'll like this less, but why not 
make `invisible' inactive when `display' is set?

This works is a more consistent fashion, and the text that would be 
invisible ("a") is replaced by `display' anyway:

(let ((pt (point)))
   (insert (propertize "a" 'display "bbb"))
   (let ((o (make-overlay pt (point))))
     (overlay-put o 'after-string "foo\nbar")))

looks like

bbbfoo
bar

>> Maybe. But at least it's consistent with the overlay priority rules.
>
> The priority is _per_buffer_position_.  We tend to forget that text
> properties and overlays in Emacs are _character_ properties, but the
> display engine is designed and implemented to support that, and in
> some obscure cases, like this one, it is impossible to understand its
> logic, unless one remembers this simple fact.

I'm just quoting Stefan from that discussion:

"""
Same problem: for two overlays of equal `priority', the shorter one has
higher priority, so your original example is already one of those
cases, AFAIC.
"""

Like in this example:

(let ((pt (point)))
   (insert "aaa")
   (let ((o (make-overlay pt (point))) (v (make-overlay (1+ pt) (1- 
(point)))))
     (overlay-put o 'face 'bold)
     (overlay-put v 'face 'default)))

the middle character has normal weight, even though it's also covered by 
an outer overlay that sets `face' to `bold'.

So, if I had to pick which single string to show (STRING1 or STRING2), 
the latter seems to be the more consistent choice.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> Date: Fri, 22 Aug 2014 04:58:55 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> On 08/21/2014 08:06 PM, Eli Zaretskii wrote:
> 
> >> If the `invisible' starts even one character earlier, it *is* the other
> >> way around.
> >
> > Yes, because then there's no doubt about the order of evaluating the
> > various properties and acting upon them.  By contrast, when they all
> > begin at the same buffer position, the order is
> > implementation-defined.  The code is written to examine display
> > properties before the invisible properties.
> 
> Okay, but I'll take this to mean that hitting the changed behavior in 
> existing code would be pretty rare.

I have no idea how rare it will be.  FWIW, for the past year, all the
display-related bugs are for pretty rare cases.  What does that tell
you about user expectations?

> Anyway, how about the other way around? I'll like this less, but why not 
> make `invisible' inactive when `display' is set?

That's what Emacs does already.  The only place where invisible still
matters in this situation is when deciding how and where to display
overlay strings.  I thought I explained that earlier in this thread.

> >> Maybe. But at least it's consistent with the overlay priority rules.
> >
> > The priority is _per_buffer_position_.  We tend to forget that text
> > properties and overlays in Emacs are _character_ properties, but the
> > display engine is designed and implemented to support that, and in
> > some obscure cases, like this one, it is impossible to understand its
> > logic, unless one remembers this simple fact.
> 
> I'm just quoting Stefan from that discussion:
> 
> """
> Same problem: for two overlays of equal `priority', the shorter one has
> higher priority, so your original example is already one of those
> cases, AFAIC.
> """

This again omits the basic fact that properties and overlays are per
character.

> (let ((pt (point)))
>    (insert "aaa")
>    (let ((o (make-overlay pt (point))) (v (make-overlay (1+ pt) (1- 
> (point)))))
>      (overlay-put o 'face 'bold)
>      (overlay-put v 'face 'default)))
> 
> the middle character has normal weight, even though it's also covered by 
> an outer overlay that sets `face' to `bold'.
> 
> So, if I had to pick which single string to show (STRING1 or STRING2), 
> the latter seems to be the more consistent choice.

My opinion is that users and Lisp programmers should not enter these
dark corners.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/22/2014 10:41 AM, Eli Zaretskii wrote:

> I have no idea how rare it will be.  FWIW, for the past year, all the
> display-related bugs are for pretty rare cases.  What does that tell
> you about user expectations?

I dunno. Something's changing? For example, I've encountered this 
specific bug now because the `report-emacs-bug' buffer uses `display' in 
Emacs 24.4, but 24.3 used `intangible' there.

(And only after I've fixed another `display'-related bug in Company 
popup rendering.)

>> Anyway, how about the other way around? I'll like this less, but why not
>> make `invisible' inactive when `display' is set?
>
> That's what Emacs does already.  The only place where invisible still
> matters in this situation is when deciding how and where to display
> overlay strings.  I thought I explained that earlier in this thread.

So, why not make it matter less? "If display is set, don't interpret 
invisible" should be a straightforward piece of logic.

If `display' takes priority over `invisible', I would expect

(let ((pt (point)))
   (insert (propertize "a" 'display "bbb"))
   (let ((o (make-overlay pt (point))))
     (overlay-put o 'after-string "foo\nbar")))

and

(let ((pt (point)))
   (insert (propertize "a" 'display "bbb"))
   (let ((o (make-overlay pt (point))))
     (overlay-put o 'invisible t)
     (overlay-put o 'after-string "foo\nbar")))

to be rendered the same.

> My opinion is that users and Lisp programmers should not enter these
> dark corners.

Yeah, maybe.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> Date: Fri, 22 Aug 2014 15:41:51 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> >> Anyway, how about the other way around? I'll like this less, but why not
> >> make `invisible' inactive when `display' is set?
> >
> > That's what Emacs does already.  The only place where invisible still
> > matters in this situation is when deciding how and where to display
> > overlay strings.  I thought I explained that earlier in this thread.
> 
> So, why not make it matter less? "If display is set, don't interpret 
> invisible" should be a straightforward piece of logic.

If that's what people want, it's an easy change.  But the question is,
won't that cause overlay strings not to be displayed in some cases?

> If `display' takes priority over `invisible', I would expect
> 
> (let ((pt (point)))
>    (insert (propertize "a" 'display "bbb"))
>    (let ((o (make-overlay pt (point))))
>      (overlay-put o 'after-string "foo\nbar")))
> 
> and
> 
> (let ((pt (point)))
>    (insert (propertize "a" 'display "bbb"))
>    (let ((o (make-overlay pt (point))))
>      (overlay-put o 'invisible t)
>      (overlay-put o 'after-string "foo\nbar")))
> 
> to be rendered the same.

The question is what would you expect from the second example, if it
used before-string there?  Should the before-string be displayed or
shouldn't it?  Since invisible makes the beginning of the overlay
disappear, under your suggestion it won't be displayed.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/22/2014 05:31 PM, Eli Zaretskii wrote:

> If that's what people want, it's an easy change.

Can't say for all people, but it seems like a good idea to me.

> But the question is,
> won't that cause overlay strings not to be displayed in some cases?

The reverse, maybe? Making `invisible' inactive means something might 
become visible, right? But I'd have to see some examples.

>> If `display' takes priority over `invisible', I would expect
>>
>> (let ((pt (point)))
>>     (insert (propertize "a" 'display "bbb"))
>>     (let ((o (make-overlay pt (point))))
>>       (overlay-put o 'after-string "foo\nbar")))
>>
>> and
>>
>> (let ((pt (point)))
>>     (insert (propertize "a" 'display "bbb"))
>>     (let ((o (make-overlay pt (point))))
>>       (overlay-put o 'invisible t)
>>       (overlay-put o 'after-string "foo\nbar")))
>>
>> to be rendered the same.
>
> The question is what would you expect from the second example, if it
> used before-string there?  Should the before-string be displayed or
> shouldn't it?  Since invisible makes the beginning of the overlay
> disappear, under your suggestion it won't be displayed.

I think I'm suggesting the reverse, no? And anyway, with the current 
logic, both examples render the `before-string' if I use it there just 
fine. I see no reason for that that to change.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> Date: Sat, 23 Aug 2014 00:01:59 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> > But the question is,
> > won't that cause overlay strings not to be displayed in some cases?
> 
> The reverse, maybe? Making `invisible' inactive means something might 
> become visible, right?

No.

> But I'd have to see some examples.

Look at the code inside load_overlay_strings that handles this, to
understand what I'm saying.

> > The question is what would you expect from the second example, if it
> > used before-string there?  Should the before-string be displayed or
> > shouldn't it?  Since invisible makes the beginning of the overlay
> > disappear, under your suggestion it won't be displayed.
> 
> I think I'm suggesting the reverse, no?

No.

> And anyway, with the current logic, both examples render the
> `before-string' if I use it there just fine.

Of course, they do, because that's how Emacs was coded.

> I see no reason for that that to change.

You asked to ignore the invisible, so it will change.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/23/2014 12:55 AM, Eli Zaretskii wrote:

> Look at the code inside load_overlay_strings that handles this, to
> understand what I'm saying.

Do you mean the situation when the `invisible' overlay starts before the 
`display' starts? And then we skip to the end because of `invisible', 
but that position is covered by `display', so if we ignore the 
`invisible' there, `before-string' would not be displayed?

>>> The question is what would you expect from the second example, if it
>>> used before-string there?  Should the before-string be displayed or
>>> shouldn't it?  Since invisible makes the beginning of the overlay
>>> disappear, under your suggestion it won't be displayed.

This doesn't seem to apply to the second example, because the overlay 
with `invisible' and the `display' prop start at the same position, so 
the beginning of the overlay would not be "made disappear".

I'm not sure what to do in the "mixed" cases like described above, 
though. Maybe only make `invisible' ignored when `display' covers the 
entirety of its span.

Or maybe this complexity is an argument in favor of `invisible' taking 
priority over `display', after all.

That sounds like it may be easier to implement, or at least specify: 
don't handle `display' only when it's entirely covered by `invisible'.

> You asked to ignore the invisible, so it will change.

Basically, my suggestion was to ignore it when `display' already 
performs all of its job. But the edge cases make it more complicated.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> Date: Sun, 24 Aug 2014 05:28:42 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> On 08/23/2014 12:55 AM, Eli Zaretskii wrote:
> 
> > Look at the code inside load_overlay_strings that handles this, to
> > understand what I'm saying.
> 
> Do you mean the situation when the `invisible' overlay starts before the 
> `display' starts? And then we skip to the end because of `invisible', 
> but that position is covered by `display', so if we ignore the 
> `invisible' there, `before-string' would not be displayed?

No, I mean the situation where a before-string or after-string overlay
is put on invisible text.

> Basically, my suggestion was to ignore it when `display' already 
> performs all of its job. But the edge cases make it more complicated.

It's always the corner cases that add enormous complications.  We are
talking about such corner case.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/21/2014 06:07 PM, Dmitry Gutov wrote:

> The workaround of replacing
> `before-string' + `invisible' with just `display' seems to function just
> fine so far. For some reason, Nikolaj opted to render the completion
> tooltip in Company with the former option, so I tried not to change it
> too much.

And now I know why that was: `display' doesn't work on empty overlays, 
but `before-string' and `after-string' do. That means +1 workaround.

This comes up when the Company tooltip is displayed "after" the end of 
the buffer.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Eli Zaretskii]

> Date: Sun, 24 Aug 2014 03:21:28 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18285@debbugs.gnu.org
> 
> On 08/21/2014 06:07 PM, Dmitry Gutov wrote:
> 
> > The workaround of replacing
> > `before-string' + `invisible' with just `display' seems to function just
> > fine so far. For some reason, Nikolaj opted to render the completion
> > tooltip in Company with the former option, so I tried not to change it
> > too much.
> 
> And now I know why that was: `display' doesn't work on empty overlays, 
> but `before-string' and `after-string' do. That means +1 workaround.

Bu empty overlays don't need invisible at all, so I don't see a
problem.

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Dmitry Gutov]

On 08/24/2014 06:40 AM, Eli Zaretskii wrote:

>> And now I know why that was: `display' doesn't work on empty overlays,
>> but `before-string' and `after-string' do. That means +1 workaround.
>
> Bu empty overlays don't need invisible at all, so I don't see a
> problem.

The only problem is, I now need to use `after-string' or `display', 
depending on the context. Which is a small one, as far as problems go.

       (if (/= (overlay-start ov) (overlay-end ov))
           (overlay-put ov 'display disp)
         (overlay-put ov 'after-string disp))

bug#18285: 24.3.92; A combination of `display' on text and `invisible' and `before/after-string' leads to the before/after string being displayed twice

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think it's not worth to try to fix this (by complicating the heck
> out of the display engine) on the account of this use case.

Skimming this bug thread, the discussion then went on to possible fixes,
but if I read it correctly, this was still the conclusion.  So I'm
therefore closing this bug report; if I misunderstood, please reopen it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no