* 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 @ 2014-08-17 22:35 Dmitry [not found] ` <handler.18285.B.140831493931056.ack@debbugs.gnu.org> 2014-08-18 15:07 ` 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 0 siblings, 2 replies; 19+ messages in thread From: Dmitry @ 2014-08-17 22:35 UTC (permalink / raw) To: 18285 (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 ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <handler.18285.B.140831493931056.ack@debbugs.gnu.org>]
* 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) [not found] ` <handler.18285.B.140831493931056.ack@debbugs.gnu.org> @ 2014-08-18 1:06 ` Dmitry Gutov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Gutov @ 2014-08-18 1:06 UTC (permalink / raw) To: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-17 22:35 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 [not found] ` <handler.18285.B.140831493931056.ack@debbugs.gnu.org> @ 2014-08-18 15:07 ` Eli Zaretskii 2014-08-21 14:07 ` Dmitry Gutov 2022-04-18 11:39 ` Lars Ingebrigtsen 1 sibling, 2 replies; 19+ messages in thread From: Eli Zaretskii @ 2014-08-18 15:07 UTC (permalink / raw) To: Dmitry; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-18 15:07 ` 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 @ 2014-08-21 14:07 ` Dmitry Gutov 2014-08-21 14:57 ` Eli Zaretskii 2014-08-23 23:21 ` Dmitry Gutov 2022-04-18 11:39 ` Lars Ingebrigtsen 1 sibling, 2 replies; 19+ messages in thread From: Dmitry Gutov @ 2014-08-21 14:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-21 14:07 ` Dmitry Gutov @ 2014-08-21 14:57 ` Eli Zaretskii 2014-08-21 15:40 ` Dmitry Gutov 2014-08-23 23:21 ` Dmitry Gutov 1 sibling, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2014-08-21 14:57 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-21 14:57 ` Eli Zaretskii @ 2014-08-21 15:40 ` Dmitry Gutov 2014-08-21 16:06 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2014-08-21 15:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-21 15:40 ` Dmitry Gutov @ 2014-08-21 16:06 ` Eli Zaretskii 2014-08-22 0:58 ` Dmitry Gutov 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2014-08-21 16:06 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-21 16:06 ` Eli Zaretskii @ 2014-08-22 0:58 ` Dmitry Gutov 2014-08-22 6:41 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2014-08-22 0:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-22 0:58 ` Dmitry Gutov @ 2014-08-22 6:41 ` Eli Zaretskii 2014-08-22 11:41 ` Dmitry Gutov 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2014-08-22 6:41 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-22 6:41 ` Eli Zaretskii @ 2014-08-22 11:41 ` Dmitry Gutov 2014-08-22 13:31 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2014-08-22 11:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-22 11:41 ` Dmitry Gutov @ 2014-08-22 13:31 ` Eli Zaretskii 2014-08-22 20:01 ` Dmitry Gutov 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2014-08-22 13:31 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-22 13:31 ` Eli Zaretskii @ 2014-08-22 20:01 ` Dmitry Gutov 2014-08-22 20:55 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2014-08-22 20:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-22 20:01 ` Dmitry Gutov @ 2014-08-22 20:55 ` Eli Zaretskii 2014-08-24 1:28 ` Dmitry Gutov 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2014-08-22 20:55 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-22 20:55 ` Eli Zaretskii @ 2014-08-24 1:28 ` Dmitry Gutov 2014-08-24 2:44 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2014-08-24 1:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-24 1:28 ` Dmitry Gutov @ 2014-08-24 2:44 ` Eli Zaretskii 0 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2014-08-24 2:44 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-21 14:07 ` Dmitry Gutov 2014-08-21 14:57 ` Eli Zaretskii @ 2014-08-23 23:21 ` Dmitry Gutov 2014-08-24 2:40 ` Eli Zaretskii 1 sibling, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2014-08-23 23:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-23 23:21 ` Dmitry Gutov @ 2014-08-24 2:40 ` Eli Zaretskii 2014-08-24 2:48 ` Dmitry Gutov 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2014-08-24 2:40 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 18285 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-24 2:40 ` Eli Zaretskii @ 2014-08-24 2:48 ` Dmitry Gutov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Gutov @ 2014-08-24 2:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285 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)) ^ permalink raw reply [flat|nested] 19+ messages in thread
* 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 2014-08-18 15:07 ` 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 2014-08-21 14:07 ` Dmitry Gutov @ 2022-04-18 11:39 ` Lars Ingebrigtsen 1 sibling, 0 replies; 19+ messages in thread From: Lars Ingebrigtsen @ 2022-04-18 11:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18285, Dmitry 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-04-18 11:39 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-08-17 22:35 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 [not found] ` <handler.18285.B.140831493931056.ack@debbugs.gnu.org> 2014-08-18 1:06 ` 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 2014-08-18 15:07 ` 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 2014-08-21 14:07 ` Dmitry Gutov 2014-08-21 14:57 ` Eli Zaretskii 2014-08-21 15:40 ` Dmitry Gutov 2014-08-21 16:06 ` Eli Zaretskii 2014-08-22 0:58 ` Dmitry Gutov 2014-08-22 6:41 ` Eli Zaretskii 2014-08-22 11:41 ` Dmitry Gutov 2014-08-22 13:31 ` Eli Zaretskii 2014-08-22 20:01 ` Dmitry Gutov 2014-08-22 20:55 ` Eli Zaretskii 2014-08-24 1:28 ` Dmitry Gutov 2014-08-24 2:44 ` Eli Zaretskii 2014-08-23 23:21 ` Dmitry Gutov 2014-08-24 2:40 ` Eli Zaretskii 2014-08-24 2:48 ` Dmitry Gutov 2022-04-18 11:39 ` Lars Ingebrigtsen
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.