[Top][All Lists]

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

bug#27427: 26.0.50; Native line numbers lead to display error in company

From: Dmitry Gutov
Subject: bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup
Date: Sun, 25 Jun 2017 17:31:59 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0

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?


If you have a link to a previous discussion, that would be great as well.

Here's one (I think there were more):


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).

reply via email to

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