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#29279: Sharing the margins Date: Wed, 15 Nov 2017 20:00:10 +0200 Message-ID: <83a7znjuc5.fsf@gnu.org> References: <0a54e927-cab1-1f1d-4996-85bb36949a33@yandex.ru> <83375imbaa.fsf@gnu.org> <83o9o6kp61.fsf@gnu.org> <83h8tykm99.fsf@gnu.org> <83375glvx4.fsf@gnu.org> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@yandex.ru> <83efp0jjhi.fsf@gnu.org> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1510768876 8349 195.159.176.226 (15 Nov 2017 18:01:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Nov 2017 18:01:16 +0000 (UTC) Cc: 29279@debbugs.gnu.org, joostkremers@fastmail.fm To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 15 19:01:12 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 1eF1zl-0001dV-PG for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 Nov 2017 19:01:06 +0100 Original-Received: from localhost ([::1]:37247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eF1zt-0000WJ-4y for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 Nov 2017 13:01:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eF1zm-0000VR-VA for bug-gnu-emacs@gnu.org; Wed, 15 Nov 2017 13:01:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eF1zi-00052F-Pt for bug-gnu-emacs@gnu.org; Wed, 15 Nov 2017 13:01:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33415) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eF1zi-00051r-Lj for bug-gnu-emacs@gnu.org; Wed, 15 Nov 2017 13:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eF1zi-0004pN-AX for bug-gnu-emacs@gnu.org; Wed, 15 Nov 2017 13:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Nov 2017 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29279 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29279-submit@debbugs.gnu.org id=B29279.151076882718509 (code B ref 29279); Wed, 15 Nov 2017 18:01:02 +0000 Original-Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 18:00:27 +0000 Original-Received: from localhost ([127.0.0.1]:42096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eF1z8-0004oT-QK for submit@debbugs.gnu.org; Wed, 15 Nov 2017 13:00:27 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eF1z7-0004oH-CL for 29279@debbugs.gnu.org; Wed, 15 Nov 2017 13:00:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eF1yw-00048j-5C for 29279@debbugs.gnu.org; Wed, 15 Nov 2017 13:00:20 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33566) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eF1yp-00042G-LN; Wed, 15 Nov 2017 13:00:07 -0500 Original-Received: from [176.228.60.248] (port=4841 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eF1yn-0002NI-Rr; Wed, 15 Nov 2017 13:00:07 -0500 In-reply-to: <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@yandex.ru> (message from Dmitry Gutov on Wed, 15 Nov 2017 16:23:01 +0200) 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:139929 Archived-At: > Cc: 29279@debbugs.gnu.org, joostkremers@fastmail.fm > From: Dmitry Gutov > Date: Wed, 15 Nov 2017 16:23:01 +0200 > > On 11/15/17 5:42 AM, Eli Zaretskii wrote: > > >> It might be just a matter of interpretation: even if all the padding is > >> on the right, the "rightmost" column will remain such, among all the > >> visible columns. > > > > Yes, but "being the rightmost" might mean "being right next to the > > text", for whatever purposes. > > So far, I doubt it's going to come up as a real, hard requirement. But > we'll probably see. I could think of something similar to overlay-arrow, only using the margin. Such a feature will want the arrow to be as close to buffer text as possible. > > A stretch of white space between the > > text and the margin display might not be what the package wants. > > OK, can we think of a case where a package might want its margin content > to be _as far away_ from the text as possible? And become troubled if > some padding stands between it and the window edge? > > If not, let's put all padding on the outside and be done with that concern. This is doable, but the implementation will be more complex. Remember: the display engine lays out stuff left to right. So padding what's left after we are done with all of the "columns" is easy; padding _before_ requires that you either compute all the widths in advance, or that you come back after laying out the columns and insert the stretch before it, moving all the glyphs to the right. > >> But the effects are almost entirely the same, aren't they? Both the > >> change of margin width and the change of line numbers column width force > >> the reflowing of buffer contents display. > > > > Again, as long as the text-area dimensions didn't change, it could be > > argued that the hook shouldn't run. > > That's some creative nomenclature lawyering. :-) It isn't. It's just how the implementation works. > OK then, what's the practical problem with saying that margins are also > part of "text-area dimensions"? It's hard to implement. window-configuration-change-hook currently runs from functions that change window dimensions or the buffer displayed in it; those never run inside redisplay. What you (and some others) propose will have to run in the middle of redisplaying a window, and who knows what running arbitrary Lisp at that point will or could do? In addition, it will require us to record somewhere (probably, in the window object) the last used width for number display, so we could compare that with the new one. This is not as simple as it sounds, because most redisplay cycles avoid redrawing the entire window, so determining just where in the code to perform this comparison is a non-trivial decision. So I'd like to avoid this if possible.