* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup @ 2017-06-19 16:50 Alexander Miller 2017-06-19 17:08 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Alexander Miller @ 2017-06-19 16:50 UTC (permalink / raw) To: 27427 As requested by Eli on reddit, a proper bug report about the company issue: Using the new native line numbers in emacs -q alongside company mode results in line numbers not being rendered in lines where the company-mode popup is active. This is the same as in (n)linum-mode, however the company popup, except the first line, is also shifted to the left into the space line numbers used to occupy: http://imgur.com/xHf2mlp It looks like there's a general issue of overlay using packages not expecting the space now being used by line numbers. For example the fill-column-indicator package draws its indicator too far to the left and swerves off with the comments at the top for some reason: http://imgur.com/WHcrhdC (Don't know why the company popup looks even worse here, that doesn't happen when I load my full config). In GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.15) of 2017-06-18 built on a-laptop Repository revision: 7277c0fca7dab9f1b311c3eba5c42fd17acc3593 Windowing system distributor 'The X.Org Foundation ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-19 16:50 bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup Alexander Miller @ 2017-06-19 17:08 ` Eli Zaretskii [not found] ` <6b307502-53db-e92d-1050-3cf0132537cb@web.de> 2017-06-19 21:03 ` Dmitry Gutov 0 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-19 17:08 UTC (permalink / raw) To: Alexander Miller; +Cc: 27427 > From: Alexander Miller <alexanderm@web.de> > Date: Mon, 19 Jun 2017 18:50:18 +0200 > > As requested by Eli on reddit, a proper bug report about the company issue: Thanks. > Using the new native line numbers in emacs -q > alongside company mode results in line numbers not being rendered in > lines where the company-mode popup is active. This is the same as in > (n)linum-mode, however the company popup, except the first line, is also > shifted to the left into the space line numbers used to occupy: > http://imgur.com/xHf2mlp Can you show a minimal recipe, assuming company-mode was already loaded, to reproduce the issue? Such a recipe will make the job of looking into the issue much easier, TIA. > It looks like there's a general issue of overlay using packages not > expecting the space now being used by line numbers. For example the > fill-column-indicator package draws its indicator too far to the left > and swerves off with the comments at the top for some reason: > http://imgur.com/WHcrhdC > (Don't know why the company popup looks even worse here, that doesn't > happen when I load my full config). It looks like some packages need to revisit their calculations of horizontal coordinates. I'm guessing they convert column numbers into pixels, which will err when line numbers are displayed. They should instead use posn-at-point and the likes. Per Martin's analysis, the same problems should happen when the buffer has line-prefix defined; could you try that? ^ permalink raw reply [flat|nested] 97+ messages in thread
[parent not found: <6b307502-53db-e92d-1050-3cf0132537cb@web.de>]
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup [not found] ` <6b307502-53db-e92d-1050-3cf0132537cb@web.de> @ 2017-06-19 19:23 ` Eli Zaretskii 2017-06-19 19:53 ` Alexander Miller 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-19 19:23 UTC (permalink / raw) To: Alexander Miller; +Cc: 27427 [Please keep the bug address on the CC line, so this is recorded by the bug tracker.] > From: Alexander Miller <alexanderm@web.de> > Date: Mon, 19 Jun 2017 19:26:23 +0200 > > > Can you show a minimal recipe, assuming company-mode was already > > loaded, to reproduce the issue? Such a recipe will make the job of > > looking into the issue much easier, TIA > It's just the code you see in the pictures, starting from emacs -q. > > Here it is again for easy copy-pasting: Thanks, I will try to look into this. > > Per Martin's analysis, the > > same problems should happen when the buffer has line-prefix defined; > > could you try that? > You're right, exactly the same thing happens. OK, then may I suggest you raise this issue with the respective package developers? They could for now use line-prefix as trigger for the problem; once they fix that, I think the problem with line numbers will go away as well. I will try to help them to pinpoint their problem using the recipe you provided. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-19 19:23 ` Eli Zaretskii @ 2017-06-19 19:53 ` Alexander Miller 0 siblings, 0 replies; 97+ messages in thread From: Alexander Miller @ 2017-06-19 19:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 27427 > [Please keep the bug address on the CC line, so this is recorded by > the bug tracker.] Sorry about that. I pushed reply out of habit. > OK, then may I suggest you raise this issue with the respective > package developers? Will do. I'll direct them to this ticket as well as the general discussion. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-19 17:08 ` Eli Zaretskii [not found] ` <6b307502-53db-e92d-1050-3cf0132537cb@web.de> @ 2017-06-19 21:03 ` Dmitry Gutov 2017-06-20 15:04 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-19 21:03 UTC (permalink / raw) To: Eli Zaretskii, Alexander Miller; +Cc: 27427 On 6/19/17 8:08 PM, Eli Zaretskii wrote: > It looks like some packages need to revisit their calculations of > horizontal coordinates. I'm guessing they convert column numbers into > pixels, which will err when line numbers are displayed. They should > instead use posn-at-point and the likes. Use it how? With (setq line-prefix "..."), (car (posn-col-row (posn-at-point))) suddenly returns 3 at bol. > Per Martin's analysis, the > same problems should happen when the buffer has line-prefix defined; > could you try that? Indeed, it does. But it's easy for company-mode to ignore the possibility of line-prefix variable being set (it almost never happens). We do support line-prefix when it's assigned via text property. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-19 21:03 ` Dmitry Gutov @ 2017-06-20 15:04 ` Eli Zaretskii 2017-06-21 2:18 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-20 15:04 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Tue, 20 Jun 2017 00:03:08 +0300 > > With (setq line-prefix "..."), > > (car (posn-col-row (posn-at-point))) suddenly returns 3 at bol. I guess you think this result is incorrect, but I don't think I understand why. posn-col-row returns the horizontal window-relative coordinate in units of the frame's canonical column width, so it is expected that its value at BOL will be non-zero when there's a line-prefix displayed there. Can you tell how this value is used in company-mode? I think the key to my understanding why this change interferes with company-mode is in that direction. > > Per Martin's analysis, the > > same problems should happen when the buffer has line-prefix defined; > > could you try that? > > Indeed, it does. But it's easy for company-mode to ignore the > possibility of line-prefix variable being set (it almost never happens). > > We do support line-prefix when it's assigned via text property. If you do support the line-prefix property, why are there problems with line-prefix the variable? The effect on display is the same, AFAIU. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-20 15:04 ` Eli Zaretskii @ 2017-06-21 2:18 ` Dmitry Gutov 2017-06-21 2:40 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-21 2:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/20/17 6:04 PM, Eli Zaretskii wrote: >> With (setq line-prefix "..."), >> >> (car (posn-col-row (posn-at-point))) suddenly returns 3 at bol. > > I guess you think this result is incorrect, but I don't think I > understand why. posn-col-row returns the horizontal window-relative > coordinate in units of the frame's canonical column width, so it is > expected that its value at BOL will be non-zero when there's a > line-prefix displayed there. From where I'm standing, it points to a design flaw in how line-prefix is implemented. Or at least it hints that the native line numbering shouldn't use it, and should use fringe or margin (like linum and nlinum do), or something like them that's considered to be outside of the window by the display engine. > Can you tell how this value is used in company-mode? I think the key > to my understanding why this change interferes with company-mode is in > that direction. We've discussed it before, but here's a reminder. Company draws popup by taking a number of lines that the popup would cover, collecting them into strings, modifying those strings to "draw" the popup on top of them. These operations use the "current row" and "current column" results, respectively. Then, it (without going into nuance) puts an overlay over the said buffer lines, makes it `invisible', and puts a strings consisting of concatenation of those modified lines on the overlay's `display' property. When the position at bol is interpreted as "column 3", all lines of the rectangle are rendered starting with the fourth character of each line. Somehow, the result turns out to be uneven, and the first line of the overlay doesn't get affected by line-prefix (so the popup there ends up at the proper horizontal position), but the rest are affected, and they're displaced three columns to the right. >> We do support line-prefix when it's assigned via text property. > > If you do support the line-prefix property, why are there problems > with line-prefix the variable? The effect on display is the same, > AFAIU. The way we support the property is impossible to translate to the variable. For each line, we take the value of `line-prefix', prepend it to the line text, and the popup overlay (the one that covers all of the affected lines) gets the `line-prefix' property set to "". ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-21 2:18 ` Dmitry Gutov @ 2017-06-21 2:40 ` Eli Zaretskii 2017-06-21 13:04 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-21 2:40 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Wed, 21 Jun 2017 05:18:38 +0300 > > When the position at bol is interpreted as "column 3", all lines of the > rectangle are rendered starting with the fourth character of each line. So this is the root cause of the problem. Is there a reason not to start rendering from the character whose posn-col-row is 3? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-21 2:40 ` Eli Zaretskii @ 2017-06-21 13:04 ` Dmitry Gutov 2017-06-21 15:51 ` Alexander Miller 2017-06-21 18:15 ` Eli Zaretskii 0 siblings, 2 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-21 13:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/21/17 5:40 AM, Eli Zaretskii wrote: >> When the position at bol is interpreted as "column 3", all lines of the >> rectangle are rendered starting with the fourth character of each line. > > So this is the root cause of the problem. Is there a reason not to > start rendering from the character whose posn-col-row is 3? How? Does that mean I'll have to call posn-at-point twice now? Once for point, and once for beginning-of-visual-line? Even that won't solve all the rendering issues. In my testing, the first line of the popup is not at the same column as the rest of them. Probably because of the `line-prefix' property on the overlay which I explained in the previous email. And we can't stop putting it there because we don't have a better solution for the `line-prefix' text property. I _guess_ I could reorganize the code and track whether the current line is the first, and render that line of the popup with a different offset... Doesn't sound great, to be honest. That's an extra piece of complexity. Even so, I'm not sure this will be the end of it. Setting line-prefix doesn't seem to be an accurate model of the problem company popup has with native line numbering: - The image in the report shows the first line of the popup being "rendered" at a higher column than the rest. The rest are basically positioned fine. - In my testing, with (setq line-prefix "..."), it's the opposite. The first line of the popup is positioned correctly, while the rest are shifted to the right by 3 columns. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-21 13:04 ` Dmitry Gutov @ 2017-06-21 15:51 ` Alexander Miller 2017-06-21 18:15 ` Eli Zaretskii 1 sibling, 0 replies; 97+ messages in thread From: Alexander Miller @ 2017-06-21 15:51 UTC (permalink / raw) To: Dmitry Gutov, Eli Zaretskii; +Cc: 27427 > In my testing, with (setq line-prefix "..."), it's the opposite. The > first line of the popup is positioned correctly, while the rest are > shifted to the right by 3 columns. You're right about that, it's the same, but opposite problem. I tried again with line-numbers and/or line-prefix and the popup is indeed shifted around in different directions in both cases. Interestingly enough it's possible for the effects of both settings to cancel each other out when they take the same amount of space. For me it for example happened with (setq display-line-width 5 line-prefix "......."). Link to pictures: http://imgur.com/a/9QRQs ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-21 13:04 ` Dmitry Gutov 2017-06-21 15:51 ` Alexander Miller @ 2017-06-21 18:15 ` Eli Zaretskii 2017-06-21 22:41 ` Dmitry Gutov 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-21 18:15 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Wed, 21 Jun 2017 16:04:58 +0300 > > On 6/21/17 5:40 AM, Eli Zaretskii wrote: > > >> When the position at bol is interpreted as "column 3", all lines of the > >> rectangle are rendered starting with the fourth character of each line. > > > > So this is the root cause of the problem. Is there a reason not to > > start rendering from the character whose posn-col-row is 3? > > How? > > Does that mean I'll have to call posn-at-point twice now? Once for > point, and once for beginning-of-visual-line? I guess so. I understand that now you call current-column or something similar at BOL? Or do you just assume the column there is zero? > Even that won't solve all the rendering issues. In my testing, the first > line of the popup is not at the same column as the rest of them. > Probably because of the `line-prefix' property on the overlay which I > explained in the previous email. And we can't stop putting it there > because we don't have a better solution for the `line-prefix' text property. What I had in mind is to come up with a solution that will work the same with line-prefix specified in any way we support. Then you won't need to put the line-prefix property on the company overlay. Btw, can you remind me why we don't use pop-up menus for company popups? > Even so, I'm not sure this will be the end of it. Setting line-prefix > doesn't seem to be an accurate model of the problem company popup has > with native line numbering: Could be. Can I seduce you to try the line-numbers branch? ;-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-21 18:15 ` Eli Zaretskii @ 2017-06-21 22:41 ` Dmitry Gutov 2017-06-22 14:55 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-21 22:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/21/17 9:15 PM, Eli Zaretskii wrote: > Or do you just assume the column there is > zero? Yep! And there are zero outstanding bug reports related to this. > What I had in mind is to come up with a solution that will work the > same with line-prefix specified in any way we support. Then you won't > need to put the line-prefix property on the company overlay. I'm saying it's not easy, and I'm not brimming with ideas. Can't we put native line numbering outside of the window bounds? Like linum and nlinum do. > Btw, can you remind me why we don't use pop-up menus for company > popups? Event handing and theming issues (at least with GUI frames). - GUI menus have only two colors: background and foreground (and maybe "inactive"). Not sure about the terminal mode menus. - Menus take over the event loop. IIRC you suggested a way to get around this, but that doesn't solve the previous problem anyway. IIUC we've settled on using chromeless frames for the popup. It seems Martin is cooking something in this direction (almost ready?), but I haven't tried using them. And that would take some work. Last I checked, Clément was interested, but no results yet. > Could be. Can I seduce you to try the line-numbers branch? ;-) Consider me seduced. I'm seeing the same behavior as what Alexander reported. There are two problems: 1. The first visual line containing the popup has the line number at its beginning. And as such, the popup line is shifted to the right. 2. The rest don't have the line numbers before them, so they are positioned correctly. This may or may not be considered a problem (there's probably nothing we can do about the lack of numbers), but the inconsistency between the different popup lines seems like it would require some special handling in the code. And whatever that additional code would do, it would have to be reconciled with line-prefix as well, so as not to make things worse. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-21 22:41 ` Dmitry Gutov @ 2017-06-22 14:55 ` Eli Zaretskii 2017-06-22 23:17 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-22 14:55 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Thu, 22 Jun 2017 01:41:15 +0300 > > On 6/21/17 9:15 PM, Eli Zaretskii wrote: > > Or do you just assume the column there is > > zero? > > Yep! And there are zero outstanding bug reports related to this. Well, except this one ;-) > > What I had in mind is to come up with a solution that will work the > > same with line-prefix specified in any way we support. Then you won't > > need to put the line-prefix property on the company overlay. > > I'm saying it's not easy, and I'm not brimming with ideas. Is it not easy because the assumption about column-zero is hard-coded in many places? Or for some other reason? > Can't we put native line numbering outside of the window bounds? Like > linum and nlinum do. Keeping the numbers out of the margins was my explicit design goal, because some packages want the margins, and we don't have a good solution for "sharing" margins. So from my POV putting the numbers in the margins would be a step backward. It will probably also create major havoc for the few packages that do display in the margins, because Emacs facilities for layout of text and other stuff there are exceedingly limited. > IIUC we've settled on using chromeless frames for the popup. It seems > Martin is cooking something in this direction (almost ready?), but I > haven't tried using them. And that would take some work. Not sure what you mean by "chromeless" here, but if I understand you correctly, Martin's work is already on master. > 1. The first visual line containing the popup has the line number at its > beginning. And as such, the popup line is shifted to the right. That's the "BOL at non-zero column" issue, right? > 2. The rest don't have the line numbers before them, so they are > positioned correctly. This may or may not be considered a problem > (there's probably nothing we can do about the lack of numbers), but the > inconsistency between the different popup lines seems like it would > require some special handling in the code. The lack of numbers is a "feature", I think: only "physical" lines in buffer text are counted, newlines in overlay and display strings do not count. Can you artificially offset the beginning of the overlay to account for the line numbers, and see if that alone solves the problem of the first lines, and doesn't cause problems in the subsequent lines? Thanks. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-22 14:55 ` Eli Zaretskii @ 2017-06-22 23:17 ` Dmitry Gutov 2017-06-23 9:10 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-22 23:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/22/17 5:55 PM, Eli Zaretskii wrote: >> Yep! And there are zero outstanding bug reports related to this. > > Well, except this one ;-) But it's not about line-prefix, it's about a new feature in Emacs that was just introduced in a way that's different from those that came before. >> I'm saying it's not easy, and I'm not brimming with ideas. > > Is it not easy because the assumption about column-zero is hard-coded > in many places? Or for some other reason? Because if we're not allowed to use column-zero, the first line of the popup and the rest are behaving differently. And, depending on which feature is causing the first character of the visual line to be on a non-zero column, the popup lines are offset in different directions. > Keeping the numbers out of the margins was my explicit design goal, > because some packages want the margins, and we don't have a good > solution for "sharing" margins. It's not without problems, though, as it introduces a new, different type of margin, doesn't it? Why not put it outside of the window bounds next to the "actual" margins? That's one option. > So from my POV putting the numbers in > the margins would be a step backward. It will probably also create > major havoc for the few packages that do display in the margins, Not any more havoc than linum or nlinum which many people install and use, and are apparently fine with them taking up one of the margins. > because Emacs facilities for layout of text and other stuff there are > exceedingly limited. But of course, it would be ideal if you could also introduce a facility that would allow sharing of margins (and hopefully also fringes) between different modes. > Not sure what you mean by "chromeless" here, but if I understand you > correctly, Martin's work is already on master. I think so, yes. >> 1. The first visual line containing the popup has the line number at its >> beginning. And as such, the popup line is shifted to the right. > > That's the "BOL at non-zero column" issue, right? Yes, but also the lack of ability to disable the line numbering on a line-by-line basis (which could be one solution for this problem). > The lack of numbers is a "feature", I think: only "physical" lines in > buffer text are counted, newlines in overlay and display strings do > not count. It is indeed a feature from your standpoint, but it's a bug from the point of view of the popup's rendering. Imagine of the line numbers were displayed using line-prefix (I'm not really suggesting that, but...). Then the popup could pick them up and include in the overlay's `display' property text. The user wouldn't see any difference. > Can you artificially offset the beginning of the overlay to account > for the line numbers, and see if that alone solves the problem of the > first lines, and doesn't cause problems in the subsequent lines? Offset the beginning by how much? By (- (car (posn-col-row (posn-at-point (point)))) (car (posn-col-row (posn-at-point (beginning-of-visual-line))))) ? Let's call the value of this expression X. Let's try a thought experiment. Suppose X is non-zero because of line numbering. Then adding an offset of X to the position of the first popup line should fix it. What if X is non-zero because of line-prefix, though? If it's because of line-prefix variable, okay, we don't support it. What if X is non-zero because of the line-prefix text property? We'd get an "array out of bounds" error somewhere, because the first popup line is currently positioned correctly. So when should we add an X offset to the first popup line's position? Suppose X is non-nil because of line numbering and the line-prefix text property both? Org uses the line-prefix text property in certain configurations, so it's a real possibility. One idea would be to first create an overlay on the first visual line which overrides the line-prefix property to zero, *then* measure (car (posn-col-row (posn-at-point (beginning-of-visual-line)))) , then delete the said overlay and proceed. Doesn't that sound like a mess already? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-22 23:17 ` Dmitry Gutov @ 2017-06-23 9:10 ` Eli Zaretskii 2017-06-23 23:26 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-23 9:10 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Fri, 23 Jun 2017 02:17:24 +0300 > > On 6/22/17 5:55 PM, Eli Zaretskii wrote: > > >> Yep! And there are zero outstanding bug reports related to this. > > > > Well, except this one ;-) > > But it's not about line-prefix, it's about a new feature in Emacs that > was just introduced in a way that's different from those that came before. Sorry, I thought that by "related to this" you alluded to the zero-column-at-BOL assumption. > > Keeping the numbers out of the margins was my explicit design goal, > > because some packages want the margins, and we don't have a good > > solution for "sharing" margins. > > It's not without problems, though, as it introduces a new, different > type of margin, doesn't it? Not really. The display engine was always inserting stuff at the beginning of a visual line. Some features that use this include line-prefix and wrap-prefix, the left truncation glyphs, and overlay-arrow. It's just that AFAIU company-mode has coded workarounds for each one of them, and now there's one more feature to deal with. > Why not put it outside of the window bounds next to the "actual" > margins? That's one option. That option requires a thorough redesign of the canvas geometry used by the display engine: currently there's no area for it to put glyphs except the 3 existing ones -- the two margins and the text area. > > So from my POV putting the numbers in > > the margins would be a step backward. It will probably also create > > major havoc for the few packages that do display in the margins, > > Not any more havoc than linum or nlinum which many people install and > use, and are apparently fine with them taking up one of the margins. As long as only one mode uses the margins, no problems indeed. Once there are two or more, they need to work around one another, and that doesn't work very well, sometimes not at all. > But of course, it would be ideal if you could also introduce a facility > that would allow sharing of margins (and hopefully also fringes) between > different modes. Alas, we don't have any consensus for how should this be done. > > Not sure what you mean by "chromeless" here, but if I understand you > > correctly, Martin's work is already on master. > > I think so, yes. I'd urge you to see if company-mode can switch to using these facilities, as working against the display engine works only up to a point, and doubtless causes many maintenance headaches. > >> 1. The first visual line containing the popup has the line number at its > >> beginning. And as such, the popup line is shifted to the right. > > > > That's the "BOL at non-zero column" issue, right? > > Yes, but also the lack of ability to disable the line numbering on a > line-by-line basis (which could be one solution for this problem). If providing such a facility would solve the problem, it should be easy to code. E.g., we could have a display-line-numbers-disable property which a Lisp program could put on the first visible character of a visual line, and a non-nil value of that property would signal to the display engine not to produce the line-number glyphs for that visual line. Would that be okay? (Note that line-number display produces glyphs even for lines for which no number should be displayed, such as continuation lines and empty screen lines beyond EOB, so company-mode would need to decide whether it needs to disable those as well. Which is why I wrote "the first visible character of a visual line" above, emphasis on "visual".) > Imagine of the line numbers were displayed using line-prefix (I'm not > really suggesting that, but...). Then the popup could pick them up and > include in the overlay's `display' property text. The user wouldn't see > any difference. You can do similar things with line numbers: Lisp code can count lines as well as C code, and the fact that the line numbers are being displayed is easily detected from Lisp. > Suppose X is non-zero because of line numbering. Then adding an offset > of X to the position of the first popup line should fix it. > > What if X is non-zero because of line-prefix, though? If it's because of > line-prefix variable, okay, we don't support it. > > What if X is non-zero because of the line-prefix text property? We'd get > an "array out of bounds" error somewhere, because the first popup line > is currently positioned correctly. > > So when should we add an X offset to the first popup line's position? > > Suppose X is non-nil because of line numbering and the line-prefix text > property both? Org uses the line-prefix text property in certain > configurations, so it's a real possibility. > > One idea would be to first create an overlay on the first visual line > which overrides the line-prefix property to zero, *then* measure > > (car (posn-col-row (posn-at-point (beginning-of-visual-line)))) > > , then delete the said overlay and proceed. Doesn't that sound like a > mess already? (And you didn't yet consider the possibility of _both_ line numbers and line-prefix. Yes, that should be possible, and I intended that to be supported.) Anyway, the mess should be expected in any feature which attempts to change the display in significant ways, like company-mode does. Experience shows that this only works up to a point. Which is why The Right Way to implement such features is to introduce infrastructure (on the C level) which will allow the display engine to do the layout job as those features need. Native display of line numbers is one step in that direction, from my POV. I hope that Martin's work on child frames will allow company-mode to go in a similar direction as well. However, this bug report is about letting the current implementation of company-mode live in peace with native display of line numbers. So if you tell me that the above-mentioned property will allow such a coexistence, I will code it. Thanks. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-23 9:10 ` Eli Zaretskii @ 2017-06-23 23:26 ` Dmitry Gutov 2017-06-24 7:47 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-23 23:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/23/17 12:10 PM, Eli Zaretskii wrote: > Sorry, I thought that by "related to this" you alluded to the > zero-column-at-BOL assumption. I just meant that until now this code coped pretty well with what can be found in practice. There are various issues, but none of them were zero-column related. > Not really. The display engine was always inserting stuff at the > beginning of a visual line. Some features that use this include > line-prefix and wrap-prefix, the left truncation glyphs, and > overlay-arrow. It's just that AFAIU company-mode has coded > workarounds for each one of them, and now there's one more feature to > deal with. I don't remember (or see in the code) any workarounds for any of these, aside from line-prefix text property. Maybe we're missing certain problem situations, of course (examples welcome). Do most of these only appear in non-graphical mode? >> Why not put it outside of the window bounds next to the "actual" >> margins? That's one option. > > That option requires a thorough redesign of the canvas geometry used > by the display engine: currently there's no area for it to put glyphs > except the 3 existing ones -- the two margins and the text area. In that case, I think we should try harder to make use of the margins. > As long as only one mode uses the margins, no problems indeed. Once > there are two or more, they need to work around one another, and that > doesn't work very well, sometimes not at all. Violent agreement, isn't it? Again, it's a known problem. You're trying to work around it in a way that doesn't scale to any potential similar new features, and which breaks company-mode popup (and probably some other overlay-wrangling code as well, I'm guessing). I'm saying the users seem willing to wait for a scalable solution, and use a margin in the meantime. After all, we have two margins, and two fringes as well. >> But of course, it would be ideal if you could also introduce a facility >> that would allow sharing of margins (and hopefully also fringes) between >> different modes. > > Alas, we don't have any consensus for how should this be done. I can try to outline a possible API. Do we have an existing bug report where that discussion would be better placed? If you have a link to a previous discussion, that would be great as well. >>> Not sure what you mean by "chromeless" here, but if I understand you >>> correctly, Martin's work is already on master. >> >> I think so, yes. > > I'd urge you to see if company-mode can switch to using these > facilities, as working against the display engine works only up to a > point, and doubtless causes many maintenance headaches. It sounds like a fair amount of work, so it's low on my list. Improving ruby-mode and xref seems more important. >> Yes, but also the lack of ability to disable the line numbering on a >> line-by-line basis (which could be one solution for this problem). > > If providing such a facility would solve the problem, it should be > easy to code. E.g., we could have a display-line-numbers-disable > property which a Lisp program could put on the first visible character > of a visual line, and a non-nil value of that property would signal to > the display engine not to produce the line-number glyphs for that > visual line. Would that be okay? Should be fine, if we find no better choice. As long as that property can be set via an overlay. > (Note that line-number display > produces glyphs even for lines for which no number should be > displayed, such as continuation lines and empty screen lines beyond > EOB, so company-mode would need to decide whether it needs to disable > those as well. Which is why I wrote "the first visible character of a > visual line" above, emphasis on "visual".) Visual line sounds right. >> Imagine of the line numbers were displayed using line-prefix (I'm not >> really suggesting that, but...). Then the popup could pick them up and >> include in the overlay's `display' property text. The user wouldn't see >> any difference. > > You can do similar things with line numbers: Lisp code can count lines > as well as C code, and the fact that the line numbers are being > displayed is easily detected from Lisp. I can't get to the actual numbers, though. And isn't counting lines in Lisp considered too slow? Or why else would we have this new feature? > (And you didn't yet consider the possibility of _both_ line numbers > and line-prefix. Yes, that should be possible, and I intended that to > be supported.) I did, it's in the middle of your quote. ;-) > Anyway, the mess should be expected in any feature which attempts to > change the display in significant ways, like company-mode does. > Experience shows that this only works up to a point. Which is why The > Right Way to implement such features is to introduce infrastructure > (on the C level) which will allow the display engine to do the layout > job as those features need. Native display of line numbers is one > step in that direction, from my POV. I hope that Martin's work on > child frames will allow company-mode to go in a similar direction as > well. Agreed that it's the right direction (although I wouldn't say no to a popup library in the core either ;-). Would it help in non-graphical mode, though? Does it support non-maximized frames? > However, this bug report is about letting the current implementation > of company-mode live in peace with native display of line numbers. So > if you tell me that the above-mentioned property will allow such a > coexistence, I will code it. Let's try it, if it's not hard to add. I'll report back as soon as it's available. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-23 23:26 ` Dmitry Gutov @ 2017-06-24 7:47 ` Eli Zaretskii 2017-06-24 17:28 ` Eli Zaretskii 2017-06-25 14:31 ` Dmitry Gutov 0 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-24 7:47 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sat, 24 Jun 2017 02:26:23 +0300 > > > Not really. The display engine was always inserting stuff at the > > beginning of a visual line. Some features that use this include > > line-prefix and wrap-prefix, the left truncation glyphs, and > > overlay-arrow. It's just that AFAIU company-mode has coded > > workarounds for each one of them, and now there's one more feature to > > deal with. > > I don't remember (or see in the code) any workarounds for any of these, > aside from line-prefix text property. Maybe we're missing certain > problem situations, of course (examples welcome). Do most of these only > appear in non-graphical mode? Not necessarily. E.g., disabling the fringes will cause Emacs to display left-truncation glyphs on GUI frames as well. I guess you were just lucky, because in all of the other cases the additional horizontal shift was somehow either accounted for or (in the case of overlay-arrow) non-existent. But the principle still stands: the display engine is allowed to insert glyphs it invents out of thin air at the edges of the text area, and Emacs always made use of this. > Again, [display in margins is] a known problem. You're trying to > work around it in a way that doesn't scale to any potential similar > new features, and which breaks company-mode popup (and probably some > other overlay-wrangling code as well, I'm guessing). It will only break modes that assume too much about layout. And given the popularity of the line numbers, there's no other practical way except adapt those add-on packages, starting from company-mode. > I'm saying the users seem willing to wait for a scalable solution, and > use a margin in the meantime. I think you have it backwards: the margin-based solutions were tried and were found not to be scalable. > >> But of course, it would be ideal if you could also introduce a facility > >> that would allow sharing of margins (and hopefully also fringes) between > >> different modes. > > > > Alas, we don't have any consensus for how should this be done. > > I can try to outline a possible API. Do we have an existing bug report > where that discussion would be better placed? Bug#24193. > If you have a link to a previous discussion, that would be great as well. Here's one (I think there were more): http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01171.html FWIW, I don't recommend going in that direction, as I believe we will again bump into the same basic disagreements due to conflicting goals. That's why I decided to stay away of the margins in the first place. > >> Yes, but also the lack of ability to disable the line numbering on a > >> line-by-line basis (which could be one solution for this problem). > > > > If providing such a facility would solve the problem, it should be > > easy to code. E.g., we could have a display-line-numbers-disable > > property which a Lisp program could put on the first visible character > > of a visual line, and a non-nil value of that property would signal to > > the display engine not to produce the line-number glyphs for that > > visual line. Would that be okay? > > Should be fine, if we find no better choice. As long as that property > can be set via an overlay. OK, I will add that. > >> Imagine of the line numbers were displayed using line-prefix (I'm not > >> really suggesting that, but...). Then the popup could pick them up and > >> include in the overlay's `display' property text. The user wouldn't see > >> any difference. > > > > You can do similar things with line numbers: Lisp code can count lines > > as well as C code, and the fact that the line numbers are being > > displayed is easily detected from Lisp. > > I can't get to the actual numbers, though. count-lines should give them to you, no? > And isn't counting lines in Lisp considered too slow? When done as part of routine redisplay, off the post-command-hook, yes. But company-mode is not used during routine redisplay, as in during scrolling through the window, right? > Or why else would we have this new feature? Producing line numbers as part of redisplay was indeed intended to make it faster, since all the line-numbering add-ons basically induce an immediate additional redisplay cycle, because they change overlays. But that was only one of my goals, the other was to do in the infrastructure something that can be done well only there. > > I hope that Martin's work on child frames will allow company-mode > > to go in a similar direction as well. > > Agreed that it's the right direction (although I wouldn't say no to a > popup library in the core either ;-). Would it help in non-graphical > mode, though? Does it support non-maximized frames? AFAIU, it supports any kind of frame. > > However, this bug report is about letting the current implementation > > of company-mode live in peace with native display of line numbers. So > > if you tell me that the above-mentioned property will allow such a > > coexistence, I will code it. > > Let's try it, if it's not hard to add. I'll report back as soon as it's > available. Thanks. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-24 7:47 ` Eli Zaretskii @ 2017-06-24 17:28 ` Eli Zaretskii 2017-06-24 20:43 ` Dmitry Gutov 2017-06-25 14:31 ` Dmitry Gutov 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-24 17:28 UTC (permalink / raw) To: dgutov; +Cc: alexanderm, 27427 > Date: Sat, 24 Jun 2017 10:47:28 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > > > > If providing such a facility would solve the problem, it should be > > > easy to code. E.g., we could have a display-line-numbers-disable > > > property which a Lisp program could put on the first visible character > > > of a visual line, and a non-nil value of that property would signal to > > > the display engine not to produce the line-number glyphs for that > > > visual line. Would that be okay? > > > > Should be fine, if we find no better choice. As long as that property > > can be set via an overlay. > > OK, I will add that. Now done. Please see if this allows company-mode to fix its display when line numbers are displayed. Thanks. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-24 17:28 ` Eli Zaretskii @ 2017-06-24 20:43 ` Dmitry Gutov 2017-06-25 13:51 ` Dmitry Gutov 2017-06-25 14:13 ` Eli Zaretskii 0 siblings, 2 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-24 20:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/24/17 8:28 PM, Eli Zaretskii wrote: > Now done. Please see if this allows company-mode to fix its display > when line numbers are displayed. Seems to work well locally, aside from the EOB case (*). Will commit after you push to master. BTW, without this property, I now see line numbers beside all the visual lines the popup overlay takes up, and the number is the same: N+1, where N is the line-at-point. That doesn't look intended. (*) The case is where the overlay is shown below the last line of the buffer. In that case, we display the popup using the `after-string' property. The after-EOB glyphs don't seem to be affected by `display-line-numbers-disable'. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-24 20:43 ` Dmitry Gutov @ 2017-06-25 13:51 ` Dmitry Gutov 2017-06-25 14:32 ` Eli Zaretskii 2017-06-25 14:13 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-25 13:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 [-- Attachment #1: Type: text/plain, Size: 304 bytes --] On 6/24/17 11:43 PM, Dmitry Gutov wrote: > Seems to work well locally, aside from the EOB case (*). Will commit > after you push to master. A couple of screenshots attached, to illustrate. The EOB case is a problem, but it seems less grating than before (since the popup keeps its shape, at least). [-- Attachment #2: Screenshot from 2017-06-25 16-47-26.png --] [-- Type: image/png, Size: 32843 bytes --] [-- Attachment #3: Screenshot from 2017-06-25 16-47-44.png --] [-- Type: image/png, Size: 25560 bytes --] ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 13:51 ` Dmitry Gutov @ 2017-06-25 14:32 ` Eli Zaretskii 2017-06-25 14:36 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 14:32 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > From: Dmitry Gutov <dgutov@yandex.ru> > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > Date: Sun, 25 Jun 2017 16:51:07 +0300 > > A couple of screenshots attached, to illustrate. Thanks, but as I don't use company-mode, I need explanations to go with the screenshots ;-) First, is the display OK from your POV? If not, what are the problems you'd prefer to solve? Next, do those empty numbered lines in the first screenshots indicate a problem? Or are there indeed empty lines in the buffer? Finally, the EOB case is not in these screenshots, is it? Or is the last one it? If the latter, what problems do you see in that screenshot? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 14:32 ` Eli Zaretskii @ 2017-06-25 14:36 ` Dmitry Gutov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-25 14:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/25/17 5:32 PM, Eli Zaretskii wrote: > Thanks, but as I don't use company-mode, I need explanations to go > with the screenshots ;-) OK. > First, is the display OK from your POV? If not, what are the problems > you'd prefer to solve? The second screenshot shows the popup rendered at EOB, and it's rendered 3 columns too far to the right than expected. > Next, do those empty numbered lines in the first screenshots indicate > a problem? Like I described previously, the numbering doesn't know what to do with a part of the buffer covered by a multiline `display' string. > Or are there indeed empty lines in the buffer? Most lines in this buffer are empty, that doesn't seem to affect the presence of the numbers, except for the last line of the buffer. > Finally, the EOB case is not in these screenshots, is it? Or is the > last one it? If the latter, what problems do you see in that > screenshot? The last one, yes. The popup is 3 columns too far to the right. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-24 20:43 ` Dmitry Gutov 2017-06-25 13:51 ` Dmitry Gutov @ 2017-06-25 14:13 ` Eli Zaretskii 2017-06-25 14:46 ` Dmitry Gutov 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 14:13 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sat, 24 Jun 2017 23:43:25 +0300 > > On 6/24/17 8:28 PM, Eli Zaretskii wrote: > > > Now done. Please see if this allows company-mode to fix its display > > when line numbers are displayed. > > Seems to work well locally, aside from the EOB case (*). Will commit > after you push to master. Great, thanks for testing. > BTW, without this property, I now see line numbers beside all the visual > lines the popup overlay takes up, and the number is the same: N+1, where > N is the line-at-point. That doesn't look intended. The displayed line number reflects the line of the buffer positions corresponding to what's on that screen line. If none of the buffer positions appear on that screen line, it's the line of the buffer position(s) "covered" by the display string/overlay which generates the display. If what you see doesn't fit this description, please show a screenshot, and describe or show the code which puts the overlay that causes the display. > (*) The case is where the overlay is shown below the last line of the > buffer. In that case, we display the popup using the `after-string' > property. The after-EOB glyphs don't seem to be affected by > `display-line-numbers-disable'. I'm not sure I understand: are you saying that you've put the property in that case and it didn't have the expected effect? Or are you saying that you don't have a position to put the property in that case? If the former, can you tell on which buffer position you put the property, and perhaps show a simple reproducer? Thanks. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 14:13 ` Eli Zaretskii @ 2017-06-25 14:46 ` Dmitry Gutov 2017-06-25 15:05 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-25 14:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/25/17 5:13 PM, Eli Zaretskii wrote: > The displayed line number reflects the line of the buffer positions > corresponding to what's on that screen line. If none of the buffer > positions appear on that screen line, it's the line of the buffer > position(s) "covered" by the display string/overlay which generates > the display. It didn't look like this in the previous version. Might be considered a bit annoying, repeating the number several times. BTW, by that logic, the last empty line should have a number as well: it does correspond to a buffer position. > If what you see doesn't fit this description, please show a > screenshot, and describe or show the code which puts the overlay that > causes the display. It does fit the description. > I'm not sure I understand: are you saying that you've put the property > in that case and it didn't have the expected effect? Yes. Although I half expected it to have no effect in this case. > Or are you > saying that you don't have a position to put the property in that > case? Also true, probably. > If the former, can you tell on which buffer position you put > the property, and perhaps show a simple reproducer? (with-current-buffer (get-buffer-create "popup-test.el") (setq display-line-numbers t) (insert "aaaaaaa aaaaaaa aaaaaaa aaaaaaa aaaaaaa ") (let ((ov (make-overlay (point-max) (point-max)))) (overlay-put ov 'after-string "bbbbbb\nbbbbbb\n") (overlay-put ov 'display-line-numbers-disable t))) After that, the buffer popup-test.el shows the "bbbbbb" lines prepended with the empty line number columns. I'd rather they weren't there. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 14:46 ` Dmitry Gutov @ 2017-06-25 15:05 ` Eli Zaretskii 2017-06-25 16:35 ` Eli Zaretskii 2017-06-25 17:57 ` Eli Zaretskii 0 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 15:05 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sun, 25 Jun 2017 17:46:23 +0300 > > On 6/25/17 5:13 PM, Eli Zaretskii wrote: > > > The displayed line number reflects the line of the buffer positions > > corresponding to what's on that screen line. If none of the buffer > > positions appear on that screen line, it's the line of the buffer > > position(s) "covered" by the display string/overlay which generates > > the display. > > It didn't look like this in the previous version. Might be considered a > bit annoying, repeating the number several times. It wasn't supposed to be repeated, it was supposed to appear only once. Hmm... I think I see what causes this, let me try to come up with a fix. > BTW, by that logic, the last empty line should have a number as well: it > does correspond to a buffer position. No, it doesn't correspond to any buffer position: there's never any character at point-max. > (with-current-buffer (get-buffer-create "popup-test.el") > (setq display-line-numbers t) > (insert "aaaaaaa > aaaaaaa > aaaaaaa > aaaaaaa > aaaaaaa > ") > > (let ((ov (make-overlay (point-max) (point-max)))) > (overlay-put ov 'after-string "bbbbbb\nbbbbbb\n") > (overlay-put ov 'display-line-numbers-disable t))) > > After that, the buffer popup-test.el shows the "bbbbbb" lines prepended > with the empty line number columns. I'd rather they weren't there. OK, thanks, I will look into this case. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 15:05 ` Eli Zaretskii @ 2017-06-25 16:35 ` Eli Zaretskii 2017-06-25 17:57 ` Eli Zaretskii 1 sibling, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 16:35 UTC (permalink / raw) To: dgutov; +Cc: alexanderm, 27427 > Date: Sun, 25 Jun 2017 18:05:54 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > > > > The displayed line number reflects the line of the buffer positions > > > corresponding to what's on that screen line. If none of the buffer > > > positions appear on that screen line, it's the line of the buffer > > > position(s) "covered" by the display string/overlay which generates > > > the display. > > > > It didn't look like this in the previous version. Might be considered a > > bit annoying, repeating the number several times. > > It wasn't supposed to be repeated, it was supposed to appear only > once. Hmm... I think I see what causes this, let me try to come up > with a fix. Should be fixed now. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 15:05 ` Eli Zaretskii 2017-06-25 16:35 ` Eli Zaretskii @ 2017-06-25 17:57 ` Eli Zaretskii 2017-06-25 22:56 ` Dmitry Gutov 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 17:57 UTC (permalink / raw) To: dgutov; +Cc: alexanderm, 27427 > Date: Sun, 25 Jun 2017 18:05:54 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > > > (with-current-buffer (get-buffer-create "popup-test.el") > > (setq display-line-numbers t) > > (insert "aaaaaaa > > aaaaaaa > > aaaaaaa > > aaaaaaa > > aaaaaaa > > ") > > > > (let ((ov (make-overlay (point-max) (point-max)))) > > (overlay-put ov 'after-string "bbbbbb\nbbbbbb\n") > > (overlay-put ov 'display-line-numbers-disable t))) > > > > After that, the buffer popup-test.el shows the "bbbbbb" lines prepended > > with the empty line number columns. I'd rather they weren't there. > > OK, thanks, I will look into this case. Should be fixed now. the fix only works for empty overlays at EOB, but that should be enough, right? Or do you see some other way of specifying this property at EOB? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 17:57 ` Eli Zaretskii @ 2017-06-25 22:56 ` Dmitry Gutov 2017-06-26 8:23 ` martin rudalics ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-25 22:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/25/17 8:57 PM, Eli Zaretskii wrote: > Should be fixed now. Thanks, both cases are working well now. See below for the third one (though it's relatively rare). ;-( > the fix only works for empty overlays at EOB, > but that should be enough, right? Or do you see some other way of > specifying this property at EOB? No, it seems plenty enough for me. I doubt we'd ever going to try using text properties for the popup without an overlay. The third case which disrupts popup positioning: horizontal scrolling, which we discussed earlier. With native numbers, it breaks our function which calculates the "usable" window body width. It looks like this: (defun company--window-width () (let ((ww (window-body-width))) ;; Account for the line continuation column. (when (zerop (cadr (window-fringes))) (cl-decf ww)) (unless (or (display-graphic-p) (version< "24.3.1" emacs-version)) ;; Emacs 24.3 and earlier included margins ;; in window-width when in TTY. (cl-decf ww (let ((margins (window-margins))) (+ (or (car margins) 0) (or (cdr margins) 0))))) (when (and word-wrap (version< emacs-version "24.4.51.5")) ;; http://debbugs.gnu.org/19300 (cl-decf ww)) ;; whitespace-mode with newline-mark (when (and buffer-display-table (aref buffer-display-table ?\n)) (cl-decf ww (1- (length (aref buffer-display-table ?\n))))) ww)) Without going into details, how do I figure out the width which line number glyphs are taking up? Any way to do that without calling posn-at-point at the beginning-of-visual-line? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 22:56 ` Dmitry Gutov @ 2017-06-26 8:23 ` martin rudalics 2017-06-26 15:07 ` Eli Zaretskii 2017-06-26 15:22 ` Eli Zaretskii 2017-07-13 23:04 ` Dmitry Gutov 2 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-26 8:23 UTC (permalink / raw) To: Dmitry Gutov, Eli Zaretskii; +Cc: alexanderm, 27427 > Without going into details, how do I figure out the width which line > number glyphs are taking up? Any way to do that without calling > posn-at-point at the beginning-of-visual-line? You'd probably need a function ‘window-line-number-width’ callable after the current glyph matrix was calculated. But if your overlays then mess with the number of lines displayed in the window you'll get into a loop. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 8:23 ` martin rudalics @ 2017-06-26 15:07 ` Eli Zaretskii 2017-06-27 7:06 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-26 15:07 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Mon, 26 Jun 2017 10:23:44 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: alexanderm@web.de, 27427@debbugs.gnu.org > > > Without going into details, how do I figure out the width which line > > number glyphs are taking up? Any way to do that without calling > > posn-at-point at the beginning-of-visual-line? > > You'd probably need a function ‘window-line-number-width’ callable after > the current glyph matrix was calculated. Or maybe a new value of the argument to window-body-width which would cause it to return the width excluding the line-number part? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 15:07 ` Eli Zaretskii @ 2017-06-27 7:06 ` martin rudalics 2017-06-27 14:48 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-27 7:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > Or maybe a new value of the argument to window-body-width which would > cause it to return the width excluding the line-number part? Probably excluding the line- and wrap-prefixes as well. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-27 7:06 ` martin rudalics @ 2017-06-27 14:48 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-27 14:48 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Tue, 27 Jun 2017 09:06:15 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > Or maybe a new value of the argument to window-body-width which would > > cause it to return the width excluding the line-number part? > > Probably excluding the line- and wrap-prefixes as well. Of course. Actually, to _not_ exclude them would be extra work. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 22:56 ` Dmitry Gutov 2017-06-26 8:23 ` martin rudalics @ 2017-06-26 15:22 ` Eli Zaretskii 2017-06-26 15:28 ` Dmitry Gutov 2017-06-26 21:30 ` Johan Bockgård 2017-07-13 23:04 ` Dmitry Gutov 2 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-26 15:22 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Mon, 26 Jun 2017 01:56:28 +0300 > > > the fix only works for empty overlays at EOB, > > but that should be enough, right? Or do you see some other way of > > specifying this property at EOB? > > No, it seems plenty enough for me. I doubt we'd ever going to try using > text properties for the popup without an overlay. No, I meant is there any other way of having a property on EOB except via empty overlays? get-text-property always returns nil at point-max. Is there some creative way of using text properties there? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 15:22 ` Eli Zaretskii @ 2017-06-26 15:28 ` Dmitry Gutov 2017-06-26 15:50 ` Eli Zaretskii 2017-06-26 21:30 ` Johan Bockgård 1 sibling, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-26 15:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/26/17 6:22 PM, Eli Zaretskii wrote: > No, I meant is there any other way of having a property on EOB except > via empty overlays? get-text-property always returns nil at > point-max. Is there some creative way of using text properties there? Probably not. Anyway, from where I'm standing, the new property is more of a temporary workaround, so I wouldn't worry about a detail like that. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 15:28 ` Dmitry Gutov @ 2017-06-26 15:50 ` Eli Zaretskii 2017-06-26 17:12 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-26 15:50 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Mon, 26 Jun 2017 18:28:41 +0300 > > Anyway, from where I'm standing, the new property is more of a temporary > workaround, so I wouldn't worry about a detail like that. Based on ME, we might be surprised how long this temporary workaround will be used... ;-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 15:50 ` Eli Zaretskii @ 2017-06-26 17:12 ` Dmitry Gutov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-26 17:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/26/17 6:50 PM, Eli Zaretskii wrote: > Based on ME, we might be surprised how long this temporary workaround > will be used... ;-) That happens, sure. I imagine it wouldn't be too hard to add support for the additional cases later, though. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 15:22 ` Eli Zaretskii 2017-06-26 15:28 ` Dmitry Gutov @ 2017-06-26 21:30 ` Johan Bockgård 2017-06-27 16:47 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: Johan Bockgård @ 2017-06-26 21:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, Dmitry Gutov Eli Zaretskii <eliz@gnu.org> writes: > No, I meant is there any other way of having a property on EOB except > via empty overlays? get-text-property always returns nil at > point-max. Is there some creative way of using text properties there? `default-text-properties' ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 21:30 ` Johan Bockgård @ 2017-06-27 16:47 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-27 16:47 UTC (permalink / raw) To: Johan Bockgård; +Cc: alexanderm, 27427, dgutov > From: Johan Bockgård <bojohan@gnu.org> > Cc: Dmitry Gutov <dgutov@yandex.ru>, alexanderm@web.de, 27427@debbugs.gnu.org > Date: Mon, 26 Jun 2017 23:30:24 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > No, I meant is there any other way of having a property on EOB except > > via empty overlays? get-text-property always returns nil at > > point-max. Is there some creative way of using text properties there? > > `default-text-properties' Thanks, I fixed the code to support that as well. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 22:56 ` Dmitry Gutov 2017-06-26 8:23 ` martin rudalics 2017-06-26 15:22 ` Eli Zaretskii @ 2017-07-13 23:04 ` Dmitry Gutov 2017-07-14 6:11 ` Eli Zaretskii 2 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-07-13 23:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/26/17 1:56 AM, Dmitry Gutov wrote: > On 6/25/17 8:57 PM, Eli Zaretskii wrote: > >> Should be fixed now. > > Thanks, both cases are working well now. ...and either something changed before the merge into master, or I tested the result poorly. Probably the latter. What doesn't work well is that the popup "background" gets displaced to the left by the width of the numbers column, when rendered using the popup overlay. Background meaning the contents of all the lines behind the popup. And that happens because the line number glyphs are gone for those specific lines, and we can't pad them without knowing the width of the numbers column. Now, I've come upon this idea of a trivial patch. What do you think, Eli? It seems to work perfectly, even though I'm struggling to understand how this might happen under the covers. Is it brittle? We bind display-line-numbers to nil around the call to posn-at-point, so that it calculates the column value that we want. I imagine there's some extra redisplay work involved, but it still turns out to be faster than calling posn-at-point twice. diff --git a/company.el b/company.el index f361bb7..869c5de 100644 --- a/company.el +++ b/company.el @@ -835,7 +835,8 @@ means that `company-mode' is always turned on except in `message-mode' buffers." (cons (+ col (window-hscroll)) row))) (defun company--col-row (&optional pos) - (company--posn-col-row (posn-at-point pos))) + (let (display-line-numbers) + (company--posn-col-row (posn-at-point pos)))) (defun company--row (&optional pos) (cdr (company--col-row pos))) ^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-13 23:04 ` Dmitry Gutov @ 2017-07-14 6:11 ` Eli Zaretskii 2017-07-14 6:24 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-07-14 6:11 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > From: Dmitry Gutov <dgutov@yandex.ru> > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > Date: Fri, 14 Jul 2017 02:04:21 +0300 > > What doesn't work well is that the popup "background" gets displaced to > the left by the width of the numbers column, when rendered using the > popup overlay. Background meaning the contents of all the lines behind > the popup. And that happens because the line number glyphs are gone for > those specific lines, and we can't pad them without knowing the width of > the numbers column. You could use the new function line-number-display-width to obtain that information. > Now, I've come upon this idea of a trivial patch. What do you think, > Eli? It seems to work perfectly, even though I'm struggling to > understand how this might happen under the covers. Is it brittle? No, it isn't brittle. What are you struggling to understand? Maybe I can help. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-14 6:11 ` Eli Zaretskii @ 2017-07-14 6:24 ` Dmitry Gutov 2017-07-14 7:04 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-07-14 6:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 7/14/17 9:11 AM, Eli Zaretskii wrote: > You could use the new function line-number-display-width to obtain > that information. Thanks. The current patch seems preferable, though. And since you are saying it's good enough, it seems I have no need for the display-line-numbers-disable text property either, sorry. > No, it isn't brittle. What are you struggling to understand? Maybe I > can help. To get the value of the current column, Emacs needs to trigger redisplay, right? To know how many columns the numbers take up. Then it has to redisplay again before the user sees the result. So I'm surprised Emacs knows it needs to perform two redisplays just because I bound display-line-numbers to nil temporarily. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-14 6:24 ` Dmitry Gutov @ 2017-07-14 7:04 ` Eli Zaretskii 2017-07-15 17:38 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-07-14 7:04 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Fri, 14 Jul 2017 09:24:58 +0300 > > > No, it isn't brittle. What are you struggling to understand? Maybe I > > can help. > > To get the value of the current column, Emacs needs to trigger > redisplay, right? To know how many columns the numbers take up. Then it > has to redisplay again before the user sees the result. > > So I'm surprised Emacs knows it needs to perform two redisplays just > because I bound display-line-numbers to nil temporarily. That's because posn-at-point "simulates" redisplay: it performs all the layout calculations exactly like redisplay would, but without actually displaying anything. Otherwise, how would posn-at-point be able to return you the information you request, even when there are no line numbers? (If you think posn-at-point takes that information from what is displayed on the glass, or from some of its internal representation, then that's not what it does, because the internal representation of what's on the glass is many times outdated when a Lisp program runs, so it cannot be trusted.) ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-14 7:04 ` Eli Zaretskii @ 2017-07-15 17:38 ` Dmitry Gutov 2017-07-15 17:49 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-07-15 17:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427-done On 7/14/17 10:04 AM, Eli Zaretskii wrote: > That's because posn-at-point "simulates" redisplay: it performs all > the layout calculations exactly like redisplay would, but without > actually displaying anything. Very cool. In that case, let's consider this issue resolved. I've already pushed this fix and cut a new release now. > (If you think posn-at-point takes that information from what is > displayed on the glass, or from some of its internal representation, > then that's not what it does, because the internal representation of > what's on the glass is many times outdated when a Lisp program runs, > so it cannot be trusted.) I was thinking there was some change canary (or many of them), and the "internal representation" is recomputed when any of those values change. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-15 17:38 ` Dmitry Gutov @ 2017-07-15 17:49 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-07-15 17:49 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427-done@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sat, 15 Jul 2017 20:38:15 +0300 > > > (If you think posn-at-point takes that information from what is > > displayed on the glass, or from some of its internal representation, > > then that's not what it does, because the internal representation of > > what's on the glass is many times outdated when a Lisp program runs, > > so it cannot be trusted.) > > I was thinking there was some change canary (or many of them), and the > "internal representation" is recomputed when any of those values change. The internal representation is recomputed only as part of a redisplay cycle. And we cannot start a redisplay cycle before the Lisp interpreter has done its thing, and we are back in the main loop, because only then we know all the buffers and other related Lisp data are in a consistent state that can be reflected on the glass without risking inconsistencies. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-24 7:47 ` Eli Zaretskii 2017-06-24 17:28 ` Eli Zaretskii @ 2017-06-25 14:31 ` Dmitry Gutov 2017-06-25 14:54 ` Eli Zaretskii 2017-06-25 15:59 ` martin rudalics 1 sibling, 2 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-25 14:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/24/17 10:47 AM, Eli Zaretskii wrote: > I guess you were just lucky, because in all of the other cases the > additional horizontal shift was somehow either accounted for or (in > the case of overlay-arrow) non-existent. But the principle still > stands: the display engine is allowed to insert glyphs it invents out > of thin air at the edges of the text area, and Emacs always made use > of this. Try as I might, I can't repro those kind of problems. Line wrap indicators in the terminal usually come at the right. And I think it's aesthetically important that the extra glyphs don't shift line text to the right unless absolutely necessary, so those issues don't materialize. The choice to use one overlay instead of one-overlay-per-line also makes some problems easier. Anyway, naturally, a proper popup will be better. > It will only break modes that assume too much about layout. And given > the popularity of the line numbers, there's no other practical way > except adapt those add-on packages, starting from company-mode. I think you're trying too hard to stay away from the margins. But anyway, we have the alternative solution now. >> I'm saying the users seem willing to wait for a scalable solution, and >> use a margin in the meantime. > > I think you have it backwards: the margin-based solutions were tried > and were found not to be scalable. I don't see you contradicting me. The _current_ margin-based solutions are not scalable in terms of margin-using features, but they can be, when we work on that. And the users seem willing to wait for that. >> I can try to outline a possible API. Do we have an existing bug report >> where that discussion would be better placed? > > Bug#24193. > >> If you have a link to a previous discussion, that would be great as well. > > Here's one (I think there were more): > > http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01171.html > > FWIW, I don't recommend going in that direction, as I believe we will > again bump into the same basic disagreements due to conflicting goals. > That's why I decided to stay away of the margins in the first place. Thanks! I think I have something to contribute. But TBH the use case in the emacs-devel thread is ridiculous. We should be able to provide the functionality offered in the API of common IDEs, and if that doesn't let someone to use the margins as the fill-column, too bad. It still might, but we can't consider all use cases equally valid. >> And isn't counting lines in Lisp considered too slow? > > When done as part of routine redisplay, off the post-command-hook, > yes. But company-mode is not used during routine redisplay, as in > during scrolling through the window, right? It's using post-command-hook, though. Redoing the line numbers rendering is not something I'm looking forward to either. > But that was only one of my goals, the other was to do in > the infrastructure something that can be done well only there. Meaning, to use something other than the margins for display? >> Agreed that it's the right direction (although I wouldn't say no to a >> popup library in the core either ;-). Would it help in non-graphical >> mode, though? Does it support non-maximized frames? > > AFAIU, it supports any kind of frame. I can't see a way to create a less-than-fullscreen frame in terminal Emacs (speaking of normal frames here). ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 14:31 ` Dmitry Gutov @ 2017-06-25 14:54 ` Eli Zaretskii 2017-06-25 15:25 ` Dmitry Gutov 2017-06-25 16:12 ` martin rudalics 2017-06-25 15:59 ` martin rudalics 1 sibling, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 14:54 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sun, 25 Jun 2017 17:31:59 +0300 > > On 6/24/17 10:47 AM, Eli Zaretskii wrote: > > > I guess you were just lucky, because in all of the other cases the > > additional horizontal shift was somehow either accounted for or (in > > the case of overlay-arrow) non-existent. But the principle still > > stands: the display engine is allowed to insert glyphs it invents out > > of thin air at the edges of the text area, and Emacs always made use > > of this. > > Try as I might, I can't repro those kind of problems. Line wrap > indicators in the terminal usually come at the right. I think I mentioned left-truncation glyphs, so horizontally scrolling a line should cause them to appear. > And I think it's aesthetically important that the extra glyphs don't > shift line text to the right unless absolutely necessary, so those > issues don't materialize. That cannot be done in all cases. > > But that was only one of my goals, the other was to do in > > the infrastructure something that can be done well only there. > > Meaning, to use something other than the margins for display? No, I was speaking about the line-number display in general. > >> Agreed that it's the right direction (although I wouldn't say no to a > >> popup library in the core either ;-). Would it help in non-graphical > >> mode, though? Does it support non-maximized frames? > > > > AFAIU, it supports any kind of frame. > > I can't see a way to create a less-than-fullscreen frame in terminal > Emacs (speaking of normal frames here). Maybe I' was wrong. I hope Martin will chime in and set the record straight. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 14:54 ` Eli Zaretskii @ 2017-06-25 15:25 ` Dmitry Gutov 2017-06-25 16:12 ` martin rudalics 1 sibling, 0 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-25 15:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/25/17 5:54 PM, Eli Zaretskii wrote: > I think I mentioned left-truncation glyphs, so horizontally scrolling > a line should cause them to appear. They are shown on all lines at the same time, and (car (posn-col-row (posn-at-point))) returns 0 in the first visible column when horizontally scrolled. IOW, I don't see any problems when horizontally scrolled either. >> And I think it's aesthetically important that the extra glyphs don't >> shift line text to the right unless absolutely necessary, so those >> issues don't materialize. > > That cannot be done in all cases. No argument here. And there are other known issues with the popup anyway. My point is, however, is that you've created a new kind of window area that can only used by the native line numbers, and no other features or packages. This seems not so great to me. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 14:54 ` Eli Zaretskii 2017-06-25 15:25 ` Dmitry Gutov @ 2017-06-25 16:12 ` martin rudalics 2017-06-25 18:21 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-25 16:12 UTC (permalink / raw) To: Eli Zaretskii, Dmitry Gutov; +Cc: alexanderm, 27427 >> I can't see a way to create a less-than-fullscreen frame in terminal >> Emacs (speaking of normal frames here). > > Maybe I' was wrong. I hope Martin will chime in and set the record > straight. I hope I've done that already in my previous mail. Obviously, any such emulation I mentioned in that mail would result in some sort of overlay for the buffer text that is displayed there. While such overlays are temporarily tolerable for menus I strongly doubt that we would want them for anything else. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 16:12 ` martin rudalics @ 2017-06-25 18:21 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 18:21 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sun, 25 Jun 2017 18:12:23 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: alexanderm@web.de, 27427@debbugs.gnu.org > > I hope I've done that already in my previous mail. Obviously, any such > emulation I mentioned in that mail would result in some sort of overlay > for the buffer text that is displayed there. While such overlays are > temporarily tolerable for menus I strongly doubt that we would want them > for anything else. You are right. That trick works for menus only because we preempt the input queue until the menu is exited, exactly what Dmitry wants to get rid of. Too bad. I tried to think about some idea for implementing such popups in the display engine, but for now came up empty-handed. I will think some more. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 14:31 ` Dmitry Gutov 2017-06-25 14:54 ` Eli Zaretskii @ 2017-06-25 15:59 ` martin rudalics 2017-06-25 16:24 ` Dmitry Gutov 2017-06-25 19:00 ` Eli Zaretskii 1 sibling, 2 replies; 97+ messages in thread From: martin rudalics @ 2017-06-25 15:59 UTC (permalink / raw) To: Dmitry Gutov, Eli Zaretskii; +Cc: alexanderm, 27427 > Try as I might, I can't repro those kind of problems. Line wrap > indicators in the terminal usually come at the right. And I think it's > aesthetically important that the extra glyphs don't shift line text to > the right unless absolutely necessary, so those issues don't > materialize. (let ((window (split-window-horizontally))) (set-window-margins window 0 0) (set-window-fringes window 0 0)) Now move the divider between the two windows as far as possible to the right and in the window on the right move to the end of the first line. Here a '$' appears at the beginning of each line > I think you're trying too hard to stay away from the margins. But > anyway, we have the alternative solution now. Back then I considered Markus' idea to use the margins quite ingenious (actually, I didn't believe it would work in practice). Still I always voted in favor of having line numbers provided by the redisplay engine. I also voted for a line numbers cache like that of (or even in combination with) the 'syntax-ppss' cache but that's a different subject. Maybe one day Eli will come up with a redesign which would allow to divide a window into side-by-side subwindows that would share a common scroll bar so ‘follow-mode’ would be done entirely by the display engine. And each such subwindow would have an arbitrary number of subwindows usable as margins for that window and a line number subwindow and whatever else we want. > I can't see a way to create a less-than-fullscreen frame in terminal > Emacs (speaking of normal frames here). Popup frames (or tooltip frames) on terminals would have to be emulated as we currently do for menus. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 15:59 ` martin rudalics @ 2017-06-25 16:24 ` Dmitry Gutov 2017-06-25 17:10 ` martin rudalics 2017-06-25 18:24 ` Eli Zaretskii 2017-06-25 19:00 ` Eli Zaretskii 1 sibling, 2 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-25 16:24 UTC (permalink / raw) To: martin rudalics, Eli Zaretskii; +Cc: alexanderm, 27427 On 6/25/17 6:59 PM, martin rudalics wrote: > (let ((window (split-window-horizontally))) > (set-window-margins window 0 0) > (set-window-fringes window 0 0)) > > Now move the divider between the two windows as far as possible to the > right and in the window on the right move to the end of the first line. > Here a '$' appears at the beginning of each line Thanks. Still, the popup is positioned correctly here in this scenario. > Maybe one day Eli will come up with a redesign which would allow to > divide a window into side-by-side subwindows that would share a common > scroll bar so ‘follow-mode’ would be done entirely by the display > engine. And each such subwindow would have an arbitrary number of > subwindows usable as margins for that window and a line number subwindow > and whatever else we want. I'd rather think in terms of "submargins", one per "category", and having an alist of particular properties of each of those categories. > > I can't see a way to create a less-than-fullscreen frame in terminal > > Emacs (speaking of normal frames here). > > Popup frames (or tooltip frames) on terminals would have to be emulated > as we currently do for menus. Thanks for commenting. Weren't menus in the terminal rendered using a certain special method, different from overlays? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 16:24 ` Dmitry Gutov @ 2017-06-25 17:10 ` martin rudalics 2017-06-25 18:36 ` Eli Zaretskii 2017-06-25 18:24 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-25 17:10 UTC (permalink / raw) To: Dmitry Gutov, Eli Zaretskii; +Cc: alexanderm, 27427 > I'd rather think in terms of "submargins", one per "category", and > having an alist of particular properties of each of those categories. Once we do that we should try to accommodate as much as possible in the concept we provide and I think that having ‘follow-mode’ implemented by the display engine would be quite valuable. So I would vote for a more general solution that encompasses it as well. > Weren't menus in the terminal rendered using a certain special method, > different from overlays? I think it boils down to the same underlying concept: Have the display engine replace one text with another profiting from the restriction that on terminals all characters are created equal. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 17:10 ` martin rudalics @ 2017-06-25 18:36 ` Eli Zaretskii 2017-06-25 18:51 ` Eli Zaretskii 2017-06-26 8:18 ` martin rudalics 0 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 18:36 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sun, 25 Jun 2017 19:10:01 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: alexanderm@web.de, 27427@debbugs.gnu.org > > > I'd rather think in terms of "submargins", one per "category", and > > having an alist of particular properties of each of those categories. > > Once we do that we should try to accommodate as much as possible in the > concept we provide and I think that having ‘follow-mode’ implemented by > the display engine would be quite valuable. So I would vote for a more > general solution that encompasses it as well. I think people who lobby for more extensive and flexible use of the margins underestimate the amount of work something like that will take. The current management of the margin display is exceedingly rudimentary. Most of the sophisticated layout stuff we have in the text area -- truncation and continuation markers, word-wrap, etc. -- all that doesn't exist there. And the cursor cannot enter the margins. Basically, we just put there glyphs until the available space is exhausted, and that's it. By contrast, you guys are dreaming about full-fledged additional "text areas" with all the features we now support in the single one we have. That's an entirely new ballpark game, although I agree that it's a natural generalization and extension of what we have. The problem is that the knowledge of the basic canvas geometry is hard-coded in many places in the display code, and all of them will have to be reworked. I think this would be a very good project and a significant progress for Emacs, so I'd welcome such a development. Just don't underestimate the magnitude of the task. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 18:36 ` Eli Zaretskii @ 2017-06-25 18:51 ` Eli Zaretskii 2017-06-26 8:21 ` martin rudalics 2017-06-26 8:18 ` martin rudalics 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 18:51 UTC (permalink / raw) To: rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sun, 25 Jun 2017 21:36:51 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: alexanderm@web.de, 27427@debbugs.gnu.org, dgutov@yandex.ru > > I think people who lobby for more extensive and flexible use of the > margins underestimate the amount of work something like that will > take. The current management of the margin display is exceedingly > rudimentary. Most of the sophisticated layout stuff we have in the > text area -- truncation and continuation markers, word-wrap, etc. -- > all that doesn't exist there. And the cursor cannot enter the > margins. Basically, we just put there glyphs until the available > space is exhausted, and that's it. > > By contrast, you guys are dreaming about full-fledged additional "text > areas" with all the features we now support in the single one we have. > That's an entirely new ballpark game, although I agree that it's a > natural generalization and extension of what we have. The problem is > that the knowledge of the basic canvas geometry is hard-coded in many > places in the display code, and all of them will have to be reworked. > > I think this would be a very good project and a significant progress > for Emacs, so I'd welcome such a development. Just don't > underestimate the magnitude of the task. Btw, it strikes me that if we want something like that, it should be much easier to provide side-by-side windows that scroll together or according to some predefined relation. This at least doesn't need to redesign the basic display geometry of a window, only to change the order in which we traverse the window tree -- instead of the current depth-first order we'd need some more complicated traversal, and perhaps also some redisplay considerations that look at more than one window at a time. Then just removing the scroll bars from all but one of these "lockstep" windows will get you what you want at a much smaller effort. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 18:51 ` Eli Zaretskii @ 2017-06-26 8:21 ` martin rudalics 0 siblings, 0 replies; 97+ messages in thread From: martin rudalics @ 2017-06-26 8:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > Btw, it strikes me that if we want something like that, it should be > much easier to provide side-by-side windows that scroll together or > according to some predefined relation. This at least doesn't need to > redesign the basic display geometry of a window, only to change the > order in which we traverse the window tree -- instead of the current > depth-first order we'd need some more complicated traversal, and > perhaps also some redisplay considerations that look at more than one > window at a time. Then just removing the scroll bars from all but one > of these "lockstep" windows will get you what you want at a much > smaller effort. This is precisely what I had in mind and why I pleaded for a uniform handling of windows elsewhere. The question is whether and how to treat margins, scroll bars and fringes as first class citizens in this regard. Our scroll bars are already partly windows partly frames. Hence considering them a shared resource like the tool or menu bar windows/frames should be straightforward. Margins, fringes and line numbers are subordinates but I would upgrade them so the display engine is mostly disconnected from the layout problem. Now I think we agree that two or more side-by-side windows emulating ‘follow-mode’ should share a single vertical scroll bar window whose slider size and position would be computed from the amount of text displayed in all of these windows taken together and the position of ‘point’ in the most recently selected window of them. I think we could also have these windows share a common fringe and a line number window. I'm less sure about the margins. I think a vertical divider should be provided separately for each window so the user can resize them separately with the mouse. And a horizontal scroll bar, if wanted, should be provided separately for each of the windows. There's probably no rule for sharing mode and header lines: A common mode line seems obviously preferable for ‘follow-mode’, a ruler in the header line can be hardly shared. An obvious problem ensuing from such an approach is, for example, that the display engine may decide that the size of the line number window must increase because one of the windows now has to display a larger maximum line number or because ‘point’ has moved from a window with a lower ‘point’ to a window with a higher one. This will trigger a check whether the remaining windows are still large enough and maybe how to enlarge them. So what is currently a local decision entirely embedded in your line numbers code would become a more global decision of window management. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 18:36 ` Eli Zaretskii 2017-06-25 18:51 ` Eli Zaretskii @ 2017-06-26 8:18 ` martin rudalics 1 sibling, 0 replies; 97+ messages in thread From: martin rudalics @ 2017-06-26 8:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > By contrast, you guys are dreaming about full-fledged additional "text > areas" with all the features we now support in the single one we have. I suppose that's me only. IIUC Dmitry would be content with just getting multiple margins exhibiting the same behavior as they do now. What I mean is that rather than thinking about how to improve a concept like that of margins I'd invent a framework where we can provide an arbitrary amount of arbitrary-sized windows that can be later used for any purpose by the display engine among them as margins. > That's an entirely new ballpark game, although I agree that it's a > natural generalization and extension of what we have. The problem is > that the knowledge of the basic canvas geometry is hard-coded in many > places in the display code, and all of them will have to be reworked. Correct. But the underlying concept exists already---in window.c. The hard part is obviously that of synchronizing the display of windows, for example, to make sure that text laid out in the margins and fringes has the expected line-to-line coherence with text laid out in the corresponding text window. > I think this would be a very good project and a significant progress > for Emacs, so I'd welcome such a development. Just don't > underestimate the magnitude of the task. I already had my share of this when I attempted to implement horizontal scroll bars on the top of windows. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 16:24 ` Dmitry Gutov 2017-06-25 17:10 ` martin rudalics @ 2017-06-25 18:24 ` Eli Zaretskii 2017-06-26 7:15 ` martin rudalics 2017-06-26 8:18 ` martin rudalics 1 sibling, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 18:24 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 27427, alexanderm > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sun, 25 Jun 2017 19:24:21 +0300 > > Weren't menus in the terminal rendered using a certain special method, > different from overlays? Yes. We simply overwrite the glyph matrices with the menu contents, and then force a screen update. But this cannot work for features that want Emacs to return to the main loop, because anything that triggers any kind of redisplay will restore portions of the display from buffer text and mess up the menu. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 18:24 ` Eli Zaretskii @ 2017-06-26 7:15 ` martin rudalics 2017-06-26 8:18 ` martin rudalics 1 sibling, 0 replies; 97+ messages in thread From: martin rudalics @ 2017-06-26 7:15 UTC (permalink / raw) To: Eli Zaretskii, Dmitry Gutov; +Cc: alexanderm, 27427 >> Cc: alexanderm@web.de, 27427@debbugs.gnu.org >> From: Dmitry Gutov <dgutov@yandex.ru> >> Date: Sun, 25 Jun 2017 19:24:21 +0300 >> >> Weren't menus in the terminal rendered using a certain special method, >> different from overlays? > > Yes. We simply overwrite the glyph matrices with the menu contents, > and then force a screen update. > > But this cannot work for features that want Emacs to return to the > main loop, because anything that triggers any kind of redisplay will > restore portions of the display from buffer text and mess up the menu. > ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 18:24 ` Eli Zaretskii 2017-06-26 7:15 ` martin rudalics @ 2017-06-26 8:18 ` martin rudalics 2017-06-26 12:07 ` Dmitry Gutov 2017-06-26 15:05 ` Eli Zaretskii 1 sibling, 2 replies; 97+ messages in thread From: martin rudalics @ 2017-06-26 8:18 UTC (permalink / raw) To: Eli Zaretskii, Dmitry Gutov; +Cc: alexanderm, 27427 > Yes. We simply overwrite the glyph matrices with the menu contents, > and then force a screen update. We would have to do the same for popups. > But this cannot work for features that want Emacs to return to the > main loop, because anything that triggers any kind of redisplay will > restore portions of the display from buffer text and mess up the menu. And for popups it would just have to overwrite the glyph matrix again. Or what am I missing? Yet I doubt that such popups would be desirable on terminal frames. For my taste, they would appear far too obtrusive and distracting. I think any such popup should be treated like a tooltip and get displayed in the echo area. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 8:18 ` martin rudalics @ 2017-06-26 12:07 ` Dmitry Gutov 2017-06-26 15:05 ` Eli Zaretskii 1 sibling, 0 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-26 12:07 UTC (permalink / raw) To: martin rudalics, Eli Zaretskii; +Cc: alexanderm, 27427 On 6/26/17 11:18 AM, martin rudalics wrote: > Yet I doubt that such popups would be desirable on terminal frames. For > my taste, they would appear far too obtrusive and distracting. I think > any such popup should be treated like a tooltip and get displayed in the > echo area. We already have a company-mode frontend that uses the echo area to show completions (two of them, actually, slightly different from each other). Problem is, it's hard to fit the same information you would in a popup, and the echo area is used for other things (often at the same time): e.g. ElDoc, as well as some extra info that company-mode shows for the currently selected completion. So the user would have to give up that. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 8:18 ` martin rudalics 2017-06-26 12:07 ` Dmitry Gutov @ 2017-06-26 15:05 ` Eli Zaretskii 2017-06-27 7:06 ` martin rudalics 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-26 15:05 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Mon, 26 Jun 2017 10:18:10 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: alexanderm@web.de, 27427@debbugs.gnu.org > > > Yes. We simply overwrite the glyph matrices with the menu contents, > > and then force a screen update. > > We would have to do the same for popups. Doing that behind the back of the display engine is problematic, see below. > > But this cannot work for features that want Emacs to return to the > > main loop, because anything that triggers any kind of redisplay will > > restore portions of the display from buffer text and mess up the menu. > > And for popups it would just have to overwrite the glyph matrix again. > Or what am I missing? If we let Emacs escape into the main loop, we cannot control when redisplay kicks in and what effect does it have. For example, some timer could display a message that could be longer than a single screen line, so Emacs will resize the echo area and as result redisplay the windows above the mode line. Since the text of the popup comes from a source about which the display engine knows absolutely nothing, redisplay will do its job assuming that the screen shows the contents before we overwrote it, and thus will completely mess up the display. Even if the code which displayed the popup gets control right away (which isn't guaranteed in general, since company-mode wants to be able to run arbitrary Lisp given user interaction with the popup), the user will see a momentary flash of messed-up display. > Yet I doubt that such popups would be desirable on terminal frames. For > my taste, they would appear far too obtrusive and distracting. I think > any such popup should be treated like a tooltip and get displayed in the > echo area. I don't see how the echo area can fit the job, since the space there is very small and there's no way to let the user select an alternative using menu-like interaction. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 15:05 ` Eli Zaretskii @ 2017-06-27 7:06 ` martin rudalics 2017-06-27 14:48 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-27 7:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > If we let Emacs escape into the main loop, we cannot control when > redisplay kicks in and what effect does it have. For example, some > timer could display a message that could be longer than a single > screen line, so Emacs will resize the echo area and as result > redisplay the windows above the mode line. Since the text of the > popup comes from a source about which the display engine knows > absolutely nothing, redisplay will do its job assuming that the screen > shows the contents before we overwrote it, and thus will completely > mess up the display. Even if the code which displayed the popup gets > control right away (which isn't guaranteed in general, since > company-mode wants to be able to run arbitrary Lisp given user > interaction with the popup), the user will see a momentary flash of > messed-up display. I assume that the buffer position of the popup would have been specified by company-mode before. Hence, if on a terminal the character at that position would get displayed, the display engine would try to display the overlay for the popup there instead. On the right and below of that position if it fits, "anywhere there" otherwise, possibly truncating it to keep the echo area free as you did for menus. And that overlay would stick at that buffer position until company-mode removes it. So resizing the echo area would, in the worst case, not display the popup because its buffer position would be temporarily off screen. But I can't imagine any mess up here. > I don't see how the echo area can fit the job, since the space there > is very small and there's no way to let the user select an alternative > using menu-like interaction. The echo area can be resized and can emulate any menu-like interaction. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-27 7:06 ` martin rudalics @ 2017-06-27 14:48 ` Eli Zaretskii 2017-06-27 15:27 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-27 14:48 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Tue, 27 Jun 2017 09:06:06 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > If we let Emacs escape into the main loop, we cannot control when > > redisplay kicks in and what effect does it have. For example, some > > timer could display a message that could be longer than a single > > screen line, so Emacs will resize the echo area and as result > > redisplay the windows above the mode line. Since the text of the > > popup comes from a source about which the display engine knows > > absolutely nothing, redisplay will do its job assuming that the screen > > shows the contents before we overwrote it, and thus will completely > > mess up the display. Even if the code which displayed the popup gets > > control right away (which isn't guaranteed in general, since > > company-mode wants to be able to run arbitrary Lisp given user > > interaction with the popup), the user will see a momentary flash of > > messed-up display. > > I assume that the buffer position of the popup would have been specified > by company-mode before. Hence, if on a terminal the character at that > position would get displayed, the display engine would try to display > the overlay for the popup there instead. On the right and below of that > position if it fits, "anywhere there" otherwise, possibly truncating it > to keep the echo area free as you did for menus. And that overlay would > stick at that buffer position until company-mode removes it. > > So resizing the echo area would, in the worst case, not display the > popup because its buffer position would be temporarily off screen. But > I can't imagine any mess up here. I think we are miscommunicating. I was describing what would happen if we try to use the same method as used for TTY menus. There are no overlays there, the glyphs are concocted out of thin air by C code and put into the glyph matrices, overwriting what the display engine thinks should be there. By contrast, you are talking about using an overlay, which is what company-mode is using already, and which is the source of the trouble Dmitry would like to avoid. The basic problem here is that the company-mode popup is multiline, and Emacs cannot display rectangular regions, only lines. So company-mode inserts newlines into the overlay string, and the result is that the popup covers parts of the display which company-mode doesn't want to conceal. So it needs to copy those parts to the overlay string, to make the impression they weren't covered by the overlay. It also needs to make all kinds of layout calculations and decisions. All that in order to make an impression of displaying a rectangular region at certain screen coordinates, something that we ideally should have provided in the display engine. > > I don't see how the echo area can fit the job, since the space there > > is very small and there's no way to let the user select an alternative > > using menu-like interaction. > > The echo area can be resized and can emulate any menu-like interaction. Yes, but not conveniently. And if we are going to emulate, why use the echo area at all? why not pop up a buffer, like Help mode does? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-27 14:48 ` Eli Zaretskii @ 2017-06-27 15:27 ` martin rudalics 2017-06-27 16:27 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-27 15:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > I think we are miscommunicating. I was describing what would happen > if we try to use the same method as used for TTY menus. There are no > overlays there, the glyphs are concocted out of thin air by C code and > put into the glyph matrices, overwriting what the display engine > thinks should be there. > > By contrast, you are talking about using an overlay, Sorry for being unclear. I did mean overlaying text just as the menu bar code does and did not mean overlays as produced by ‘make-overlay’. > which is what > company-mode is using already, and which is the source of the trouble > Dmitry would like to avoid. The basic problem here is that the > company-mode popup is multiline, and Emacs cannot display rectangular > regions, only lines. But here we talk about the terminal where Emacs can display rectangular regions because all elements displayed have the same size (the menu bar code proves it). So such a region can cover mode and header lines, span multiple (Emacs) windows---virtually everything that can be found within the frame edges. > So company-mode inserts newlines into the > overlay string, ... which is evil because it has to calculate the beginning of the second overlay (in the sense of being made by ‘make-overlay’) string which is hardly reliable with proportional fonts, text properties and all sorts of display artefacts including overlays strings produced by someone else. > and the result is that the popup covers parts of the > display which company-mode doesn't want to conceal. So it needs to > copy those parts to the overlay string, to make the impression they > weren't covered by the overlay. It also needs to make all kinds of > layout calculations and decisions. All that in order to make an > impression of displaying a rectangular region at certain screen > coordinates, something that we ideally should have provided in the > display engine. And I still think we can do that for terminals without any problems using the same approach you used for menus. All we need is the buffer position (whose character represents the preferred upper left corner of the virtual rectangle) and the text to be shown (with newlines). Any clipping or repositioning is up to the display engine as for menus. And the lifetime of the rectangular region on screen is that of the popup frame on a GUI. >> > I don't see how the echo area can fit the job, since the space there >> > is very small and there's no way to let the user select an alternative >> > using menu-like interaction. >> >> The echo area can be resized and can emulate any menu-like interaction. > > Yes, but not conveniently. And if we are going to emulate, why use > the echo area at all? why not pop up a buffer, like Help mode does? Sure. The echo area is used by tooltip mode and simple questions on terminals, that's why I mentioned it at all. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-27 15:27 ` martin rudalics @ 2017-06-27 16:27 ` Eli Zaretskii 2017-06-28 8:45 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-27 16:27 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Tue, 27 Jun 2017 17:27:45 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > Sorry for being unclear. I did mean overlaying text just as the menu > bar code does and did not mean overlays as produced by ‘make-overlay’. Then I don't understand what you are suggesting. > But here we talk about the terminal where Emacs can display rectangular > regions because all elements displayed have the same size (the menu bar > code proves it). Menu code proves that we can do that, but it also proves that we must prevent Emacs from redisplaying anything for the entire time the menu is active. We do that in the menu case by various tricks, but those are only possible because as long as the menu is active, Emacs is conceptually stuck in a long input operation, and thus preventing redisplay raises only minor issues, like display-time stops updating. But company-mode wants to be able to reflect the current selection immediately, even before the popup pops down (AFAIU), and in general wants to be able to run arbitrary Lisp during the popup activation, and that just cannot live with the tricks used by TTY menus, because sooner or later redisplay will happen, and will mess up the screen, as the glyph matrix created from buffer text will overwrite the stuff we put there. I hope I explained myself this time. > So such a region can cover mode and header lines, span multiple > (Emacs) windows---virtually everything that can be found within the > frame edges. It can -- until the first time redisplay kicks in. > And I still think we can do that for terminals without any problems > using the same approach you used for menus. All we need is the buffer > position (whose character represents the preferred upper left corner of > the virtual rectangle) and the text to be shown (with newlines). Any > clipping or repositioning is up to the display engine as for menus. But the display engine is not involved in the TTY menus, at least not in the usual sense. Please take a look at the second half of display_menu_bar, and you will see what I mean. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-27 16:27 ` Eli Zaretskii @ 2017-06-28 8:45 ` martin rudalics 2017-06-28 16:48 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-28 8:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > But the display engine is not involved in the TTY menus, at least not > in the usual sense. Please take a look at the second half of > display_menu_bar, and you will see what I mean. Isn't display_menu_bar the code for displaying a non-X GUI menu? I suppose you allude to the "while (!leave)" part of tty_menu_activate. Please correct me if I'm wrong. I don't understand why this should be relevant for popup frames, probably because I'm too silly. So let me try again how I think a popup frame could be emulated on a TTY. Currently, on a TTY a popup frame is nothing else but a normal frame because all special frame parameters are inhibited. Hence, it will have the same size and position as the frame above which it is supposed to pop up, which doesn't make any sense. To specify the position and contents of a popup frame on a TTY I see two ways: Either in the buffer text via a normal Emacs overlay with a say 'tty-popup' property or via a separate list say ‘tty-popup-frames’. The following sketch is based on the former. An overlay with a 'tty-popup' property would specify a buffer position and a newline separated text. The buffer position would implicitly provide the upper left corner of the popup frame, the text its size. The display engine would notice the overlay like any other overlay. However, the 'tty-popup' property would cause it to (1) remember the current column of the iterator and (2) draw the first line of the overlay right where the iterator is at this moment, possibly clipping this line of the overlay text at the frame edge and skipping as many characters of underlying buffer text as there are on this overlay text line. On the next buffer text line the display engine would start to draw the second line of the overlay text at the column remembered in (1), clipping and skipping as on the first line. It would continue to process the overlay until either its text has been used up or the bottom of the window or the frame's root window has been reached. Any redisplay would now redraw the popup frame in the same way, possibly at a different position or with different size. The overlay would probably need a 'window' property to allow showing the same buffer position in several windows and some convention would be needed for how to draw overlapping popup frames. The overlay would be removed from its buffer by the same function that makes the GUI popup frame invisible or kills it. Removing the overlay would cause a redraw just like removing a GUI popup frame would cause an expose event and a subsequent redraw. I don't think that the extra check for the column stored in (1) would be overly expensive. If a separate ‘tty-popup-frames’ list were used (each entry containing a buffer position and a newline separated text), then an approach where the desired glyph matrix is overwritten as with TTY menus would be used. This would remove the need for (1) at the expense of calculating the desired position of the popup in the glyph matrix from the buffer position and the need to overwrite the relevant portions of the desired glyph matrix. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-28 8:45 ` martin rudalics @ 2017-06-28 16:48 ` Eli Zaretskii 2017-06-28 18:35 ` martin rudalics 2017-06-29 1:34 ` Dmitry Gutov 0 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-28 16:48 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Wed, 28 Jun 2017 10:45:26 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > But the display engine is not involved in the TTY menus, at least not > > in the usual sense. Please take a look at the second half of > > display_menu_bar, and you will see what I mean. > > Isn't display_menu_bar the code for displaying a non-X GUI menu? I > suppose you allude to the "while (!leave)" part of tty_menu_activate. > Please correct me if I'm wrong. I don't understand why this should be > relevant for popup frames, probably because I'm too silly. Sorry, you are right. I meant display_tty_menu_item. > An overlay with a 'tty-popup' property would specify a buffer position > and a newline separated text. The buffer position would implicitly > provide the upper left corner of the popup frame, the text its size. > > The display engine would notice the overlay like any other overlay. > However, the 'tty-popup' property would cause it to (1) remember the > current column of the iterator and (2) draw the first line of the > overlay right where the iterator is at this moment, possibly clipping > this line of the overlay text at the frame edge and skipping as many > characters of underlying buffer text as there are on this overlay text > line. > > On the next buffer text line the display engine would start to draw the > second line of the overlay text at the column remembered in (1), > clipping and skipping as on the first line. It would continue to > process the overlay until either its text has been used up or the bottom > of the window or the frame's root window has been reached. Alas, that is not how redisplay works. For starters, you seem to assume that it always traverses all the screen lines of a window (thus "on the next buffer line" etc.). But that is only so when a window needs a complete redisplay, and the display engine tries very hard to avoid that. Many times it only redraws some of the lines, sometimes just one line. If that line is not the first line of the popup, how will the display engine know that at some previous buffer position there is an overlay? Moreover, the same low-level display code is invoked by the move_it_* functions which simulate display without drawing anything, and those are very often invoked to traverse small portions of a buffer, typically a small number of lines. These will be in trouble as well, for the same reason. So we need a different solution, one that doesn't break due to redisplay optimizations. Dmitry, can you tell why the popup overlay is a single overlay with a single multiline string, and not a series of overlays, one each for every line shown in the popup? I assume this caused or could cause more serious problems than the current implementation, but what problems were those? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-28 16:48 ` Eli Zaretskii @ 2017-06-28 18:35 ` martin rudalics 2017-06-28 18:56 ` Eli Zaretskii 2017-06-29 1:34 ` Dmitry Gutov 1 sibling, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-28 18:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > Alas, that is not how redisplay works. For starters, you seem to > assume that it always traverses all the screen lines of a window (thus > "on the next buffer line" etc.). But that is only so when a window > needs a complete redisplay, and the display engine tries very hard to > avoid that. Many times it only redraws some of the lines, sometimes > just one line. If that line is not the first line of the popup, how > will the display engine know that at some previous buffer position > there is an overlay? Because an application would include that very line in the 'tty-popup' overlay BEG...END range and the display engine has to know how to handle an overlay that spans multiple lines. Right? > Moreover, the same low-level display code is invoked by the move_it_* > functions which simulate display without drawing anything, and those > are very often invoked to traverse small portions of a buffer, > typically a small number of lines. These will be in trouble as well, > for the same reason. And still would have to be able to handle multiline overlays as described above. > So we need a different solution, one that doesn't break due to > redisplay optimizations. Then consider the ‘tty-popup-frames’ list approach: It would have to remember the start and end glyph matrix positions of the popup frame as drawn the last time and if these intersect with what has been redrawn in an optimized way then it would have to (1) restore the old contents of the popup frame by the real buffer text, if necessary and (2) rewrite popup frame parts, if necessary. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-28 18:35 ` martin rudalics @ 2017-06-28 18:56 ` Eli Zaretskii 2017-06-29 7:17 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-28 18:56 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Wed, 28 Jun 2017 20:35:50 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > Alas, that is not how redisplay works. For starters, you seem to > > assume that it always traverses all the screen lines of a window (thus > > "on the next buffer line" etc.). But that is only so when a window > > needs a complete redisplay, and the display engine tries very hard to > > avoid that. Many times it only redraws some of the lines, sometimes > > just one line. If that line is not the first line of the popup, how > > will the display engine know that at some previous buffer position > > there is an overlay? > > Because an application would include that very line in the 'tty-popup' > overlay BEG...END range and the display engine has to know how to handle > an overlay that spans multiple lines. Right? I cannot answer this question, it's too general. And doesn't company-mode use before- and after-strings, at least sometimes? Those have BEG and END the same value, so you must hit that position to know something's there. > Then consider the ‘tty-popup-frames’ list approach: It would have to > remember the start and end glyph matrix positions of the popup frame as > drawn the last time and if these intersect with what has been redrawn in > an optimized way then it would have to (1) restore the old contents of > the popup frame by the real buffer text, if necessary and (2) rewrite > popup frame parts, if necessary. That'll cause flickering, as users will see "incorrect" stuff momentarily visible until the popup is restored. Moreover, the "redrawn" part is in dispnew.c routines, called long after xdisp.c did its job. I think the only workable idea is to create a special kind of window that is not part of the usual window tree, and let the display engine consider those windows after the "normal" ones have been. Do popup frames need to support windows, mode lines, etc? Or are they more like tooltips -- one window and no decorations? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-28 18:56 ` Eli Zaretskii @ 2017-06-29 7:17 ` martin rudalics 2017-06-29 16:29 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-29 7:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov >> Because an application would include that very line in the 'tty-popup' >> overlay BEG...END range and the display engine has to know how to handle >> an overlay that spans multiple lines. Right? > > I cannot answer this question, it's too general. And doesn't > company-mode use before- and after-strings, at least sometimes? Those > have BEG and END the same value, so you must hit that position to know > something's there. Obviously, ‘company-mode’ would have to get rid of all earlier workarounds. Likely we would encapsulate the TTY/GUI differences in a separate function or macro. > I think the only workable idea is to create a special kind of window > that is not part of the usual window tree, and let the display engine > consider those windows after the "normal" ones have been. Do popup > frames need to support windows, mode lines, etc? Or are they more > like tooltips -- one window and no decorations? Note that so far the concept "popup frame" does not exist yet. If the window system supports them, we have child frames, undecorated frames, override redirect frames and some more. All these are full-fledged frames but we can easily provide restrictions, single window only, no echo area, no mode or header lines ... you name it. But note in this context that a native Emacs tooltip frame is not very viable. It works only because it's so ephemeral that before Lisp code has a chance to lay its hands on it, it has already disappeared. In this sense, a tooltip is similar to a TTY menu---an application cannot disrupt its display. So the answer to your question is: We can supply any restrictions the TTY display code would need although I'd prefer to call this a "special kind of frame" and not a "special kind of window". martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-29 7:17 ` martin rudalics @ 2017-06-29 16:29 ` Eli Zaretskii 2017-06-30 8:27 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-29 16:29 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Thu, 29 Jun 2017 09:17:41 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > So the answer to your question is: We can supply any restrictions the > TTY display code would need although I'd prefer to call this a "special > kind of frame" and not a "special kind of window". I prefer "window" for the simple reason that doing so will most probably wreak the least havoc on TTY display, in particular because it won't invalidate the assumption that only one frame is visible at any given time. Also, frames can have decorations, even on a TTY, which we are better without in this case. And finally, you most probably remember that TTY redisplay is frame-based, so having just one of them would fit better. Should be a nice project. Any takers? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-29 16:29 ` Eli Zaretskii @ 2017-06-30 8:27 ` martin rudalics 2017-06-30 9:33 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-30 8:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > I prefer "window" for the simple reason that doing so will most > probably wreak the least havoc on TTY display, in particular because > it won't invalidate the assumption that only one frame is visible at > any given time. Also, frames can have decorations, even on a TTY, > which we are better without in this case. And finally, you most > probably remember that TTY redisplay is frame-based, so having just > one of them would fit better. As a window it won't appear on any window list since it's got no frame. If we made it a window of the frame where we popped it up, then where would we put it into that frame's window tree? The window tree code is not very clean, but changing it for the sake of TTY popups sounds like very intrusive surgery. All the (implicit) invariants that window sizes have to sum up would get invalidated. Suppose we spliced in some special TTY_popup_window_list slot for every frame. Then we'd have to invent functions for accessing and changing its elements. If such an element were an Emacs window, practically all functions that access and change windows and their properties would have to be rewritten in consequence of that. This is hardly feasible. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-30 8:27 ` martin rudalics @ 2017-06-30 9:33 ` Eli Zaretskii 2017-07-01 10:31 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-30 9:33 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Fri, 30 Jun 2017 10:27:50 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > Suppose we spliced in some special TTY_popup_window_list slot for every > frame. That's what I had in mind, yes. > Then we'd have to invent functions for accessing and changing its > elements. We already have functions for accessing elements of lists and changing lists. > If such an element were an Emacs window, practically all functions > that access and change windows and their properties would have to be > rewritten in consequence of that. What functions are you alluding to here, specifically? And what did you mean by "an Emacs window"? My idea was that these windows would be "special", in that they could only display some special buffer or maybe only a string. About the only function we'd need is to set the coordinates where such a window will be displayed. Everything else, including the dimensions, will be determined by the text to be displayed there. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-30 9:33 ` Eli Zaretskii @ 2017-07-01 10:31 ` martin rudalics 2017-07-01 11:59 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-07-01 10:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > My idea was that these windows would be "special", in that they could > only display some special buffer or maybe only a string. Then we are back at my earlier ‘tty-popup-frames’ proposal with "windows" substituting "frames". Please lets call these objects "popups" for now. > About the > only function we'd need is to set the coordinates where such a window > will be displayed. Everything else, including the dimensions, will be > determined by the text to be displayed there. We'd have to decide when to call the function that sets the coordinates. For that purpose each popup would probably have to store the window it originated from to handle scrolling of that window and any changes to its buffer. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-01 10:31 ` martin rudalics @ 2017-07-01 11:59 ` Eli Zaretskii 2017-07-01 13:22 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-07-01 11:59 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sat, 01 Jul 2017 12:31:49 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > My idea was that these windows would be "special", in that they could > > only display some special buffer or maybe only a string. > > Then we are back at my earlier ‘tty-popup-frames’ proposal with > "windows" substituting "frames". Please lets call these objects > "popups" for now. OK. > > About the > > only function we'd need is to set the coordinates where such a window > > will be displayed. Everything else, including the dimensions, will be > > determined by the text to be displayed there. > > We'd have to decide when to call the function that sets the coordinates. I hoped the application would do that, via some new API. > For that purpose each popup would probably have to store the window it > originated from to handle scrolling of that window and any changes to > its buffer. That could be one way, but maybe we could use something more direct. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-01 11:59 ` Eli Zaretskii @ 2017-07-01 13:22 ` martin rudalics 2017-07-01 13:33 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-07-01 13:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > I hoped the application would do that, via some new API. We'd at least need something like a ‘TTY-check-popup-functions’ called immediately before the display engine looks at the popups list: The application could then check whether its popup is still relevant and whether is should be redisplayed, possibly at a different location, with different text. If the application decides that nothing should be changed and the desired matrix and the current matrix are the same for a specific popup, the display engine would probably leave that popup in the desired matrix alone. >> For that purpose each popup would probably have to store the window it >> originated from to handle scrolling of that window and any changes to >> its buffer. > > That could be one way, but maybe we could use something more direct. So far, the implementation of child and undecorated frames is complete. Hence, for the moment I intend to proceed as follows: People who need such frames should read the manual and try to provide a GUI solution for their problem. As soon as we have a few samples that work satisfactorily on GUI systems, we can try to implement a fairly useful workaround for TTY systems. However, if people say they need to select such frames or put the cursor into one of their windows, we have to rethink how to implement a TTY solution if it's viable at all. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-01 13:22 ` martin rudalics @ 2017-07-01 13:33 ` Eli Zaretskii 2017-07-01 15:20 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-07-01 13:33 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sat, 01 Jul 2017 15:22:43 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > I hoped the application would do that, via some new API. > > We'd at least need something like a ‘TTY-check-popup-functions’ called > immediately before the display engine looks at the popups list: The > application could then check whether its popup is still relevant and > whether is should be redisplayed, possibly at a different location, with > different text. Why not the other way around: let the application specify the text and the position of the popup in dedicated variables, and then redisplay could just access those as part of its job? > So far, the implementation of child and undecorated frames is complete. > Hence, for the moment I intend to proceed as follows: People who need > such frames should read the manual and try to provide a GUI solution for > their problem. As soon as we have a few samples that work > satisfactorily on GUI systems, we can try to implement a fairly useful > workaround for TTY systems. However, if people say they need to select > such frames or put the cursor into one of their windows, we have to > rethink how to implement a TTY solution if it's viable at all. Sounds like a good plan, thanks. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-01 13:33 ` Eli Zaretskii @ 2017-07-01 15:20 ` martin rudalics 2017-07-01 15:41 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-07-01 15:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > Why not the other way around: let the application specify the text and > the position of the popup in dedicated variables, and then redisplay > could just access those as part of its job? The application has to react when a given buffer position changes its position on screen. If ‘window-text-change-functions’ is sufficient to determine that (I never used it), it could add itself to that hook and specify the popup accordingly. Otherwise, the application would have to track whether the window was scrolled, resized or moved, or its buffer modified. Or, for example, whether an overlay before the popup position changed from visible to invisible. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-01 15:20 ` martin rudalics @ 2017-07-01 15:41 ` Eli Zaretskii 2017-07-02 7:54 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-07-01 15:41 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sat, 01 Jul 2017 17:20:34 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > Why not the other way around: let the application specify the text and > > the position of the popup in dedicated variables, and then redisplay > > could just access those as part of its job? > > The application has to react when a given buffer position changes its > position on screen. Yes, but I presumed it will do it the same way company-mode reacts to such changes today. Currently. company-mode recomputes and moves its overlay; it will instead recompute the text and its position. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-01 15:41 ` Eli Zaretskii @ 2017-07-02 7:54 ` martin rudalics 2017-07-02 14:10 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-07-02 7:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > Yes, but I presumed it will do it the same way company-mode reacts to > such changes today. Currently. company-mode recomputes and moves its > overlay; it will instead recompute the text and its position. To my knowledge ‘company-mode’ and all packages trying to solve similar display problems are based on idle timers. The overlay is moved, if necessry, when the timeout expires. I'm not sure whether it makes sense to use a timer-less approach. If it does, we should allow moving the overlay right after recalculating the frame's glyph matrix on TTYs. Whether removing timers makes sense for GUIs is yet another question. In this context the ‘window-text-change-functions’ I mentioned earlier seems completely useless. Here doing for example (add-hook 'window-text-change-functions 'ignore) just gets me into a loop and I have to kill Emacs. Also, it's not clear to me why this hook is considered abnormal and how to identify from Elisp the window that is redisplayed at the time the hook is run. The fact that the window's buffer is current at that time is hardly useful. So I think we should either remove that hook or completely redesign it. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-02 7:54 ` martin rudalics @ 2017-07-02 14:10 ` Eli Zaretskii 2017-07-02 14:45 ` Dmitry Gutov 2017-07-06 7:08 ` martin rudalics 0 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-07-02 14:10 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sun, 02 Jul 2017 09:54:12 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > Yes, but I presumed it will do it the same way company-mode reacts to > > such changes today. Currently. company-mode recomputes and moves its > > overlay; it will instead recompute the text and its position. > > To my knowledge ‘company-mode’ and all packages trying to solve similar > display problems are based on idle timers. I thought they used post-command-hook, but I will let Dmitry comment on that. > In this context the ‘window-text-change-functions’ I mentioned earlier > seems completely useless. Here doing for example > > (add-hook 'window-text-change-functions 'ignore) > > just gets me into a loop and I have to kill Emacs. Also, it's not clear > to me why this hook is considered abnormal and how to identify from > Elisp the window that is redisplayed at the time the hook is run. The > fact that the window's buffer is current at that time is hardly useful. > So I think we should either remove that hook or completely redesign it. This hook ws introduced for linum.el, but linum.el as added to Emacs never used it. We should delete the hook and any references to it in the manuals. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-02 14:10 ` Eli Zaretskii @ 2017-07-02 14:45 ` Dmitry Gutov 2017-07-02 15:18 ` Eli Zaretskii 2017-07-06 7:08 ` martin rudalics 2017-07-06 7:08 ` martin rudalics 1 sibling, 2 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-07-02 14:45 UTC (permalink / raw) To: Eli Zaretskii, martin rudalics; +Cc: alexanderm, 27427 On 7/2/17 5:10 PM, Eli Zaretskii wrote: >> To my knowledge ‘company-mode’ and all packages trying to solve similar >> display problems are based on idle timers. > > I thought they used post-command-hook, but I will let Dmitry comment > on that. post-command hooks and non-idle timers. Not that it matters much. It would be nice if the popup were able to reposition itself when the Emacs window is resized, of course (post-command-hook doesn't always run in such cases), but we've been living well enough without that. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-02 14:45 ` Dmitry Gutov @ 2017-07-02 15:18 ` Eli Zaretskii 2017-07-03 0:22 ` Dmitry Gutov 2017-07-06 7:08 ` martin rudalics 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-07-02 15:18 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 27427, alexanderm > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sun, 2 Jul 2017 17:45:13 +0300 > > It would be nice if the popup were able to reposition itself when the > Emacs window is resized We could have a feature whereby the coordinates are determined by a specific buffer position shown in a "normal" window. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-02 15:18 ` Eli Zaretskii @ 2017-07-03 0:22 ` Dmitry Gutov 2017-07-03 2:29 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-07-03 0:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 7/2/17 6:18 PM, Eli Zaretskii wrote: > We could have a feature whereby the coordinates are determined by a > specific buffer position shown in a "normal" window. That's what I was thinking of as well. But that, in turn, might call for some extra features: When there is not enough space below the current line to show the popup, we display it above the current line. I'd expect the new popup code reposition it like that automatically as well. But: in company we have feature where, when the popup is displayed above the current line, the popup lines are inverted vertically (so that the first completion is the closest to the current line visually). I'm not a fan, but it's fairly popular. If the core popup handles repositioning, it would have to handle inverting (optionally) as well, or run some sort of hook to require the popup items to be recomputed. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-03 0:22 ` Dmitry Gutov @ 2017-07-03 2:29 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-07-03 2:29 UTC (permalink / raw) To: Dmitry Gutov; +Cc: alexanderm, 27427 > Cc: 27427@debbugs.gnu.org, alexanderm@web.de > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Mon, 3 Jul 2017 03:22:56 +0300 > > On 7/2/17 6:18 PM, Eli Zaretskii wrote: > > > We could have a feature whereby the coordinates are determined by a > > specific buffer position shown in a "normal" window. > > That's what I was thinking of as well. But that, in turn, might call for > some extra features: > > When there is not enough space below the current line to show the popup, > we display it above the current line. I'd expect the new popup code > reposition it like that automatically as well. > > But: in company we have feature where, when the popup is displayed above > the current line, the popup lines are inverted vertically (so that the > first completion is the closest to the current line visually). I'm not a > fan, but it's fairly popular. > > If the core popup handles repositioning, it would have to handle > inverting (optionally) as well, or run some sort of hook to require the > popup items to be recomputed. These are all doable, and AFAIU are needed even if the coordinates are specified by the application. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-02 14:45 ` Dmitry Gutov 2017-07-02 15:18 ` Eli Zaretskii @ 2017-07-06 7:08 ` martin rudalics 2017-07-06 13:06 ` Dmitry Gutov 1 sibling, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-07-06 7:08 UTC (permalink / raw) To: Dmitry Gutov, Eli Zaretskii; +Cc: alexanderm, 27427 > post-command hooks and non-idle timers. Not that it matters much. I don't understand the reasons for this combination. Inherently this emulates idle timers as also the variable names (‘company-idle-delay’, ‘company-tooltip-idle-delay’) indicate. > It would be nice if the popup were able to reposition itself when the > Emacs window is resized, of course (post-command-hook doesn't always > run in such cases), but we've been living well enough without that. Putting the function on ‘window-size-change-functions’ should handle that now. For earlier Emacs versions you probably have to resort to ‘window-configuration-change-hook’ as well. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-06 7:08 ` martin rudalics @ 2017-07-06 13:06 ` Dmitry Gutov 2017-07-07 6:52 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-07-06 13:06 UTC (permalink / raw) To: martin rudalics, Eli Zaretskii; +Cc: alexanderm, 27427 On 7/6/17 10:08 AM, martin rudalics wrote: > I don't understand the reasons for this combination. Inherently this > emulates idle timers as also the variable names (‘company-idle-delay’, > ‘company-tooltip-idle-delay’) indicate. We need post-command-hook anyway, to add or remove the timer depending on the last command. I don't recall the exact reasons for the choice between the idle and non-idle timers, but flyspell comes to mind (and its use of sit-for). > > It would be nice if the popup were able to reposition itself when the > > Emacs window is resized, of course (post-command-hook doesn't always > > run in such cases), but we've been living well enough without that. > > Putting the function on ‘window-size-change-functions’ should handle > that now. Maybe that's enough. What if the user moves the Emacs frame around with a mouse, without resizing? Will the tooltip window follow? > For earlier Emacs versions you probably have to resort to > ‘window-configuration-change-hook’ as well. They won't support the new style tooltips anyway. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-06 13:06 ` Dmitry Gutov @ 2017-07-07 6:52 ` martin rudalics 0 siblings, 0 replies; 97+ messages in thread From: martin rudalics @ 2017-07-07 6:52 UTC (permalink / raw) To: Dmitry Gutov, Eli Zaretskii; +Cc: alexanderm, 27427 > We need post-command-hook anyway, to add or remove the timer depending > on the last command. I don't recall the exact reasons for the choice > between the idle and non-idle timers, but flyspell comes to mind (and > its use of sit-for). It would be interesting to know these reasons to avoid reinventing that choice elsewhere. > Maybe that's enough. What if the user moves the Emacs frame around > with a mouse, without resizing? Will the tooltip window follow? A child frame automatically moves along with its parent. Normal frames must be moved manually. ‘move-frame-functions’ is the hook provided to do that. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-02 14:10 ` Eli Zaretskii 2017-07-02 14:45 ` Dmitry Gutov @ 2017-07-06 7:08 ` martin rudalics 2017-07-06 15:21 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-07-06 7:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov [-- Attachment #1: Type: text/plain, Size: 241 bytes --] > This hook ws introduced for linum.el, but linum.el as added to Emacs > never used it. We should delete the hook and any references to it in > the manuals. The attached patch tries to restore the state before its introduction. martin [-- Attachment #2: remove-window-text-change-functions.diff --] [-- Type: text/plain, Size: 3191 bytes --] diff --git a/doc/lispref/hooks.texi b/doc/lispref/hooks.texi index 0ac5b08..6443464 100644 --- a/doc/lispref/hooks.texi +++ b/doc/lispref/hooks.texi @@ -241,11 +241,6 @@ Standard Hooks @itemx window-scroll-functions @itemx window-size-change-functions @xref{Window Hooks}. - -@item window-text-change-functions -@vindex window-text-change-functions -Functions to call in redisplay when text in the window might change. - @end table @ignore diff --git a/src/xdisp.c b/src/xdisp.c index 8bc5d81..bd60ed2 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -16431,9 +16431,8 @@ enum eassert (XMARKER (w->start)->buffer == buffer); eassert (XMARKER (w->pointm)->buffer == buffer); - /* We come here again if we need to run window-text-change-functions - below. */ - restart: + specbind (Qinhibit_point_motion_hooks, Qt); + reconsider_clip_changes (w); frame_line_height = default_line_pixel_height (w); margin = window_scroll_margin (w, MARGIN_IN_LINES); @@ -16492,6 +16491,10 @@ enum /* Really select the buffer, for the sake of buffer-local variables. */ set_buffer_internal_1 (XBUFFER (w->contents)); + SET_TEXT_POS (opoint, PT, PT_BYTE); + + beg_unchanged = BEG_UNCHANGED; + end_unchanged = END_UNCHANGED; current_matrix_up_to_date_p = (w->window_end_valid @@ -16500,23 +16503,6 @@ enum && !window_outdated (w) && !hscrolling_current_line_p (w)); - /* Run the window-text-change-functions - if it is possible that the text on the screen has changed - (either due to modification of the text, or any other reason). */ - if (!current_matrix_up_to_date_p - && !NILP (Vwindow_text_change_functions)) - { - safe_run_hooks (Qwindow_text_change_functions); - goto restart; - } - - beg_unchanged = BEG_UNCHANGED; - end_unchanged = END_UNCHANGED; - - SET_TEXT_POS (opoint, PT, PT_BYTE); - - specbind (Qinhibit_point_motion_hooks, Qt); - buffer_unchanged_p = (w->window_end_valid && !current_buffer->clip_changed @@ -31692,7 +31678,6 @@ A polygon is a cons (poly . [x0 y0 x1 y1 ...]) where each pair in the DEFSYM (Qoverriding_terminal_local_map, "overriding-terminal-local-map"); DEFSYM (Qoverriding_local_map, "overriding-local-map"); DEFSYM (Qwindow_scroll_functions, "window-scroll-functions"); - DEFSYM (Qwindow_text_change_functions, "window-text-change-functions"); DEFSYM (Qredisplay_end_trigger_functions, "redisplay-end-trigger-functions"); DEFSYM (Qinhibit_point_motion_hooks, "inhibit-point-motion-hooks"); DEFSYM (Qeval, "eval"); @@ -32016,11 +32001,6 @@ either to point into another buffer (e.g. via `set-window-buffer') or another work. */); Vwindow_scroll_functions = Qnil; - DEFVAR_LISP ("window-text-change-functions", - Vwindow_text_change_functions, - doc: /* Functions to call in redisplay when text in the window might change. */); - Vwindow_text_change_functions = Qnil; - DEFVAR_LISP ("redisplay-end-trigger-functions", Vredisplay_end_trigger_functions, doc: /* Functions called when redisplay of a window reaches the end trigger. Each function is called with two arguments, the window and the end trigger value. ^ permalink raw reply related [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-06 7:08 ` martin rudalics @ 2017-07-06 15:21 ` Eli Zaretskii 2017-07-07 6:52 ` martin rudalics 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-07-06 15:21 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Thu, 06 Jul 2017 09:08:13 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > This hook ws introduced for linum.el, but linum.el as added to Emacs > > never used it. We should delete the hook and any references to it in > > the manuals. > > The attached patch tries to restore the state before its introduction. Thanks. Are the rearrangements necessary, or just out of aesthetic feelings? If the latter, I'd prefer not to rearrange, as that makes forensics a tad harder. Otherwise, fine with me; please push. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-07-06 15:21 ` Eli Zaretskii @ 2017-07-07 6:52 ` martin rudalics 0 siblings, 0 replies; 97+ messages in thread From: martin rudalics @ 2017-07-07 6:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > Are the rearrangements necessary, or just out of aesthetic feelings? Neither. They were part of the attempt to faithfully restore the state before that variable was introduced. > If the latter, I'd prefer not to rearrange, as that makes forensics a > tad harder. We violently agree. > Otherwise, fine with me; please push. Done. martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-28 16:48 ` Eli Zaretskii 2017-06-28 18:35 ` martin rudalics @ 2017-06-29 1:34 ` Dmitry Gutov 2017-06-29 16:20 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: Dmitry Gutov @ 2017-06-29 1:34 UTC (permalink / raw) To: Eli Zaretskii, martin rudalics; +Cc: alexanderm, 27427 On 6/28/17 7:48 PM, Eli Zaretskii wrote: > Dmitry, can you tell why the popup overlay is a single overlay with a > single multiline string, and not a series of overlays, one each for > every line shown in the popup? I assume this caused or could cause > more serious problems than the current implementation, but what > problems were those? Different tradeoffs, some different problems, and a lot of common ones (like text scaling, images, character widths, etc). How would that help with the current issue? One-line-per-overlay approach will always work worse in display-heavy buffers, for instance. Like the 'M-x report-emacs-bug' one. auto-complete (with popup.el) use this approach, however. company uses the other one. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-29 1:34 ` Dmitry Gutov @ 2017-06-29 16:20 ` Eli Zaretskii 2017-06-29 17:55 ` Dmitry Gutov 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-29 16:20 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 27427, alexanderm > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Thu, 29 Jun 2017 04:34:16 +0300 > > On 6/28/17 7:48 PM, Eli Zaretskii wrote: > > > Dmitry, can you tell why the popup overlay is a single overlay with a > > single multiline string, and not a series of overlays, one each for > > every line shown in the popup? I assume this caused or could cause > > more serious problems than the current implementation, but what > > problems were those? > > Different tradeoffs, some different problems, and a lot of common ones > (like text scaling, images, character widths, etc). But all of these are not relevant to TTY frames, right? > How would that help with the current issue? Martin is trying very hard to come up with a method to overcome the fact that Emacs cannot display "rectangular" overlay strings. Breaking the string into several one-line strings and putting their overlays at the appropriate buffer positions would solve this problem. > One-line-per-overlay approach will always work worse in display-heavy > buffers, for instance. Like the 'M-x report-emacs-bug' one. Why would it work worse in that case? ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-29 16:20 ` Eli Zaretskii @ 2017-06-29 17:55 ` Dmitry Gutov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry Gutov @ 2017-06-29 17:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427 On 6/29/17 7:20 PM, Eli Zaretskii wrote: >> Different tradeoffs, some different problems, and a lot of common ones >> (like text scaling, images, character widths, etc). > > But all of these are not relevant to TTY frames, right? The `display' issue in `M-x report-emacs-bug' should be just as relevant. And similar stuff. Character widths might be relevant as well in some terminals, but that's hardly something we could fix in Emacs. > Martin is trying very hard to come up with a method to overcome the > fact that Emacs cannot display "rectangular" overlay strings. > Breaking the string into several one-line strings and putting their > overlays at the appropriate buffer positions would solve this problem. Like I said, we have another completion package that does this (but the authors refuse to assign copyright). How will that help with the arithmetics? How is it better than the one-overlay approach for the current situation? >> One-line-per-overlay approach will always work worse in display-heavy >> buffers, for instance. Like the 'M-x report-emacs-bug' one. > > Why would it work worse in that case? Imagine that point is above the "If Emacs crashed..." display overlay. There is no physical line below it where we can put an overlay with the first popup line. I suppose we could replace (propertize "\n" 'display txt) string that is there with a fully made up overlay string, but a) it's less trivial than you probably imagined initially, b) the buffer text below it is going to jump up and down as the popup is shown and hidden. With the one-overlay approach, we ignore that `display' property (so there's empty space there when the popup is displayed), but preserve the height in rows, so the other buffer text is not jumping. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 15:59 ` martin rudalics 2017-06-25 16:24 ` Dmitry Gutov @ 2017-06-25 19:00 ` Eli Zaretskii 2017-06-26 8:21 ` martin rudalics 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2017-06-25 19:00 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Sun, 25 Jun 2017 17:59:01 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: alexanderm@web.de, 27427@debbugs.gnu.org > > I also voted for a line numbers cache like that of (or even in > combination with) the 'syntax-ppss' cache but that's a different > subject. For the record, IME caches are problematic in the display code. Various display routines are invoked from semi-random places, sometimes utterly unrelated to display per se. As a typical example, consider vertical-motion. Also, redisplay optimizations many time perform layout only for small portions of the window/frame, so you cannot easily rely on the fact that you will be called for a significant number of screen lines, something which would favor caching. Last, but definitely not least, caching gets in the way when the display engine decides it should abandon some layout attempt, back up, and continue from some previous state of the layout process. Many times, this requires to reset the cache as well, which complicates management. So my advice is always to try to code efficient algorithms that can perform reasonably fast without caching. It turned out that counting line (using the same code we always used for line-number display in the mode line) is just such a fast method. ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-25 19:00 ` Eli Zaretskii @ 2017-06-26 8:21 ` martin rudalics 2017-06-26 15:06 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: martin rudalics @ 2017-06-26 8:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alexanderm, 27427, dgutov > So my advice is always to try to code efficient algorithms that can > perform reasonably fast without caching. It turned out that counting > line (using the same code we always used for line-number display in > the mode line) is just such a fast method. Yet we have ‘line-number-display-limit’ and ‘line-number-display-limit-width’ ... martin ^ permalink raw reply [flat|nested] 97+ messages in thread
* bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup 2017-06-26 8:21 ` martin rudalics @ 2017-06-26 15:06 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2017-06-26 15:06 UTC (permalink / raw) To: martin rudalics; +Cc: alexanderm, 27427, dgutov > Date: Mon, 26 Jun 2017 10:21:23 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > So my advice is always to try to code efficient algorithms that can > > perform reasonably fast without caching. It turned out that counting > > line (using the same code we always used for line-number display in > > the mode line) is just such a fast method. > > Yet we have ‘line-number-display-limit’ and > ‘line-number-display-limit-width’ ... Whose default values could probably be enlarged considerably, given the contemporary CPUs. ^ permalink raw reply [flat|nested] 97+ messages in thread
end of thread, other threads:[~2017-07-15 17:49 UTC | newest] Thread overview: 97+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-06-19 16:50 bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup Alexander Miller 2017-06-19 17:08 ` Eli Zaretskii [not found] ` <6b307502-53db-e92d-1050-3cf0132537cb@web.de> 2017-06-19 19:23 ` Eli Zaretskii 2017-06-19 19:53 ` Alexander Miller 2017-06-19 21:03 ` Dmitry Gutov 2017-06-20 15:04 ` Eli Zaretskii 2017-06-21 2:18 ` Dmitry Gutov 2017-06-21 2:40 ` Eli Zaretskii 2017-06-21 13:04 ` Dmitry Gutov 2017-06-21 15:51 ` Alexander Miller 2017-06-21 18:15 ` Eli Zaretskii 2017-06-21 22:41 ` Dmitry Gutov 2017-06-22 14:55 ` Eli Zaretskii 2017-06-22 23:17 ` Dmitry Gutov 2017-06-23 9:10 ` Eli Zaretskii 2017-06-23 23:26 ` Dmitry Gutov 2017-06-24 7:47 ` Eli Zaretskii 2017-06-24 17:28 ` Eli Zaretskii 2017-06-24 20:43 ` Dmitry Gutov 2017-06-25 13:51 ` Dmitry Gutov 2017-06-25 14:32 ` Eli Zaretskii 2017-06-25 14:36 ` Dmitry Gutov 2017-06-25 14:13 ` Eli Zaretskii 2017-06-25 14:46 ` Dmitry Gutov 2017-06-25 15:05 ` Eli Zaretskii 2017-06-25 16:35 ` Eli Zaretskii 2017-06-25 17:57 ` Eli Zaretskii 2017-06-25 22:56 ` Dmitry Gutov 2017-06-26 8:23 ` martin rudalics 2017-06-26 15:07 ` Eli Zaretskii 2017-06-27 7:06 ` martin rudalics 2017-06-27 14:48 ` Eli Zaretskii 2017-06-26 15:22 ` Eli Zaretskii 2017-06-26 15:28 ` Dmitry Gutov 2017-06-26 15:50 ` Eli Zaretskii 2017-06-26 17:12 ` Dmitry Gutov 2017-06-26 21:30 ` Johan Bockgård 2017-06-27 16:47 ` Eli Zaretskii 2017-07-13 23:04 ` Dmitry Gutov 2017-07-14 6:11 ` Eli Zaretskii 2017-07-14 6:24 ` Dmitry Gutov 2017-07-14 7:04 ` Eli Zaretskii 2017-07-15 17:38 ` Dmitry Gutov 2017-07-15 17:49 ` Eli Zaretskii 2017-06-25 14:31 ` Dmitry Gutov 2017-06-25 14:54 ` Eli Zaretskii 2017-06-25 15:25 ` Dmitry Gutov 2017-06-25 16:12 ` martin rudalics 2017-06-25 18:21 ` Eli Zaretskii 2017-06-25 15:59 ` martin rudalics 2017-06-25 16:24 ` Dmitry Gutov 2017-06-25 17:10 ` martin rudalics 2017-06-25 18:36 ` Eli Zaretskii 2017-06-25 18:51 ` Eli Zaretskii 2017-06-26 8:21 ` martin rudalics 2017-06-26 8:18 ` martin rudalics 2017-06-25 18:24 ` Eli Zaretskii 2017-06-26 7:15 ` martin rudalics 2017-06-26 8:18 ` martin rudalics 2017-06-26 12:07 ` Dmitry Gutov 2017-06-26 15:05 ` Eli Zaretskii 2017-06-27 7:06 ` martin rudalics 2017-06-27 14:48 ` Eli Zaretskii 2017-06-27 15:27 ` martin rudalics 2017-06-27 16:27 ` Eli Zaretskii 2017-06-28 8:45 ` martin rudalics 2017-06-28 16:48 ` Eli Zaretskii 2017-06-28 18:35 ` martin rudalics 2017-06-28 18:56 ` Eli Zaretskii 2017-06-29 7:17 ` martin rudalics 2017-06-29 16:29 ` Eli Zaretskii 2017-06-30 8:27 ` martin rudalics 2017-06-30 9:33 ` Eli Zaretskii 2017-07-01 10:31 ` martin rudalics 2017-07-01 11:59 ` Eli Zaretskii 2017-07-01 13:22 ` martin rudalics 2017-07-01 13:33 ` Eli Zaretskii 2017-07-01 15:20 ` martin rudalics 2017-07-01 15:41 ` Eli Zaretskii 2017-07-02 7:54 ` martin rudalics 2017-07-02 14:10 ` Eli Zaretskii 2017-07-02 14:45 ` Dmitry Gutov 2017-07-02 15:18 ` Eli Zaretskii 2017-07-03 0:22 ` Dmitry Gutov 2017-07-03 2:29 ` Eli Zaretskii 2017-07-06 7:08 ` martin rudalics 2017-07-06 13:06 ` Dmitry Gutov 2017-07-07 6:52 ` martin rudalics 2017-07-06 7:08 ` martin rudalics 2017-07-06 15:21 ` Eli Zaretskii 2017-07-07 6:52 ` martin rudalics 2017-06-29 1:34 ` Dmitry Gutov 2017-06-29 16:20 ` Eli Zaretskii 2017-06-29 17:55 ` Dmitry Gutov 2017-06-25 19:00 ` Eli Zaretskii 2017-06-26 8:21 ` martin rudalics 2017-06-26 15:06 ` Eli Zaretskii
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.