From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <83y3o6cndf.fsf@gnu.org> References: <1508125091.3713406.1139815176.12F59A69@webmail.messagingengine.com> <83po9nf58h.fsf@gnu.org> <3fdce54f-f704-66df-75db-843dbd98ec50@yandex.ru> <83h8uwe730.fsf@gnu.org> <59E79312.5050201@gmx.at> <83d15ke3hm.fsf@gnu.org> <87a80ot3ec.fsf@gmail.com> <838tg7es1q.fsf@gnu.org> <87tvyvk7gx.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1508483068 32250 195.159.176.226 (20 Oct 2017 07:04:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 20 Oct 2017 07:04:28 +0000 (UTC) Cc: 28855@debbugs.gnu.org, monnier@iro.umontreal.ca, johnw@gnu.org, dgutov@yandex.ru To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 20 09:04:22 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e5RLn-0005tG-Kw for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Oct 2017 09:04:11 +0200 Original-Received: from localhost ([::1]:52438 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5RLr-0004LX-WB for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Oct 2017 03:04:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5RLl-0004LQ-B5 for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2017 03:04:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5RLf-0005kR-LC for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2017 03:04:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42336) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e5RLf-0005k0-HS for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2017 03:04:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e5RLf-0000Qr-1i for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2017 03:04:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Oct 2017 07:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28855 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28855-submit@debbugs.gnu.org id=B28855.15084830301639 (code B ref 28855); Fri, 20 Oct 2017 07:04:01 +0000 Original-Received: (at 28855) by debbugs.gnu.org; 20 Oct 2017 07:03:50 +0000 Original-Received: from localhost ([127.0.0.1]:51017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e5RLO-0000QH-HS for submit@debbugs.gnu.org; Fri, 20 Oct 2017 03:03:50 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38557) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e5RLM-0000Q3-Pl for 28855@debbugs.gnu.org; Fri, 20 Oct 2017 03:03:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5RLD-0005a6-Kk for 28855@debbugs.gnu.org; Fri, 20 Oct 2017 03:03:39 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5RKw-0005R4-FU; Fri, 20 Oct 2017 03:03:18 -0400 Original-Received: from [176.228.60.248] (port=1818 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e5RKv-0008DZ-QJ; Fri, 20 Oct 2017 03:03:18 -0400 In-reply-to: <87tvyvk7gx.fsf@gmail.com> (message from Alex on Wed, 18 Oct 2017 23:54:54 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138742 Archived-At: > From: Alex > 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.