bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wra


From: Eli Zaretskii
Subject: bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property
Date: Fri, 20 Oct 2017 10:03:08 +0300

> From: Alex <agrambot@gmail.com>
> Cc: rudalics@gmx.at,  28855@debbugs.gnu.org,  monnier@iro.umontreal.ca,  
> johnw@gnu.org,  dgutov@yandex.ru
> Date: Wed, 18 Oct 2017 23:54:54 -0600
> 
> It doesn't seem that line/wrap-prefix are very commonly used (though
> perhaps I'm just not using the relevant packages), so coupled with
> :align-to's rarity it doesn't seem surprising that no one has asked for
> it until now.

I'd prefer not to put too much effort into developing new aspects of
never-used combinations of features.  IME, we already have too many
such combinations, and that gets in the way of new developments due to
the need to keep them compatible to existing features, and our general
inability to decide that some such feature can be safely removed.

> Just accounting for line-numbers is better than the current behaviour,
> but if you do decide to do that, then it would be nice to have something
> along the lines of:
> 
>   :align-to (+ prefix prefix N)
> 
> That would mean "offset from the *-prefix area", which would let you
> align to non-prefix text in the buffer.

But the prefixes are different: there could be a different prefix for
each line, defined via the property set on that line.  So using that
in conjunction with :align-to makes much less sense, since most uses
of :align-to are for aligning text on more than one line.

> Still, if alignment treats line-numbers specially, then I think it makes
> sense to provide it as a full-fledged element for pixel specifications.

It has never been a principle of Emacs development to develop each
feature to its logical endpoint.  We only develop what's practically
needed and makes most sense, and do that pragmatically.

Once again, too many of these features imply we have some
unimplemented layout requirements, and if so, we will be better off
implementing that layout entirely in the display engine, instead of
giving Lisp programs more hooks into the display code.  Doing layout
in Lisp should generally be avoided.





reply via email to

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