GNU bug report logs - #27427
26.0.50; Native line numbers lead to display error in company-mode popup

Previous Next

Full log

Message #68 received at 27427 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alexanderm <at> web.de, 27427 <at> debbugs.gnu.org
Subject: Re: 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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.