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: Sun, 19 Nov 2017 17:34:28 +0200 Message-ID: <834lpqffjv.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> <83a7znjuc5.fsf@gnu.org> <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@yandex.ru> <83shdei5o8.fsf@gnu.org> <463d412b-6a5d-eda5-d882-b4044d4f417d@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1511105714 22178 195.159.176.226 (19 Nov 2017 15:35:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Nov 2017 15:35:14 +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 Sun Nov 19 16:35:10 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 1eGRcf-0005LM-L5 for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Nov 2017 16:35:05 +0100 Original-Received: from localhost ([::1]:53422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGRcn-0006Fu-3d for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Nov 2017 10:35:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGRcf-0006Fm-CD for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2017 10:35:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGRcc-0005zg-5E for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2017 10:35:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39001) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eGRcc-0005zU-1b for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2017 10:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eGRcb-0000zU-Ol for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2017 10:35:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2017 15:35:01 +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.15111056933791 (code B ref 29279); Sun, 19 Nov 2017 15:35:01 +0000 Original-Received: (at 29279) by debbugs.gnu.org; 19 Nov 2017 15:34:53 +0000 Original-Received: from localhost ([127.0.0.1]:47682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGRcT-0000z4-18 for submit@debbugs.gnu.org; Sun, 19 Nov 2017 10:34:53 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:38121) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGRcQ-0000yr-E2 for 29279@debbugs.gnu.org; Sun, 19 Nov 2017 10:34:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGRcK-0005qZ-68 for 29279@debbugs.gnu.org; Sun, 19 Nov 2017 10:34:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGRcE-0005n3-Li; Sun, 19 Nov 2017 10:34:38 -0500 Original-Received: from [176.228.60.248] (port=1916 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eGRcE-0004P2-3P; Sun, 19 Nov 2017 10:34:38 -0500 In-reply-to: <463d412b-6a5d-eda5-d882-b4044d4f417d@yandex.ru> (message from Dmitry Gutov on Sun, 19 Nov 2017 01:55:23 +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:140093 Archived-At: > Cc: 29279@debbugs.gnu.org, joostkremers@fastmail.fm > From: Dmitry Gutov > Date: Sun, 19 Nov 2017 01:55:23 +0200 > > > The way this feature is designed and implemented, it doesn't lend > > itself easily to hooks, primarily because it works in the inner-most > > level of redisplay. > > Then maybe using the margins for it will be a necessary price, with the > corresponding performance hit (though hopefully not), just to enable the > extensibility our users are accustomed to. Not from my POV. The extensibility is already there, you can look at the bundled modes which were adapted to this feature. > >> Can't you save the necessary data to a variable, finish redisplay, > >> and then run the hook (if the data says so)? > > > > That would be pointless, because there are already hooks which work > > before redisplay or after it finishes. All such a hook needs to do is > > compare the value returned by line-number-display-width with the last > > value it saw. That's what I did in tabulated-list-mode, which has > > some unique requirements in this area. Avoiding the comparison > > doesn't justify a new hook. > > Hmm, I'm not sure it would be as pointless as you say: normally, it's > most important to be notified of some change _eventually_, and not > necessarily during some process such as redisplay. It would at least > save the user the problem of puzzling out how to do this, and what to > compare. What is the difference between being notified when the width changed, and figuring out when it was changed by comparing two numbers? > On the other hand, it could be the argument for margin changes not to > run the usual hooks, because any sane called could compare margin widths > before and after. It's the other way around: we are talking about hooks that would like to change the margins. > > And anyway, what do you envision that a hook function will want to do? > > Most probably, it will want to change the window dimensions, or affect > > what's on display in some other way, which means an immediate second > > redisplay cycle. > > Affect what's on display, yes, most likely. > > > So we gain nothing by making the display engine call > > the hook. > > Yeah. I was suggesting to call the hook later, though. Same difference. > >> It's somewhat hypothetical, but I'd like to refer to (*) above. That is, > >> somebody will probably ask for that anyway, sooner or later. > > > > Somebody already did, and I declined for now, because I think the same > > effect can be achieved via existing hooks. > > Do you have margin-using examples that likewise couldn't be "achieved > via existing hooks" if margin changes didn't call > window-configuration-change-hook? I didn't try to look. Anyway, could we please stop mixing these two issues? This discussion is about margin sharing, not about a (missing) hook for changes in line-number width.