GNU logs - #29279, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 12 Nov 2017 23:53:02 +0000
Resent-Message-ID: <handler.29279.B.151053073215373 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 29279 <at> debbugs.gnu.org
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
Date: Mon, 13 Nov 2017 01:51:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

This is a rough proposal on how separate bodies of code (minor modes, 
etc) can use the same margin without conflict.

Previous discussions:

http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01171.html
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27427#53

Primary goals:

- Allow multiple kinds of margin content to coexist (examples: 
http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01505.html).
- Continue to use the text properties to set the contents of the margins 
(as opposed to having a line number based API, which seems to come with 
its own difficulties).

Outline:

We introduce two new variables, named like left-margin-columns-alist.

Each element is a cons which specifies some properties of the element, 
for instance:

- Priority (so the columns are in the same order on each line)
- Minimum width (if we want that, as opposed to just adding strings with 
that length the contents of this margin column)
- Minimum "total" width, which would allow to use this column as padding 
so that the combined width of the margin reaches a given number 
(hopefully solving the writeroom-mode problem).
- Padding (whether to pad this column with a space on one side if there 
is a next column)
- Text alignment within the column (left or right)

The keys in left-margin-columns-alist will be used as alternatives to 
`left-margin' in margin display specs.

The display engine would scan the contents of the current window, 
process said specs, calculate which lines fit the window and which do 
not, set the total margin width appropriately, and display all columns 
in it. Some reflowing might be required.

If the latter is considered too difficult, we can add "width" as a 
necessary parameter to the column properties. I think that would rule 
out the possibility of efficiently using the margins for the line 
numbers feature, though, which seems unfortunate. But the other uses of 
the margin that I'm aware of are not as dynamic.

Similar feature can be added for the fringes, too (for them, dynamic 
sizing isn't needed at all, probably).

Comments?

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: bug#29279: Acknowledgement (Sharing the margins)
Message-ID: <handler.29279.B.151053073215373.ack <at> debbugs.gnu.org>
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
X-Gnu-PR-Message: ack 29279
X-Gnu-PR-Package: emacs
Reply-To: 29279 <at> debbugs.gnu.org
Date: Sun, 12 Nov 2017 23:53:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 29279 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
29279: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D29279
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 15:44:01 +0000
Resent-Message-ID: <handler.29279.B29279.15105877871217 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Date: Mon, 13 Nov 2017 17:43:01 +0200
Message-Id: <834lpymbga.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN> (message from
 Dmitry Gutov on Mon, 13 Nov 2017 01:51:53 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Mon, 13 Nov 2017 01:51:53 +0200
> 
> This is a rough proposal on how separate bodies of code (minor modes, etc) can use the same margin without conflict.

Thanks for reviving the issue.

> Previous discussions:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01171.html
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27427#53

The second discussion doesn't seem to be relevant, although it touches
this tangentially.  It has nothing useful to add to this discussion,
AFAICT.

> Primary goals:
> 
> - Allow multiple kinds of margin content to coexist (examples: http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01505.html).

Yes, that's the goal.

> - Continue to use the text properties to set the contents of the margins (as opposed to having a line number based API, which seems to come with its own difficulties).

Not sure I understand this.  AFAIK no one proposed to get rid of the
mechanism of specifying margin display, be it via text properties or
overlays.  The line number display of Emacs 26 avoids using the
margins, but that wasn't proposed as some more general API for
anything else.  So I think this is a non-issue, and will just leads us
astray.

> Outline:
> 
> We introduce two new variables, named like left-margin-columns-alist.
> 
> Each element is a cons which specifies some properties of the element, for instance:

I think we need to come up with a specific list of properties, because
discussing an example will always be too vague and uncommitted.  So is
this the actual list you propose, or are there other properties you
envision?  If the latter, please add them to the list.

> - Priority (so the columns are in the same order on each line)

You mean "order", right?  That is, which part will be rendered first,
which after it, etc., right?  If not, what is the practical meaning of
"priority" here?

> - Minimum width (if we want that, as opposed to just adding strings with that length the contents of this margin column)
> - Minimum "total" width, which would allow to use this column as padding so that the combined width of the margin reaches a given number (hopefully solving the writeroom-mode problem).

I don't understand the difference between these two.  Can you
elaborate?

And what about the maximum width?  I think this is much more important
than the minimum.

> - Padding (whether to pad this column with a space on one side if there is a next column)

Doesn't the minimum width already cover this?  If the actual width is
less than the advertised minimum, text should be padded, otherwise it
shouldn't.  Right?

> - Text alignment within the column (left or right)

Why does this need to be a separate property?  We don't have anything
like that for any other kind of text.

> The keys in left-margin-columns-alist will be used as alternatives to `left-margin' in margin display specs.

I think we need to agree on the model of the display in the margins.
The fact that you use "columns" in your proposal hints that each
"user" of the margin (a Lisp program which displays there) will have a
separate "column" in the margin, and that column will be of the same
pixel width for each screen line.  If this is the model, then it makes
little sense to have different display specs regarding the "column"
width for each buffer position where display in the margin is
requested, because the resulting column width will be the same for all
such displays.  If we specify these in each display spec, we are in
effect wasting Lisp storage, and potentially also working against the
fundamental design of the display engine (more about that below).

> The display engine would scan the contents of the current window, process said specs, calculate which lines fit the window and which do not, set the total margin width appropriately, and display all columns in it. Some reflowing might be required.

This will not work with the current design of the display engine, at
least not without significant pains and at least twofold performance
degradation.  To realize why, you need to remember that when the
display engine is redisplaying a window, it initially has no idea
where the window will end, it normally (but not always) knows only
where it will begin.  This is because the stuff to be displayed in the
window could have changed significantly since the last redisplay
cycle, so any "memory" of where the window ended back then could
easily be invalid (which is why the display engine keeps almost no
memory about the results of the last redisplay).

The actual place where the window display ends is the consequence of
the display engine trying to lay out the window starting at
window-start, and going on until the window bottom is reached, at
which point it checks that point is visible in the window, and if not,
chooses a different window-start to bring point into the view, and
retries.

(The above description is a simplification: it omits various redisplay
optimizations which refrain from displaying the entire window in the
frequent use cases.  But for the purposes of this discussion, let's
forget about those optimizations, because their semantics is, and must
be, identical to redisplaying the whole window anew each time.)

For this reason, "scanning the contents of the current window" is not
something the display engine can do at the start of a window
redisplay.  It can only do so after one full cycle of window layout.
In addition, changing the dimensions of the margins requires to start
the window display anew, after reallocating the glyph matrices.

So what you suggest can only be implemented by displaying each window
twice.  On top of that, it will disable important redisplay
optimizations, which refrain from examining all of the screen lines
and the corresponding buffer text -- since you require to scan all of
the display specs in the window to dynamically compute the margin
dimensions.

The way the current display engine is designed, it makes the layout
decisions either at the start of a window's redisplay, or as it
traverses buffer text one character at a time.  The decisions related
to the dimensions of the canvas are best made at the beginning,
otherwise they will cause the redisplay to be abandoned and restarted
anew, which slows it down.  We have a few cases where we do that, but
they should be rare to provide good user experience.  (These cases
could also complicate the move_it_* functions, which simulate display.
As of now, they don't handle such cases, but won't be able to ignore
the consequences of your proposal to calculate margins dynamically as
part of redisplay.)

Therefore, features that require dynamic recalculation of the window
dimensions as part of redisplay should IMO be avoided at all costs.
We should try to find a way of making these calculations in Lisp, as
part of the program(s) that require display in the margins, so that by
the time redisplay kicks in, the calculation of the margin widths,
including the column width for each "user" of the margin, was already
done and stored in some form that the display engine could use when it
initializes redisplay of a window.

> If the latter is considered too difficult

I think "unworkable" is a more proper word, unfortunately, because I
don't see anyone who'd step forward to perform a major redesign of the
display engine required for your proposal.  (And if we are redesigning
the display engine, I have a few more important requirements for it ;-)

I will post an alternative proposal in a separate email.

> we can add "width" as a necessary parameter to the column properties. I think that would rule out the possibility of efficiently using the margins for the line numbers feature, though, which seems unfortunate. But the other uses of the margin that I'm aware of are not as dynamic.

Sorry, I think you lost me here.  What is that "width" parameter,
which "column properties" are being alluded to, and why would it
disallow dynamic resizing of the margins?  The only requirement for a
feature that will allow relatively simple and efficient implementation
is that the necessary total width of each window margin is known, or
can be calculated by accessing some buffer- or window-local variable,
at the beginning of a redisplay cycle.  Is that hard to accomplish?

> Similar feature can be added for the fringes, too (for them, dynamic sizing isn't needed at all, probably).

I think fringes are a separate issue.  AFAIK, we current cannot
display more than one bitmap on the fringe at any given screen line.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 15:47:02 +0000
Resent-Message-ID: <handler.29279.B29279.15105880031577 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Date: Mon, 13 Nov 2017 17:46:37 +0200
Message-Id: <83375imbaa.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN> (message from
 Dmitry Gutov on Mon, 13 Nov 2017 01:51:53 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

I tend to like better the proposal originally made by Joost Kremers in
http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01540.html.
Here it is with slight variations of my own:

We add 3 new functions:

 (defun window-margin-add (window side symbol cols &optional ordinal)
   "Request allocation of COLS columns of WINDOW's marginal area.
 WINDOW must be a live window and defaults to the selected one.
 SIDE is the window side, either `left' or `right', in whose margin
   the allocation is requested.
 SYMBOL identifies the request, in case the allocation needs to be
   changed or deleted.
 ORDINAL is the optional ordinal number of the requested area, counted
   from left to right.  Negative ordinal numbers count from right to
   left.  Zero means the value of COLS is the maximum width of the
   marginal area, and no separate allocation is requested.

 Value is the actual positive ordinal number of the allocated area."

 (defun window-margin-remove (window side symbol)
   "Remove a previously allocated part of WINDOW's marginal area.
 WINDOW must be a live window and defaults to the selected one.
 SIDE is the window side, either `left' or `right', in whose margin
   the removal is requested.
 SYMBOL identifies the request to be deleted."

 (defun window-margin-modify (window side symbol cols)
   "Modify a previously allocated part of WINDOW's marginal area.
 WINDOW must be a live window and defaults to the selected one.
 SIDE is the window side, either `left' or `right', in whose margin
   the modification is requested.
 SYMBOL identifies the request to be modified."

The details of the allocated portions of the marginal area are
maintained in window parameters `left-margin-params' and
`right-margin-params', which are modified by those 2 functions.  The
display engine uses these parameters to calculate the number of the
portions and the width of each one of them, and pre-allocates them in
the window's glyph matrices whenever a redisplay follows a change in
margin allocation.  The display spec for display in the margins will
include the symbol of the allocated portion pertaining to the display
spec.  Like this:

  '(display ((margin left-margin 'toto) STRING))

If the stuff (text, image, etc.) to be displayed in a specified
portion of the marginal area is too wide and doesn't fit the width of
the portion, it will be truncated; if it is narrower, it will be
padded.

This keeps the display engine design intact, and I think will allow
relatively straightforward implementation (although some non-trivial
changes in management of the glyph matrices will be necessary).  It
can also be implemented in a way that keeps backward compatibility
with the current APIs.

WDYT?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 17:25:01 +0000
Resent-Message-ID: <handler.29279.B29279.151059387610456 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151059387610456
          (code B ref 29279); Mon, 13 Nov 2017 17:25:01 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 17:24:36 +0000
Received: from localhost ([127.0.0.1]:38775 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEITM-0002iZ-5D
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 12:24:36 -0500
Received: from mail-wm0-f53.google.com ([74.125.82.53]:52418)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEITH-0002iH-QX
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 12:24:34 -0500
Received: by mail-wm0-f53.google.com with SMTP id t139so16858366wmt.1
 for <29279 <at> debbugs.gnu.org>; Mon, 13 Nov 2017 09:24:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=i1j7MhUd0UPo6Jj2CXMF8A9zGXB97O2DkN4Iu5jSRA4=;
 b=UbNFu9ZjJvW5YkaZ9JSRTPneYb/jPAM+ppuxixup6jYsSHD3ML0nzMS/HBFU36S+VQ
 PuFTGVUrS0dORmFDURVJi1KncOhriTj5ut+1DPTyZLb6Cvcp8iqWL/wy6rek0D83iIdH
 pHkbP3v3Z+jGcvCAo0oJnWkQroFu0dsK8RQYGqA7OdJhlZ/AYxX2EqGZrt9V19m6L9sv
 O6ur508kuu1K8eycYPR8qKu42buFgmJWpfAa9/dIemiSVug3AgfPzIDFW7scPQGJ2Qdo
 DqA3qk0DNvhXCfu7JvHUcJWqNbQGq7uKEuJWIp8c8d+fFaVwBBmeJcvWSWC7sTjj2pXe
 hfhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=i1j7MhUd0UPo6Jj2CXMF8A9zGXB97O2DkN4Iu5jSRA4=;
 b=cxz4rK7wV++3EfbeprveRIqP5/JliO1AhgpM3vHlJM4k8Frv9bnnXZq9O2txV/rgCU
 /KZSdtrlQP5VrFcdBjARNqlLc3lVAhHHMv0uxzP9VEe4e6xjROa4r3RcwTKgLY7JpR49
 ByflMAaMVEPfpHqsb3ag0x2dX5cHzTAN7UhBBmYYMOathEuLsG9OeJ7XDqoGckFf+fjo
 RRPJL0qQNa2m/OiNAoXLa+BEvu4Ht2gUkOmY+jHU7lC8vg5fivdxZ2/BzitNcxjrc6Wv
 sA993dEQzVAfOVP0bWfDwF5kSfLwiBlvRLKc6I/Mj743QpwATc66EO1OC9S/hk8MTWhv
 qvUw==
X-Gm-Message-State: AJaThX7Z6IE8bx/1BFVhQHP/feMhwtpKm7SY1kHShyz0Uo6vyjIOpqvP
 c5sInl5k1m/r6cNxhGdgFriBVdP6
X-Google-Smtp-Source: AGs4zMZCiWYZq1UzgEH554mtcXdT0qxTV9aFvsxEtu5m0cyyyV/tdqwPHa+ShI7QU7b6TRR3NJ/2sA==
X-Received: by 10.80.230.137 with SMTP id z9mr14332342edm.106.1510593865407;
 Mon, 13 Nov 2017 09:24:25 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id a52sm3547176eda.92.2017.11.13.09.24.22
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 13 Nov 2017 09:24:24 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <834lpymbga.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <b37bad4f-6994-7d0e-4af4-2c73576d24fa@HIDDEN>
Date: Mon, 13 Nov 2017 19:24:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <834lpymbga.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/13/17 5:43 PM, Eli Zaretskii wrote:

> The second discussion doesn't seem to be relevant, although it touches
> this tangentially.  It has nothing useful to add to this discussion,
> AFAICT.

Maybe not. Except as a use case. The first one is also not hugely 
relevant, because it's mostly about workroom-mode, and that one is a 
rare kind of margin usage conflict.

>> - Continue to use the text properties to set the contents of the margins (as opposed to having a line number based API, which seems to come with its own difficulties).
> 
> Not sure I understand this.  AFAIK no one proposed to get rid of the
> mechanism of specifying margin display, be it via text properties or
> overlays.

I meant that the alternative would be a new line-based programmatic API 
with functions like (add-margin vsual-line-number, width, contents). 
Which I've briefly considered and discarded, for now.

 > The line number display of Emacs 26 avoids using the
 > margins, but that wasn't proposed as some more general API for
 > anything else.  So I think this is a non-issue, and will just leads us
 > astray.

No reference to "native line numbers" intended.

>> Each element is a cons which specifies some properties of the element, for instance:
> 
> I think we need to come up with a specific list of properties, because
> discussing an example will always be too vague and uncommitted.  So is
> this the actual list you propose, or are there other properties you
> envision?  If the latter, please add them to the list.

I think that was it, but additions welcome. These ones should be 
sufficient for the uses I'm thinking of now.

>> - Priority (so the columns are in the same order on each line)
> 
> You mean "order", right?  That is, which part will be rendered first,
> which after it, etc., right?  If not, what is the practical meaning of
> "priority" here?

Order priority, yes. It's just when I think of an "order" argument, the 
value is usually something like "user_name ASC", and not a number.

>> - Minimum width (if we want that, as opposed to just adding strings with that length the contents of this margin column)
>> - Minimum "total" width, which would allow to use this column as padding so that the combined width of the margin reaches a given number (hopefully solving the writeroom-mode problem).
> 
> I don't understand the difference between these two.  Can you
> elaborate?

The first one sizes a given column (all the margins contents in this 
column get padded to at least this width).

The second one helps to size the whole margin, using this column. A way 
to set the minimum total margin width, IOW.

> And what about the maximum width?  I think this is much more important
> than the minimum.

I've decided to leave it out, because choosing the places to "cut" is 
not trivial in advance, until we know of specific situations.

>> - Padding (whether to pad this column with a space on one side if there is a next column)
> 
> Doesn't the minimum width already cover this?  If the actual width is
> less than the advertised minimum, text should be padded, otherwise it
> shouldn't.  Right?

Yes, and padding should be omitted if there is padding on every line of 
the given column.

But if there is a line which didn't need to be padded, it will look 
"smushed" together with the next column. For some uses, it might be 
okay, for others, it will be not as readable.

>> - Text alignment within the column (left or right)
> 
> Why does this need to be a separate property?  We don't have anything
> like that for any other kind of text.

IDK, why not? Will we always align to the right? I don't really mind, 
but if we anticipate the users to want different alignments, the 
property needs to be here. Otherwise, the callers will have to take care 
of "minimum width" themselves. And that basically requires them to 
refresh the margin display specs after every scrolling (but before 
redisplay, apparently).

>> The keys in left-margin-columns-alist will be used as alternatives to `left-margin' in margin display specs.
> 
> I think we need to agree on the model of the display in the margins.
> The fact that you use "columns" in your proposal hints that each
> "user" of the margin (a Lisp program which displays there) will have a
> separate "column" in the margin, and that column will be of the same
> pixel width for each screen line.

Yes.

> If this is the model, then it makes
> little sense to have different display specs regarding the "column"
> width for each buffer position where display in the margin is
> requested, because the resulting column width will be the same for all
> such displays.

The width of the string inside the margin display specs can very, can't it?

> If we specify these in each display spec, we are in
> effect wasting Lisp storage, and potentially also working against the
> fundamental design of the display engine (more about that below).

Sorry, specify what? The margin display spec will continue to be

   ((margin column-name) spec)

where SPEC is a text string, most of the time.

>> The display engine would scan the contents of the current window, process said specs, calculate which lines fit the window and which do not, set the total margin width appropriately, and display all columns in it. Some reflowing might be required.
> 
> This will not work with the current design of the display engine, at
> least not without significant pains and at least twofold performance
> degradation.  To realize why, you need to remember that when the
> display engine is redisplaying a window, it initially has no idea
> where the window will end, it normally (but not always) knows only
> where it will begin.  This is because the stuff to be displayed in the
> window could have changed significantly since the last redisplay
> cycle, so any "memory" of where the window ended back then could
> easily be invalid (which is why the display engine keeps almost no
> memory about the results of the last redisplay).

I think I'm getting the rough idea.

> The actual place where the window display ends is the consequence of
> the display engine trying to lay out the window starting at
> window-start, and going on until the window bottom is reached, at
> which point it checks that point is visible in the window, and if not,
> chooses a different window-start to bring point into the view, and
> retries.

Yes, and choosing a different margin width will obviously affect that, 
as we as the set of margin specs we encounter in the visible part of the 
buffer. Which might make a naive implementation restart the process 
multiple times in certain cases, and maybe even infloop.

> (The above description is a simplification: it omits various redisplay
> optimizations which refrain from displaying the entire window in the
> frequent use cases.  But for the purposes of this discussion, let's
> forget about those optimizations, because their semantics is, and must
> be, identical to redisplaying the whole window anew each time.)
> 
> For this reason, "scanning the contents of the current window" is not
> something the display engine can do at the start of a window
> redisplay.  It can only do so after one full cycle of window layout.
> In addition, changing the dimensions of the margins requires to start
> the window display anew, after reallocating the glyph matrices.
> 
> So what you suggest can only be implemented by displaying each window
> twice.  On top of that, it will disable important redisplay
> optimizations, which refrain from examining all of the screen lines
> and the corresponding buffer text -- since you require to scan all of
> the display specs in the window to dynamically compute the margin
> dimensions.

I was hoping that we might consider some parts of redisplay to be "fast 
enough" by now (posn-at-point is fast enough for ~500 FPS on my machine, 
for instance), but indeed it should require some smart programming.

> The way the current display engine is designed, it makes the layout
> decisions either at the start of a window's redisplay, or as it
> traverses buffer text one character at a time.  The decisions related
> to the dimensions of the canvas are best made at the beginning,
> otherwise they will cause the redisplay to be abandoned and restarted
> anew, which slows it down.  We have a few cases where we do that, but
> they should be rare to provide good user experience.  (These cases
> could also complicate the move_it_* functions, which simulate display.
> As of now, they don't handle such cases, but won't be able to ignore
> the consequences of your proposal to calculate margins dynamically as
> part of redisplay.)
>
> Therefore, features that require dynamic recalculation of the window
> dimensions as part of redisplay should IMO be avoided at all costs.
> We should try to find a way of making these calculations in Lisp, as
> part of the program(s) that require display in the margins, so that by
> the time redisplay kicks in, the calculation of the margin widths,
> including the column width for each "user" of the margin, was already
> done and stored in some form that the display engine could use when it
> initializes redisplay of a window.

What your description tells me, foremost, is that it should be 
impossible to "perfectly" make these decisions in Lisp, too.

Like, what can linum-mode do? After scrolling, it would look at the 
window-start, its height, and calculate the _approximate_ physical line 
at the end of the window. It can't get the precise number because the 
layout still hasn't happened, right? Furthermore, after it increases the 
width of its margin column (suppose we were scrolling up so line numbers 
increased), it can create a different layout where the last line is not 
visible anymore. And if its number was 100, that makes the specified 
margin width inaccurate by 1. Luckily, line numbers' width changes 
slowly, so this won't be apparent often.

Is this the idea?

>> If the latter is considered too difficult
> 
> I think "unworkable" is a more proper word, unfortunately, because I
> don't see anyone who'd step forward to perform a major redesign of the
> display engine required for your proposal.  (And if we are redesigning
> the display engine, I have a few more important requirements for it ;-)

OK :)

> I will post an alternative proposal in a separate email.
> 
>> we can add "width" as a necessary parameter to the column properties. I think that would rule out the possibility of efficiently using the margins for the line numbers feature, though, which seems unfortunate. But the other uses of the margin that I'm aware of are not as dynamic.
> 
> Sorry, I think you lost me here.  What is that "width" parameter,
> which "column properties" are being alluded to,

The properties inside left-margin-columns-alist.

So we'll have a WIDTH there (global for each column), instead of 
MINIMUM-WIDTH, and PADDING and TEXT-ALIGNMENT might become unnecessary.

> and why would it
> disallow dynamic resizing of the margins?

I guess more accurately, it would disallow dynamic *sizing* of the 
margins by the display engine.

Column widths will be accessible for manipulation from e.g. 
pre-redisplay-functions, but like described above, it doesn't seem like 
choosing margin width precisely is feasible in Lisp, even in the use 
case of showing line numbers.

> The only requirement for a
> feature that will allow relatively simple and efficient implementation
> is that the necessary total width of each window margin is known, or
> can be calculated by accessing some buffer- or window-local variable,
> at the beginning of a redisplay cycle.  Is that hard to accomplish?

With a column-global WIDTH property, I don't think it's hard.

>> Similar feature can be added for the fringes, too (for them, dynamic sizing isn't needed at all, probably).
> 
> I think fringes are a separate issue.  AFAIK, we current cannot
> display more than one bitmap on the fringe at any given screen line.

Technical limitations of some GUI toolkits, no doubt. Hopefully, more 
easily overcome than display engine complexity.

Fringes have other problems anyway, like inability to use more than 2 
colors, vector graphics, etc.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 17:55:01 +0000
Resent-Message-ID: <handler.29279.B29279.151059569613244 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151059569613244
          (code B ref 29279); Mon, 13 Nov 2017 17:55:01 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 17:54:56 +0000
Received: from localhost ([127.0.0.1]:38791 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEIwh-0003RX-WF
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 12:54:56 -0500
Received: from mail-wm0-f45.google.com ([74.125.82.45]:39988)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEIwg-0003RJ-Gb
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 12:54:54 -0500
Received: by mail-wm0-f45.google.com with SMTP id b189so9754326wmd.5
 for <29279 <at> debbugs.gnu.org>; Mon, 13 Nov 2017 09:54:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=VCtoshp7GSO3lIE3vBP4w1jA0GNXupe/Ag+ndjsYzi0=;
 b=jA8J/dhoIucHUnAAWq8t9FMfLL4gv42WskvQMGuRDGlQmUc3MIAG1npxgK5VMseJpa
 WN2X8CxToeVxHni6N3lYY9O81Lv2ZNtDcVlvtfp0UflWR3JNcGzbGRVaA+uZHA2AQhiR
 ac6tS074w3RhhBDVF19hFlyHJP2M8n2D+M82s174ozig54KUjXwXRN5nZ2cw5xfWP/se
 qRSBfzVBJjZ/SpDD5/EB5jvzSMU/IfcCGwySdgK1lO5bT/yqPkmDbQB45ODCMTmH9WCI
 yYcP3fiDzU+IEnJfSlCwOnNoieR0SPP5on+LXw0+1JcE5vU5hubkflzgWZJJA1lDfl2M
 2gJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=VCtoshp7GSO3lIE3vBP4w1jA0GNXupe/Ag+ndjsYzi0=;
 b=KrZx99ceI1wxgeH0VqKf0mjfRh7TbTInMgCOi64jAnco9oY5WlG3GTmFureLLtiqhW
 G/HMV3ZtlpSbSboS8xl9eCvbhK+8GvXfaUoe20hSx/D1rLhwjGMZ6rTXZx15ziHtb9pz
 REjB1O61lZY3GDGyk3z4USQOl6OOWleGbMi0ecSJ25gEOgPXBWLo3YpJe23E0Wo/4KyV
 21ThLCaE0F3C1F6A7ggQ2XfeJ4HtbgGJslG9tsC22SNpLHwwq6tpDvtsJ5+fniMjkHa4
 Uv8YsoykiyeYxYI/xR7TzmI4DivBQOcw1iENY3G0UKTtwbe363EXibgKz6YAYFuIpeAw
 AqhQ==
X-Gm-Message-State: AJaThX4X96gJwnO01udTa/7xbMd9cu3tB8bisAiKS5rSzbxZaNKQHaUB
 TTIlxIeBPZ/PnaGUYEwvntc9WQrB
X-Google-Smtp-Source: AGs4zMbUbm87ld/fdvAGJfPtAnPM17BViqV8XZ+V4ZiH5qmAKqeIO1cQFh3GQq/YbTbhaf8oYsOAqw==
X-Received: by 10.80.245.181 with SMTP id u50mr11720033edm.171.1510595688303; 
 Mon, 13 Nov 2017 09:54:48 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id m8sm14224983edl.74.2017.11.13.09.54.46
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 13 Nov 2017 09:54:47 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
Date: Mon, 13 Nov 2017 19:54:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83375imbaa.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/13/17 5:46 PM, Eli Zaretskii wrote:
> I tend to like better the proposal originally made by Joost Kremers in
> http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01540.html.
> Here it is with slight variations of my own:

Overall, it seems like a friendlier API over fairly similar structures 
as what I suggested (just replace left-margin-columns-alist with 
left-margin-params). Except SYMBOL is not given a meaningful name (they 
are "columns" in my description).

> We add 3 new functions:
> 
>   (defun window-margin-add (window side symbol cols &optional ordinal)
>     "Request allocation of COLS columns of WINDOW's marginal area.
>   WINDOW must be a live window and defaults to the selected one.
>   SIDE is the window side, either `left' or `right', in whose margin
>     the allocation is requested.
>   SYMBOL identifies the request, in case the allocation needs to be
>     changed or deleted.
>   ORDINAL is the optional ordinal number of the requested area, counted
>     from left to right.  Negative ordinal numbers count from right to
>     left.  Zero means the value of COLS is the maximum width of the
>     marginal area, and no separate allocation is requested.

ORDINAL meaning the same as "order priority"? And the lower the value 
is, the more "left" the column should be positioned? Sounds OK to me.

I'm not sure I understand the "Zero means ..." passage, though.

In addition to signifying a neutral position, does it supposed to switch 
the meaning of this function into something that 
set-right-margin/set-left-margin can call, for backward compatibility?

Seems like a wart, using ORDINAL this way. And what's going to happen 
when somebody else calls window-margin-add with non-zero ORDINAL? Will 
the end result depend on which call happens first?

>   Value is the actual positive ordinal number of the allocated area."

Return value?

> If the stuff (text, image, etc.) to be displayed in a specified
> portion of the marginal area is too wide and doesn't fit the width of
> the portion, it will be truncated; if it is narrower, it will be
> padded.

Padded from the left or from the right? :)

> This keeps the display engine design intact, and I think will allow
> relatively straightforward implementation (although some non-trivial
> changes in management of the glyph matrices will be necessary).  It
> can also be implemented in a way that keeps backward compatibility
> with the current APIs.
> 
> WDYT?

Aside from the ORDINAL edge case, it sounds good to me.

Here's an interesting question: after such an API is added, will it be 
feasible to re-implement display-line-numbers-mode using a margin 
column, instead of the special separate area?

And if not, how can we make this API better that you could?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 18:16:01 +0000
Resent-Message-ID: <handler.29279.B29279.151059694015204 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151059694015204
          (code B ref 29279); Mon, 13 Nov 2017 18:16:01 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 18:15:40 +0000
Received: from localhost ([127.0.0.1]:38812 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEJGm-0003xA-Fo
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 13:15:40 -0500
Received: from eggs.gnu.org ([208.118.235.92]:54715)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEJGk-0003ww-Lf
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 13:15:39 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEJGc-0006zB-4w
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 13:15:33 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39154)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEJGc-0006z7-10; Mon, 13 Nov 2017 13:15:30 -0500
Received: from [176.228.60.248] (port=2024 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEJGb-0003ez-KD; Mon, 13 Nov 2017 13:15:29 -0500
Date: Mon, 13 Nov 2017 20:15:36 +0200
Message-Id: <83po8mkptj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <b37bad4f-6994-7d0e-4af4-2c73576d24fa@HIDDEN> (message from
 Dmitry Gutov on Mon, 13 Nov 2017 19:24:21 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <834lpymbga.fsf@HIDDEN> <b37bad4f-6994-7d0e-4af4-2c73576d24fa@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Mon, 13 Nov 2017 19:24:21 +0200
> 
> >> - Text alignment within the column (left or right)
> > 
> > Why does this need to be a separate property?  We don't have anything
> > like that for any other kind of text.
> 
> IDK, why not? Will we always align to the right?

No, to the left.  If a Lisp program wants to align to the right, it
should insert white space before the actual text.

> > I think we need to agree on the model of the display in the margins.
> > The fact that you use "columns" in your proposal hints that each
> > "user" of the margin (a Lisp program which displays there) will have a
> > separate "column" in the margin, and that column will be of the same
> > pixel width for each screen line.
> 
> Yes.
> 
> > If this is the model, then it makes
> > little sense to have different display specs regarding the "column"
> > width for each buffer position where display in the margin is
> > requested, because the resulting column width will be the same for all
> > such displays.
> 
> The width of the string inside the margin display specs can very, can't it?

The width can change, but the column width will not change.  That
means the column width should be specified only once, not multiple
times.

> > If we specify these in each display spec, we are in
> > effect wasting Lisp storage, and potentially also working against the
> > fundamental design of the display engine (more about that below).
> 
> Sorry, specify what? The margin display spec will continue to be
> 
>    ((margin column-name) spec)
> 
> where SPEC is a text string, most of the time.

I thought you wanted all the other parameters in the spec as well.

But if you didn't mean that, then what kind of scanning and
calculations are you talking about here:

> >> The display engine would scan the contents of the current window, process said specs, calculate which lines fit the window and which do not, set the total margin width appropriately, and display all columns in it. Some reflowing might be required.

If everything is already spelled out in a variable
left-margin-columns-alist, then why do we need to scan the contents of
the window?

> > So what you suggest can only be implemented by displaying each window
> > twice.  On top of that, it will disable important redisplay
> > optimizations, which refrain from examining all of the screen lines
> > and the corresponding buffer text -- since you require to scan all of
> > the display specs in the window to dynamically compute the margin
> > dimensions.
> 
> I was hoping that we might consider some parts of redisplay to be "fast 
> enough" by now (posn-at-point is fast enough for ~500 FPS on my machine, 
> for instance), but indeed it should require some smart programming.

posn-at-point goes _once_ from window-start to the specified position,
so on average it traverses half a window, once.  By contrast, we are
now talking about redisplaying the window twice, and one of these 2
times must traverse the entire window.  So we are talking about
threefold slow-down on the average.

> What your description tells me, foremost, is that it should be 
> impossible to "perfectly" make these decisions in Lisp, too.
> 
> Like, what can linum-mode do? After scrolling, it would look at the 
> window-start, its height, and calculate the _approximate_ physical line 
> at the end of the window.

linum uses window-end (which could be nil in some cases).  window-end
is updated by redisplay when it ends successfully.  linum then updates
the width of the window margins if needed, and updates all the
overlays with line numbers, which triggers an immediate additional
redisplay.  That's why it is slow.

So yes, if the margin display depends heavily on what is in the
window, especially on how many lines/characters are in the window, it
will have hard time being Speedy Gonzales; such features are better
implemented in C as an integral part of redisplay.  But not all uses
of the margins are like that.  I will even risk saying that most of
them aren't.  For that majority, calculating the maximum width they
need from the margin at the end of a command is not a big deal, and
could probably change relatively rarely.

> I guess more accurately, it would disallow dynamic *sizing* of the 
> margins by the display engine.

With the current design of the display engine, dynamic resizing is not
a good idea.  Any such resizing is painful: it requires throwing away
the window's glyph matrices, reallocating them anew with the new
dimensions, and then completely redrawing the entire window.  It's
expensive and should be avoided.

> Column widths will be accessible for manipulation from e.g. 
> pre-redisplay-functions, but like described above, it doesn't seem like 
> choosing margin width precisely is feasible in Lisp, even in the use 
> case of showing line numbers.

I think it's feasible in many cases.  Linum and its ilk are a rare use
case, although the resulting feature is very popular (which is why we
now have the native line numbers).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 18:30:02 +0000
Resent-Message-ID: <handler.29279.B29279.151059778816454 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151059778816454
          (code B ref 29279); Mon, 13 Nov 2017 18:30:02 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 18:29:48 +0000
Received: from localhost ([127.0.0.1]:38819 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEJUR-0004HG-Rl
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 13:29:48 -0500
Received: from eggs.gnu.org ([208.118.235.92]:60017)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEJUP-0004H4-UI
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 13:29:46 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEJUG-0005w8-6H
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 13:29:40 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39520)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEJUG-0005vy-2n; Mon, 13 Nov 2017 13:29:36 -0500
Received: from [176.228.60.248] (port=2044 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEJUF-0008Mt-H0; Mon, 13 Nov 2017 13:29:35 -0500
Date: Mon, 13 Nov 2017 20:29:42 +0200
Message-Id: <83o9o6kp61.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN> (message from
 Dmitry Gutov on Mon, 13 Nov 2017 19:54:45 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Mon, 13 Nov 2017 19:54:45 +0200
> 
> >   ORDINAL is the optional ordinal number of the requested area, counted
> >     from left to right.  Negative ordinal numbers count from right to
> >     left.  Zero means the value of COLS is the maximum width of the
> >     marginal area, and no separate allocation is requested.
> 
> ORDINAL meaning the same as "order priority"?

Yes.

> And the lower the value is, the more "left" the column should be
> positioned? Sounds OK to me.

Yes.

> I'm not sure I understand the "Zero means ..." passage, though.

That's your "total width" thing, for margin users that just want to
set the overall width of the margins without displaying anything
there.  Like Joost Kramer's visual-fill-column and similar packages.

> In addition to signifying a neutral position, does it supposed to switch 
> the meaning of this function into something that 
> set-right-margin/set-left-margin can call, for backward compatibility?

Yes, set-window-margins will most probably be reimplemented by calling
the above.

> Seems like a wart, using ORDINAL this way. And what's going to happen 
> when somebody else calls window-margin-add with non-zero ORDINAL? Will 
> the end result depend on which call happens first?

Yes.  And the result is returned, so the caller knows that.  If you
have better ideas for requesting a particular position in the margin,
let's hear them.

> >   Value is the actual positive ordinal number of the allocated area."
> 
> Return value?

Yes.

> > If the stuff (text, image, etc.) to be displayed in a specified
> > portion of the marginal area is too wide and doesn't fit the width of
> > the portion, it will be truncated; if it is narrower, it will be
> > padded.
> 
> Padded from the left or from the right? :)

On the right.

> Here's an interesting question: after such an API is added, will it be 
> feasible to re-implement display-line-numbers-mode using a margin 
> column, instead of the special separate area?

Yes.  But using margins from Emacs internals means that the
window-parameters which hold the column specs will change behind the
back of the Lisp applications, which I'm not sure is a Good Thing.  It
will also be somewhat slower.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 19:03:02 +0000
Resent-Message-ID: <handler.29279.B29279.151059975519514 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151059975519514
          (code B ref 29279); Mon, 13 Nov 2017 19:03:02 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 19:02:35 +0000
Received: from localhost ([127.0.0.1]:38848 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEK0B-00054f-5J
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:02:35 -0500
Received: from mail-wr0-f180.google.com ([209.85.128.180]:49083)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEK09-00054J-Ru
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:02:34 -0500
Received: by mail-wr0-f180.google.com with SMTP id 15so15340235wrb.5
 for <29279 <at> debbugs.gnu.org>; Mon, 13 Nov 2017 11:02:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=CGvbCtbdz3k1sQGBWsQjbRGvmuq1DzdRMWxXIQOyYb8=;
 b=EfEtKAeyw+i4DQLugoyGOEoT6uCrngVOEZL7TZk6jhQP7HMia+slDiIatOArM0AYtn
 ImYXU/nawJ4l5rOQ9TA82rao+svqKveVBZe8/QtZ+vJaUGvYk67DAZLzYVk4HIJtE7Ty
 ev6/Z5/uY8OAkkYLxbVQNf4P3XnHSYkmvKiKjyge1BxWWtSc15unCzS9rp1IJcv+uSuc
 1+8WbzfxDuHHHgyrzvDykhIBA1oKxUlpVLT5wBXlq2sW2xr1nflLDP2AeMebAoKigg/s
 H1MIHTMfgof7nUiI3cFZti1Va3435Lkg7hbp0MmyR8FjbjhMYDPQ3Ast9OmLJVPXWe0E
 RWvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=CGvbCtbdz3k1sQGBWsQjbRGvmuq1DzdRMWxXIQOyYb8=;
 b=JiCrf1JMIafgdRVdmFofa5naFSw3GdvD+tGa57jHO/ihz/134Ym5aA0QHdX//RAWe9
 biEb9bzupBUym/HowE+rIeoO1grFm1DagZtLoB0KAcmQ3dYQaGnBs9GxUFlCnebP7b9I
 USRldFm28v5wWrSeRDq9YHHl8uCShQJQqw6MLt6ZrBfUS68YJRIQIXbZ50aRgytABc5C
 U62rj1mtQ/hjUcPr3xyoJML8+wI8gbLmT50+EbCUgIFuwtfqHzKWpK7ZU+GYtb8xCKv1
 skol32YjsqXD+duJaSnaZQVlwm7RbrJn3eI2jQBHR8HJLCQDysK9IyFGBhj/hkMSyaPG
 P6oA==
X-Gm-Message-State: AJaThX5uEvsyBNktlQYvdWvdRAgI1I5K/X2ON+P8emxkTpohHyMZ+FjS
 rXiEiOx4NmkrFHq4C1+TZV0dIhYq
X-Google-Smtp-Source: AGs4zMZ1UavA4QSnUQTn5VZPNHtO3yjgUqPxlscNY4Nqu8NxZ8isRHklmHYLXPyIbzRceLqmkcJ5RQ==
X-Received: by 10.223.198.130 with SMTP id j2mr8321272wrg.52.1510599747581;
 Mon, 13 Nov 2017 11:02:27 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id e124sm4924760wmg.34.2017.11.13.11.02.25
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 13 Nov 2017 11:02:25 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <834lpymbga.fsf@HIDDEN> <b37bad4f-6994-7d0e-4af4-2c73576d24fa@HIDDEN>
 <83po8mkptj.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <56131da6-14fb-d669-f69a-72fd2e696d5c@HIDDEN>
Date: Mon, 13 Nov 2017 21:02:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83po8mkptj.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)

On 11/13/17 8:15 PM, Eli Zaretskii wrote:

> No, to the left.  If a Lisp program wants to align to the right, it
> should insert white space before the actual text.

That's only possible if it knows the resulting width. Which it will, in 
the current state of the discussion.

Still, it seems unnecessary if the somewhat faster C code could 
implement that for every user.

>>>> The display engine would scan the contents of the current window, process said specs, calculate which lines fit the window and which do not, set the total margin width appropriately, and display all columns in it. Some reflowing might be required.
> 
> If everything is already spelled out in a variable
> left-margin-columns-alist, then why do we need to scan the contents of
> the window?

In the first proposal, the actual width of the column would be 
auto-computed by the display engine based in the width of all relevant 
SPECs.

But we seem to have discarded this idea now.

>> I was hoping that we might consider some parts of redisplay to be "fast
>> enough" by now (posn-at-point is fast enough for ~500 FPS on my machine,
>> for instance), but indeed it should require some smart programming.
> 
> posn-at-point goes _once_ from window-start to the specified position,
> so on average it traverses half a window, once.  By contrast, we are
> now talking about redisplaying the window twice, and one of these 2
> times must traverse the entire window.  So we are talking about
> threefold slow-down on the average.

3-fold slowdown from 500 FPS seems acceptable to me.

> So yes, if the margin display depends heavily on what is in the
> window, especially on how many lines/characters are in the window, it
> will have hard time being Speedy Gonzales; such features are better
> implemented in C as an integral part of redisplay.  But not all uses
> of the margins are like that.  I will even risk saying that most of
> them aren't.  For that majority, calculating the maximum width they
> need from the margin at the end of a command is not a big deal, and
> could probably change relatively rarely.

Let's hope so.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 19:17:02 +0000
Resent-Message-ID: <handler.29279.B29279.151060060120791 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151060060120791
          (code B ref 29279); Mon, 13 Nov 2017 19:17:02 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 19:16:41 +0000
Received: from localhost ([127.0.0.1]:38864 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEKDn-0005PD-Tj
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:16:41 -0500
Received: from mail-wr0-f170.google.com ([209.85.128.170]:56838)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEKDm-0005Ou-2A
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:16:38 -0500
Received: by mail-wr0-f170.google.com with SMTP id q66so15371737wrb.13
 for <29279 <at> debbugs.gnu.org>; Mon, 13 Nov 2017 11:16:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=7VONMmq5IefiK+gq6PHrilWrg651LId96b+BJj4cn68=;
 b=h+SIHcYIw1RCNSxDm/swPlUcWOtDSNvOAC6SpyR4LVU90dX3C2sd0zv918F7HWfp6M
 0FmgwR7Wr6RqWYPu4+7s3aONbYGXphbpOd1sg/fLMk7FOSAbaxjiIKWmkUoXG5agkRaz
 5NiiQ/iIqLe7gEvvPgTrUCK7jnX9UAfxyDZpWOqGbjR11k6dm8IS4dYCAg3JWkeULytk
 UKapDpTVhqueTw9OjD1IH/1XzSRd2FmYGQz80QWnHFEqVDgufj/1KaHaszpY1S0q5tsK
 VSEU3gquLlwclvcOCx6jlmci9IDCeiedNTidxtQgnwjz+kRZcwqujh/5/GcW21OZffhg
 sDaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=7VONMmq5IefiK+gq6PHrilWrg651LId96b+BJj4cn68=;
 b=dMWXp9VTD2qowa/XAhldI+Au42TIxa6izOZ4oZiMoHFBmAcL8RY5A+u/oyggxSyh0s
 JOpVgitOGaWsiAEgf8irrXnynkXbilWqrSM71+rzylb3gL3oAFf8/socqpK4MTwsAItQ
 lkogfngDHl7QRR+XP2rxtMoPWx0tKvUdkjoUk3qaD1dv52gryX/VaYcCmmvCTdCspu20
 KOtL6TBdtu4csPqdYUpRRL+BiG2VPmbY3a+/+h5UtfXB+7P10msKwKvGxCVYUnnqVauo
 I3CEenAFdRj8Vrc4um7XaVoLOk8e6onzR8GIM+dxqVVgIQNiivNn5LBxc1DyZUJeWt/B
 99eA==
X-Gm-Message-State: AJaThX7e43b6ImI+t8lFjDi0F314BFdVKhQhuDkuj2KPBGbvZmx29+Ix
 5noFKbNh7kSiltl1p3oVoIwqGSwq
X-Google-Smtp-Source: AGs4zMbd67L3tv15CY53MJa9wbZ7HNux5OpxGlov3lO3ffPNW6P5vnPIy4YceJLQsOde8A42e5oamw==
X-Received: by 10.223.200.132 with SMTP id k4mr7791397wrh.215.1510600592058;
 Mon, 13 Nov 2017 11:16:32 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id s12sm39829789wrc.89.2017.11.13.11.16.30
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 13 Nov 2017 11:16:31 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
Date: Mon, 13 Nov 2017 21:16:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83o9o6kp61.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)

On 11/13/17 8:29 PM, Eli Zaretskii wrote:

>> I'm not sure I understand the "Zero means ..." passage, though.
> 
> That's your "total width" thing, for margin users that just want to
> set the overall width of the margins without displaying anything
> there.  Like Joost Kramer's visual-fill-column and similar packages.

OK, but why "maximum width"? workroom-mode wanted to set the total 
width, but if we want to describe what will happen with the column in 
question, the value sounds more like "minimum total width".

>> In addition to signifying a neutral position, does it supposed to switch
>> the meaning of this function into something that
>> set-right-margin/set-left-margin can call, for backward compatibility?
> 
> Yes, set-window-margins will most probably be reimplemented by calling
> the above.

Which area will the left-margin specs be drawn on, then? Ones without 
any particular symbol specified.

>> Seems like a wart, using ORDINAL this way. And what's going to happen
>> when somebody else calls window-margin-add with non-zero ORDINAL? Will
>> the end result depend on which call happens first?
> 
> Yes.  And the result is returned, so the caller knows that.  If you
> have better ideas for requesting a particular position in the margin,
> let's hear them.

Having ORDINAL to be a number is totally fine to me.

Having ORDINAL = 0 mean something else, not so great. Especially if the 
result is to have the padding in this column, necessary to reach the 
specified total width.

I imagine workroom-mode might have a idea where they want the padding to 
end up (to the left or to the right of all columns). So instead of 
co-opting the ORDINAL argument to mean "cols will  total cols"

>> Here's an interesting question: after such an API is added, will it be
>> feasible to re-implement display-line-numbers-mode using a margin
>> column, instead of the special separate area?
> 
> Yes.  But using margins from Emacs internals means that the
> window-parameters which hold the column specs will change behind the
> back of the Lisp applications, which I'm not sure is a Good Thing.

I was thinking more along the lines of being able to specify a 
spec-returning function (that uses the current buffer position), instead 
of only using the text properties. But changing the margins directly 
sounds faster.

Maybe not an entirely good thing, but certainly an improvement for the 
authors of third-party code.

> It will also be somewhat slower.

We should probably measure before discarding this idea.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 19:23:01 +0000
Resent-Message-ID: <handler.29279.B29279.151060097421367 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151060097421367
          (code B ref 29279); Mon, 13 Nov 2017 19:23:01 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 19:22:54 +0000
Received: from localhost ([127.0.0.1]:38874 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEKJq-0005YZ-3G
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:22:54 -0500
Received: from eggs.gnu.org ([208.118.235.92]:50708)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEKJo-0005YL-42
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:22:52 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEKJf-0007Ot-Ul
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:22:47 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41060)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEKJf-0007Op-Rs; Mon, 13 Nov 2017 14:22:43 -0500
Received: from [176.228.60.248] (port=2101 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEKJf-0002yW-3P; Mon, 13 Nov 2017 14:22:43 -0500
Date: Mon, 13 Nov 2017 21:22:49 +0200
Message-Id: <83ineekmpi.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <56131da6-14fb-d669-f69a-72fd2e696d5c@HIDDEN> (message from
 Dmitry Gutov on Mon, 13 Nov 2017 21:02:23 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <834lpymbga.fsf@HIDDEN> <b37bad4f-6994-7d0e-4af4-2c73576d24fa@HIDDEN>
 <83po8mkptj.fsf@HIDDEN> <56131da6-14fb-d669-f69a-72fd2e696d5c@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Mon, 13 Nov 2017 21:02:23 +0200
> 
> On 11/13/17 8:15 PM, Eli Zaretskii wrote:
> 
> > No, to the left.  If a Lisp program wants to align to the right, it
> > should insert white space before the actual text.
> 
> That's only possible if it knows the resulting width. Which it will, in 
> the current state of the discussion.
> 
> Still, it seems unnecessary if the somewhat faster C code could 
> implement that for every user.

We could add that later if needed.  It's not rocket science, it's just
more complexity.

> > posn-at-point goes _once_ from window-start to the specified position,
> > so on average it traverses half a window, once.  By contrast, we are
> > now talking about redisplaying the window twice, and one of these 2
> > times must traverse the entire window.  So we are talking about
> > threefold slow-down on the average.
> 
> 3-fold slowdown from 500 FPS seems acceptable to me.

For each redisplay cycle?  On top of disabling most redisplay
optimizations?  I doubt that.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 19:33:02 +0000
Resent-Message-ID: <handler.29279.B29279.151060155822365 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151060155822365
          (code B ref 29279); Mon, 13 Nov 2017 19:33:02 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 19:32:38 +0000
Received: from localhost ([127.0.0.1]:38890 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEKTG-0005oe-I2
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:32:38 -0500
Received: from eggs.gnu.org ([208.118.235.92]:54326)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEKTF-0005oS-6J
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:32:37 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEKT5-0003Gy-Hd
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:32:32 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41365)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEKT5-0003Gs-Di; Mon, 13 Nov 2017 14:32:27 -0500
Received: from [176.228.60.248] (port=2103 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEKT4-0002w1-R6; Mon, 13 Nov 2017 14:32:27 -0500
Date: Mon, 13 Nov 2017 21:32:34 +0200
Message-Id: <83h8tykm99.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN> (message from
 Dmitry Gutov on Mon, 13 Nov 2017 21:16:30 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Mon, 13 Nov 2017 21:16:30 +0200
> 
> On 11/13/17 8:29 PM, Eli Zaretskii wrote:
> 
> >> I'm not sure I understand the "Zero means ..." passage, though.
> > 
> > That's your "total width" thing, for margin users that just want to
> > set the overall width of the margins without displaying anything
> > there.  Like Joost Kramer's visual-fill-column and similar packages.
> 
> OK, but why "maximum width"? workroom-mode wanted to set the total 
> width, but if we want to describe what will happen with the column in 
> question, the value sounds more like "minimum total width".

Indeed, I meant to write "total", not "maximum".

> > Yes, set-window-margins will most probably be reimplemented by calling
> > the above.
> 
> Which area will the left-margin specs be drawn on, then? Ones without 
> any particular symbol specified.

Either without any symbol, or with nil, or with some invented symbol.
Something ti figure out as part of the implementation.

> Having ORDINAL = 0 mean something else, not so great. Especially if the 
> result is to have the padding in this column, necessary to reach the 
> specified total width.

My idea was not to create a column, just make sure the total width is
no less than the requested value.  Which means some of the requested
columns will be wider than requested, I guess.

> I imagine workroom-mode might have a idea where they want the padding to 
> end up (to the left or to the right of all columns). So instead of 
> co-opting the ORDINAL argument to mean "cols will  total cols"

We need to study the needs of potential users, no doubt, before
finalizing the API.

> > It will also be somewhat slower.
> 
> We should probably measure before discarding this idea.

The slowdown will be caused by resizing of the margins (and all the
window-configuration-change-hooks that triggers).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 19:34:01 +0000
Resent-Message-ID: <handler.29279.B29279.151060159822446 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151060159822446
          (code B ref 29279); Mon, 13 Nov 2017 19:34:01 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 19:33:18 +0000
Received: from localhost ([127.0.0.1]:38894 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEKTt-0005py-TH
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:33:18 -0500
Received: from mail-wm0-f54.google.com ([74.125.82.54]:38881)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEKTs-0005pm-Ut
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 14:33:17 -0500
Received: by mail-wm0-f54.google.com with SMTP id z3so7278840wme.3
 for <29279 <at> debbugs.gnu.org>; Mon, 13 Nov 2017 11:33:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=GgyRXxie08WoN9YBDrgMIFKak+qKUIUpWzrj3K3vupA=;
 b=pfsnjiHVyCmtgczxIUGuA2wnevsZRCpFHRSgJWzTI+Kf507l6ti/KzrzZy9+G9nStp
 z3Cy9wFdSlugsGV3jawjXXYfzhwtI6ef/hmMoVZef4f5eCAHI6Cp1zF1qjo/YYC7/FE1
 +NbExOSTMTZiBN2HOtUVNQrAq14twSnHma3YXUZSk7vgQ4wFliyhCohnCFBLP1Bt06ry
 NCB68iGvSght2LSrdDMuS0zQl8xQiUbMt9s/i1O4EH66j3z0StontoRvN/N066iMwhzC
 XZPYsfD2zANhJthQQxg2vJgWRcvpwNbTdjvGH0Kn6LSEKJX22z58y8Iher5p32srWOwD
 eFIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=GgyRXxie08WoN9YBDrgMIFKak+qKUIUpWzrj3K3vupA=;
 b=m2T/K0sRXA8DuyvTSMUeT3gzApc+AJXernNWcifSnFnToTleBglciqXCiC+q1XC45A
 EDTUe38lXe/fe3litelXGGa6XxovSOYGOD/r3QBo5gSAjoysUNZHwm+y2h2xMxxzez9p
 S2mJNVvrEF+wM+En428PvBienExIlyGOd70A6KtkdAodE/GQfKXRa31skeXbAJvCcykF
 UiOepv2S6CmyVLQ5luQNsq1YYdb3b5zTS00h5ZQ+kkeey60D9oRIy47U5oobCD6jMFXs
 cxxu+yAwhhuJf1axSdiL1tYLvHYrhyJDAbXEK/AU3ivd+EJUG+H90E9btoyRLiQhoW3H
 2XQA==
X-Gm-Message-State: AJaThX6pgQYJ8b6wnWRsV5DFZfxarQ1CtNjUrOqjacNzzclEE4A0/f5D
 tqaSQtgXMsHSFlRCXkgpzL4tMlOU
X-Google-Smtp-Source: AGs4zMade+o/6XAbuy8mycMbI/AxhnItXl9XHibP4bGYEpSgE6SiMUpecWcwcYt10DK1bOtQkIHW9A==
X-Received: by 10.80.135.226 with SMTP id 31mr14444676edz.210.1510601590857;
 Mon, 13 Nov 2017 11:33:10 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id r8sm996120edm.22.2017.11.13.11.33.09
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 13 Nov 2017 11:33:10 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <834lpymbga.fsf@HIDDEN> <b37bad4f-6994-7d0e-4af4-2c73576d24fa@HIDDEN>
 <83po8mkptj.fsf@HIDDEN> <56131da6-14fb-d669-f69a-72fd2e696d5c@HIDDEN>
 <83ineekmpi.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <39c4661e-f7cb-7979-7025-e529d86883ed@HIDDEN>
Date: Mon, 13 Nov 2017 21:33:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83ineekmpi.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/13/17 9:22 PM, Eli Zaretskii wrote:

>> Still, it seems unnecessary if the somewhat faster C code could
>> implement that for every user.
> 
> We could add that later if needed.  It's not rocket science, it's just
> more complexity.

Yup.

>>> posn-at-point goes _once_ from window-start to the specified position,
>>> so on average it traverses half a window, once.  By contrast, we are
>>> now talking about redisplaying the window twice, and one of these 2
>>> times must traverse the entire window.  So we are talking about
>>> threefold slow-down on the average.
>>
>> 3-fold slowdown from 500 FPS seems acceptable to me.
> 
> For each redisplay cycle?  On top of disabling most redisplay
> optimizations?  I doubt that.

Hard for me to tell. Like, in the recent discussion of a performance 
problem related to double-buffering, apparently Emacs itself wasn't the 
rendering bottleneck.

You probably know better, though.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 13 Nov 2017 21:17:02 +0000
Resent-Message-ID: <handler.29279.B29279.151060778731589 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, Joost Kremers <joostkremers@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151060778731589
          (code B ref 29279); Mon, 13 Nov 2017 21:17:02 +0000
Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 21:16:27 +0000
Received: from localhost ([127.0.0.1]:38954 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEM5i-0008DQ-Iz
	for submit <at> debbugs.gnu.org; Mon, 13 Nov 2017 16:16:27 -0500
Received: from mail-wm0-f42.google.com ([74.125.82.42]:35457)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEM5g-0008DD-Jk
 for 29279 <at> debbugs.gnu.org; Mon, 13 Nov 2017 16:16:24 -0500
Received: by mail-wm0-f42.google.com with SMTP id y80so17430784wmd.0
 for <29279 <at> debbugs.gnu.org>; Mon, 13 Nov 2017 13:16:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=rl9Rze5pEf21JEKE/GsiLvpHRs9//JSk+WEKXU8bJ2E=;
 b=TR2sCHHnm5kLMFScBe+pt5TY9EHAfV+9YgiG+bFHcihM5mMEsgJTsttVPCRZEDILbe
 9I3ZkBvbjS3/SAOJwzRSAA3x0lPKp8iTBGzmOLdsUu2aHP8n9qHXV0LuTt8Xblf8u68P
 3pTLuaDmLkU5Sw8X23mcIwHvlUwmGKdhO7oUr74Jbn/qksePpeK+e0/33Zj2hZJgUrVq
 bIQQ0XdefBGXaSMzIjEcBqQcsmjm3C2B+/+UpJxh5FbV7UU/WYUEiWaKotSA4jk2ATRz
 qU9Zv8eV9hR5sZXHkeWNvwuDGDj1/qcswX9jCH0+/MAY4Y6gYQXNzprojN0xcT7MVf82
 gdvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=rl9Rze5pEf21JEKE/GsiLvpHRs9//JSk+WEKXU8bJ2E=;
 b=c4uZoQZMqA3Pyv8AWQ/CAIO/mZ9hFTvpNjvzAGxppFYkBAE1cf8/SwB+2RQDpe+Lmu
 vyE0ZE38bIrqXS/09/PF3WGzbybHsco0GmNfpdg+EZbm4UNIzmpV1RIjVLagDI3xL1o7
 LCwFnkT5YWADjterFmiT9VaCHXnhnhUP6rINIMLh8x/F5dXt67bjR/HTN2vPnjiYRAaR
 RS6zrtrH9/FMGpB0im45ZKVXjIpMcn6nN+W21h/yCrktI20G6CPRdZVXb2wABmNGBNVu
 1OTWNd7IcHXjXztgRSHRk21FFY5xcSLC3vvVo3IoIYijzymm22+xsxRmbzqUqGwHRl0d
 8giQ==
X-Gm-Message-State: AJaThX6TmJC8xqM5i4nx3hSjr+Tsg44Bubr2kgFPvda3vXcWXaOsasOZ
 0q74jJIrS8JHrxJMnhMUnwL+/bEm
X-Google-Smtp-Source: AGs4zMZYJumjUK3O7+tjTGK9dJkomui0k4SHGaEs+wZy61kVUFPkomtujK2aCLGxdGEiSGVJWefZ1Q==
X-Received: by 10.80.153.197 with SMTP id n5mr14418050edb.281.1510607778639;
 Mon, 13 Nov 2017 13:16:18 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id 23sm13305740edx.8.2017.11.13.13.16.16
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 13 Nov 2017 13:16:17 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
Date: Mon, 13 Nov 2017 23:16:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83h8tykm99.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/13/17 9:32 PM, Eli Zaretskii wrote:

>> OK, but why "maximum width"? workroom-mode wanted to set the total
>> width, but if we want to describe what will happen with the column in
>> question, the value sounds more like "minimum total width".
> 
> Indeed, I meant to write "total", not "maximum".

I see.

>>> Yes, set-window-margins will most probably be reimplemented by calling
>>> the above.
>>
>> Which area will the left-margin specs be drawn on, then? Ones without
>> any particular symbol specified.
> 
> Either without any symbol, or with nil, or with some invented symbol.
> Something ti figure out as part of the implementation.

I think set-window-margins, and the nil/unknown symbols should work with 
the 'default' symbol. And it will have the ordinal = 0.

Then, older packages that are not updated to use the new API can fight 
between themselves for the use of the default column, but the winner can 
peacefully coexist with the packages using the new API.

>> Having ORDINAL = 0 mean something else, not so great. Especially if the
>> result is to have the padding in this column, necessary to reach the
>> specified total width.
> 
> My idea was not to create a column, just make sure the total width is
> no less than the requested value.  Which means some of the requested
> columns will be wider than requested, I guess.

It would probably look not too great. Just like 'text-align: justify' 
often works bad on web pages.

So I'd personally prefer to have all padding on one side.

Then, unless people disagree, setting the total width could be made into 
a separate call. With three arguments: side, width and the side from 
which to pad (inside/outside, for instance).

>> I imagine workroom-mode might have a idea where they want the padding to
>> end up (to the left or to the right of all columns). So instead of
>> co-opting the ORDINAL argument to mean "cols will  total cols"
> 
> We need to study the needs of potential users, no doubt, before
> finalizing the API.

Inviting Joost into the discussion.

>>> It will also be somewhat slower.
>>
>> We should probably measure before discarding this idea.
> 
> The slowdown will be caused by resizing of the margins (and all the
> window-configuration-change-hooks that triggers).

Doesn't the use of the special area trigger the window configuration 
changes as well, in similar situations? After all, it also changes the 
accessible window body width, right?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 09:55:02 +0000
Resent-Message-ID: <handler.29279.B29279.151065329231310 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151065329231310
          (code B ref 29279); Tue, 14 Nov 2017 09:55:02 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 09:54:52 +0000
Received: from localhost ([127.0.0.1]:39352 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEXvg-00088w-71
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 04:54:52 -0500
Received: from mout.gmx.net ([212.227.15.19]:59135)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1eEXvf-00088k-37
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 04:54:51 -0500
Received: from [192.168.1.100] ([46.125.250.30]) by mail.gmx.com (mrgmx003
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LztHH-1fI9El34zr-0152eX; Tue, 14
 Nov 2017 10:54:44 +0100
Message-ID: <5A0ABD5C.1050109@HIDDEN>
Date: Tue, 14 Nov 2017 10:54:36 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN>
In-Reply-To: <83375imbaa.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:Bek0rALiN8tskzZcIKhdVCkL9HFJ2g5uIWOZ0InleArv8KAGilO
 uSZ/sKpu5vxasy9LV3M9ufSwEiq0BjDKeyl4Dqvfkm5mYy7YOytc3i/e8OwmBLCNLGGaL6r
 ol5M0161JI4VjanxEJ3s5WecUg/lWBtqxICEXh2r2EhhoNYvVaczPMrb8HwV/kLKfTfjBgB
 d3k2koufoJY/PEFQlRKvQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:tH07unTZarE=:WHGZnLuvZ0jZdnerGoS8Ke
 W1/nqUHUerjMssODPxt71zwm/WAauG3G/z8aB3c0/ne+PfJnwl5GhuY0lxr54Gy3den4nKDXz
 xbWPN/zsJw1/iYozuzRBcYdN7sYpwApUE9pYrhpxmbcWv//ZhYHQ1R7Ehf7mFOBev4X8Ghh29
 wh/pQMpaNtPxFkJY7VOjR/cJwEUIY5hfDK7erM8KMQ8i5s8rSTDF8RvC6OZrJOJvoVHpCI/uK
 ni32grwq1FswDmYGUY7xoVwRz7g8Ba4AAxeqc9Jr0NJhW6Q3qOphJcCIe2iZ3kEr1pULyLHTU
 8PYNznZOMzVR3gQ/UR090JV7Ux4/L7xhH2vWo4HYGTNI98byn8Cc7AEPjXXliTjSZz5bTDEao
 xGR7UTw9z9sbKQDISPUQB9Rgy87+WRM/qEDcRwYK1bagGNXr8UptDevSj/wTKgKQoYp+Wa5oz
 02FRVmv2zZZBraNIWFi3wmgww4k+3qZnoov29gs4aV2iSlu4ha4AwRnFmo5IFtOTTDCaSFXLl
 OHvfK7rfvRtuvn2YQnVwPOKB/y1dKymttBqX5aaRCK2AX6c770nR02cE3h73RgFGTFhaMk2FG
 SlAimdkIgQT5Mrcrvn5zga5qWY+bwREz3FJghBB7xOVLrE9xK6MaERHqnVsVer0m3JdP//r5l
 4++vFldcZpwkvDi1ER1IuKOsh/yuJ+OkVnnbSepiePQuaTNQeen/OUeUr0+i+Xqbd0u5gGWLd
 0jvOq0JslH6x0ztUPmEAq/wp7nIHYyp6CAM85SY6R7tD8vLimPZujAkVk3YZdNh0T+ShWLEEg
 wWq0/Um3SD9AFGCTcKdwE6PyQBdQf5NpxBC7cbxADqCVJ82U+CYZCMe6lFDP7jYQPe3OUM3
X-Spam-Score: -3.5 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.5 (---)

 >   ORDINAL is the optional ordinal number of the requested area, counte=
d
 >     from left to right.  Negative ordinal numbers count from right to
 >     left.

I'd prefer ORDINAL represent an integer such that 0 means to put it in
the middle of that margin, a negative value farther to the left and a
positive value farther to the right with clashes decided in some
unspecified way.  I tried a similar thing with side windows.  The idea
is that a "don't care where to put it" application has a neutral choice
against others which explicitly want to display their elements left- or
rightmost.

 >     Zero means the value of COLS is the maximum width of the
 >     marginal area, and no separate allocation is requested.

I'd use a separate symbol (say 'pad-to-cols') for that.

BTW is =E2=80=98window-margin-modify=E2=80=99 just for the sake of the li=
ne numbers
codes or which other users would it have?

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 09:56:02 +0000
Resent-Message-ID: <handler.29279.B29279.151065330531363 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151065330531363
          (code B ref 29279); Tue, 14 Nov 2017 09:56:02 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 09:55:05 +0000
Received: from localhost ([127.0.0.1]:39355 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEXvq-00089V-I2
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 04:55:02 -0500
Received: from mout.gmx.net ([212.227.15.15]:65030)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1eEXvn-000896-FV
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 04:54:59 -0500
Received: from [192.168.1.100] ([46.125.250.30]) by mail.gmx.com (mrgmx001
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MMkDH-1eHXfe2eIp-008eFi; Tue, 14
 Nov 2017 10:54:53 +0100
Message-ID: <5A0ABD65.1030401@HIDDEN>
Date: Tue, 14 Nov 2017 10:54:45 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>	<83375imbaa.fsf@HIDDEN>	<bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN>
In-Reply-To: <83o9o6kp61.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:fiIpA87Pi6UnUmuTsoqheQwIgQpDwDLwXl18jomk0Bncqeu6kqB
 uLETiQpPIdLD65QOP78EzRrSOg20IMrNO0P2FVhIJvvzmNKUVOr73cLrPNUhFmvCFWMo+cT
 QgQhXFfmpKwkh+UWs8a0/fdocnLpCGR+OVtUrcpJGlx5D01TfzeKCRlNivQaTLo1AOUyzmb
 j/gD8gDe31xIHPlUqD/BA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:TqSbacjFBjw=:1nFc2HG48QqAiTSgkuaj+k
 YNROtotJcEnN2RdvpEYK9ZB30h9JmOHpYZgkEiNK3m4Q29G8x7r7fX6ECoBYz1T+nvmpiUQju
 ih7job2MJ7fFa4bqeBV4VfHobhxL5P4vaRVesWUzRFgg6MjpIpKi/gkk8gVNuozYKwG/j4EuE
 i+V3JLTd1rSLKie5CwVyhEYg49PceWrVbsS1tFDSLJIs/blUhFxUGCzR8wLqp1DNH/HHDmqM+
 yOqTmRjvWiC8TfGT05wZ01Ou8C235wpH0LBjCK8omQ81OVSzR+pZ1KV9V0U+dhaeb2bXkjxm7
 /0u9uktxBJysLhgKWs0AqWzlpPcpmMmbvteuuOzma6ZrJcuK5+GYQE9PyZ7hs1u/x109r00GK
 oRFPFavLdhh2DGXBkh+PsovNfWs1cmkQ9LvttUn6/s0SMCXaBDGNxmLjbtfBLABP88jsvf4uE
 /g4emp5/t2nsXeWI55y1wge/FBfOKV2D9ys2RYZrDaq6pz1ZebUV9uLSd7+WAHmW2s7dr320E
 dBIGoqsKqA4cpZnvlecICWgT7ZQ9ckotSGh+A2/mltnt6TwzlfPHeQ8WL27jSLfksEP/LhOlx
 7tLHn580ZM0flfaKOKxK9Z0aId4fIhYNXzfSu7mo64kNhRkHjnm8o4rnfw7lAki9LocrRN249
 lGu1BbgF/7xexduYB2w6CSNX4Na/qOHzX+0kvhbUIFTZuG0fFkLqzYaPClmaLhMI1qZu1apM+
 A2zxLKFUMFgjASn9tVQ5aZ5ax4pskbNIGznPsIoe8r5CATJAQILW2l7f9SmmbC2zuT/kLWrui
 ubxYujVbKK5rcsCvMVg1sfC3/KazrKzCyDLSX+JKUkQjdPGaieeNcxK0OR2QLyGL/JZA/M9
X-Spam-Score: -3.5 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.5 (---)

 > Yes.  But using margins from Emacs internals means that the
 > window-parameters which hold the column specs will change behind the
 > back of the Lisp applications, which I'm not sure is a Good Thing.

I can see no harm in that.

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 15:31:01 +0000
Resent-Message-ID: <handler.29279.B29279.15106734525852 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15106734525852
          (code B ref 29279); Tue, 14 Nov 2017 15:31:01 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 15:30:52 +0000
Received: from localhost ([127.0.0.1]:40330 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEdAp-0001WK-Kd
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:30:51 -0500
Received: from eggs.gnu.org ([208.118.235.92]:46131)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEdAo-0001W6-4p
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:30:50 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEdAh-0005GX-S3
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:30:44 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33081)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEdAc-0005C1-Q3; Tue, 14 Nov 2017 10:30:38 -0500
Received: from [176.228.60.248] (port=3449 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEdAc-0006zU-0J; Tue, 14 Nov 2017 10:30:38 -0500
Date: Tue, 14 Nov 2017 17:30:47 +0200
Message-Id: <83375glvx4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN> (message from
 Dmitry Gutov on Mon, 13 Nov 2017 23:16:15 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, Joost Kremers <joostkremers@HIDDEN>
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Mon, 13 Nov 2017 23:16:15 +0200
> 
> I think set-window-margins, and the nil/unknown symbols should work with 
> the 'default' symbol. And it will have the ordinal = 0.
> 
> Then, older packages that are not updated to use the new API can fight 
> between themselves for the use of the default column, but the winner can 
> peacefully coexist with the packages using the new API.

Could be.

> > My idea was not to create a column, just make sure the total width is
> > no less than the requested value.  Which means some of the requested
> > columns will be wider than requested, I guess.
> 
> It would probably look not too great. Just like 'text-align: justify' 
> often works bad on web pages.
> 
> So I'd personally prefer to have all padding on one side.

But then requests for the rightmost (or leftmost) column will go
unsatisfied, for apparently no good reason.

> Then, unless people disagree, setting the total width could be made into 
> a separate call. With three arguments: side, width and the side from 
> which to pad (inside/outside, for instance).

That can be done, but the main issue is not the API in this case, I
think, it's the effect of the call.

> > The slowdown will be caused by resizing of the margins (and all the
> > window-configuration-change-hooks that triggers).
> 
> Doesn't the use of the special area trigger the window configuration 
> changes as well, in similar situations?

No, and I still hope we can avoid the need to do that.
tabulated-list-mode came close, but I eventually succeeded in making
it happy with the other hooks.

> After all, it also changes the accessible window body width, right?

It depends on your POV.  My POV is that it doesn't, since the window
dimensions and the dimensions of the text area are unaltered.  At
least one other person disagreed (vociferously).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 15:52:02 +0000
Resent-Message-ID: <handler.29279.B29279.15106746757739 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, dgutov@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15106746757739
          (code B ref 29279); Tue, 14 Nov 2017 15:52:02 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 15:51:15 +0000
Received: from localhost ([127.0.0.1]:40352 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEdUX-00020j-9F
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:51:15 -0500
Received: from eggs.gnu.org ([208.118.235.92]:54848)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEdUT-00020U-J1
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:51:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEdUI-0002tv-No
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:51:04 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33446)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEdUI-0002tp-JU; Tue, 14 Nov 2017 10:50:58 -0500
Received: from [176.228.60.248] (port=3460 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEdUH-0008DS-WA; Tue, 14 Nov 2017 10:50:58 -0500
Date: Tue, 14 Nov 2017 17:51:08 +0200
Message-Id: <83zi7okger.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <5A0ABD5C.1050109@HIDDEN> (message from martin rudalics on Tue,
 14 Nov 2017 10:54:36 +0100)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <5A0ABD5C.1050109@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Tue, 14 Nov 2017 10:54:36 +0100
> From: martin rudalics <rudalics@HIDDEN>
> CC: 29279 <at> debbugs.gnu.org
> 
>  >   ORDINAL is the optional ordinal number of the requested area, counted
>  >     from left to right.  Negative ordinal numbers count from right to
>  >     left.
> 
> I'd prefer ORDINAL represent an integer such that 0 means to put it in
> the middle of that margin, a negative value farther to the left and a
> positive value farther to the right with clashes decided in some
> unspecified way.

This would make it hard to request to be the leftmost or rightmost
column, I think.

> I tried a similar thing with side windows.  The idea is that a
> "don't care where to put it" application has a neutral choice
> against others which explicitly want to display their elements left-
> or rightmost.

I think this should be possible by a simple transformation of the
original argument.

> BTW is ‘window-margin-modify’ just for the sake of the line numbers
> codes or which other users would it have?

Any package whose requirement of the margin width is not constant, but
has to change due to some event.  Even visual-fill-column should need
it, I think.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 15:52:04 +0000
Resent-Message-ID: <handler.29279.B29279.15106747047785 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, dgutov@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15106747047785
          (code B ref 29279); Tue, 14 Nov 2017 15:52:04 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 15:51:44 +0000
Received: from localhost ([127.0.0.1]:40355 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEdV2-00021V-8D
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:51:44 -0500
Received: from eggs.gnu.org ([208.118.235.92]:55034)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEdV1-00021G-4S
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:51:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEdUr-0003GP-J6
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 10:51:38 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33454)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEdUr-0003GK-EQ; Tue, 14 Nov 2017 10:51:33 -0500
Received: from [176.228.60.248] (port=3461 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEdUq-0008FN-KP; Tue, 14 Nov 2017 10:51:33 -0500
Date: Tue, 14 Nov 2017 17:51:41 +0200
Message-Id: <83y3n8kgdu.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <5A0ABD65.1030401@HIDDEN> (message from martin rudalics on Tue,
 14 Nov 2017 10:54:45 +0100)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>	<83375imbaa.fsf@HIDDEN>	<bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <5A0ABD65.1030401@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Tue, 14 Nov 2017 10:54:45 +0100
> From: martin rudalics <rudalics@HIDDEN>
> CC: 29279 <at> debbugs.gnu.org
> 
>  > Yes.  But using margins from Emacs internals means that the
>  > window-parameters which hold the column specs will change behind the
>  > back of the Lisp applications, which I'm not sure is a Good Thing.
> 
> I can see no harm in that.

It's...unexpected.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 18:32:02 +0000
Resent-Message-ID: <handler.29279.B29279.151068427130612 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151068427130612
          (code B ref 29279); Tue, 14 Nov 2017 18:32:02 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 18:31:11 +0000
Received: from localhost ([127.0.0.1]:40515 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEfzL-0007xg-JI
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 13:31:11 -0500
Received: from mout.gmx.net ([212.227.17.22]:65368)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1eEfzJ-0007xR-Nq
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 13:31:10 -0500
Received: from [192.168.1.100] ([46.125.250.11]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LvhC4-1fHjOk4A3w-017Wkx; Tue, 14
 Nov 2017 19:31:03 +0100
Message-ID: <5A0B365E.5000508@HIDDEN>
Date: Tue, 14 Nov 2017 19:30:54 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <5A0ABD5C.1050109@HIDDEN> <83zi7okger.fsf@HIDDEN>
In-Reply-To: <83zi7okger.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:O7Vm7doyA/8b1oSsjzLdiqcpjcm+XokWy/gENPpqT2zdJvUZhu9
 +E8cHSOC0Z6sBVexcr9Tvk1NsJ/BZ9UL/hyE1VqAOW52u3IEWJZY/V9K8raBHwoI4iYX43v
 yi+IXzoCnVf9rNxjHTN4BeTJcuJn030hUjfFLiscuUR/OfHFOAWoCO3MsLQwCOxaOs45G8m
 THnCXbO8m2/+OyGTW2s3g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ECv5syvcJz8=:ZYDTVjXQ6s1UeKkEXNzpuG
 en39bSSEqKFbJ7VSgtuyN3Mlw9qZjqFqBd9kzj0pXIW8kwnNfZIjSK58f6Wlz/aPi4/jYfHja
 zcsmEd/+GihHHmXKSx+Uh8mgYnwfYo3D7bfWqpBdcXC8LrUXj8mzkT9Qq61mAHzTFzTEqWwG9
 Pfhoa1xYCgKq/tLyMe6R9Z8zAbmkAnc7m9ElCSKAhDREQVm0doWXHm8dIjpUkiZqoclqQHd/u
 LKsgFT4RMWFa8cn2cHQW9O/AUwVCa32s1uInizvSLkTTWKnENLgkhrCD4zUZ4PVG221jis6EE
 d9ZT51ggbio5y1tGwitY620AXdDP1AUZ1BB1mgLZv5jkoJpkGviFIGCnmWvFfNlJVwqszflFn
 sK076GEdqY8y84oo+vnx24mspFTYJTRlg8HH0JzLlI9Wod58bx8L016Xr2vWOUiVbIUBFJFGk
 GqEum+Mz25DfQFirPQohw9U++OiB9Fku9crsIHQKX5kuiE1xvWsEwwXkP/d9DMNd8+4cYwHPl
 BDLDRh52QBY3DFPI0HSHTA9Co2UzdFN+hlzjUsJG5Y3re+cpFM4M3V6hTE7tSiLo+viMh5Bqm
 kC7dz+8Kn7JUVH+7NYufPwCP3/fio8cRQE1TIeJoed/s5dE6yhMbtt3i1NHyzFkt949pLlhEG
 9YKBM0+1+PdvTu8CTc7DSeMDpVDBu62CeZpKHK8Fc2LfluBrz77PdFwSrV+29WBIXikBJOWPO
 VAwXiTDhMfwZMe2EkWshUg32iUY4hVBJMYortOgDsObaIJnSk2ZrsrFqfpOjkvsCAEwlsRlrG
 U5KPgJpt2nxWLNFEoPDxceEtwyjBlJDKqf4vXL+5QSYdakx2eU=
X-Spam-Score: -3.5 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.5 (---)

 > This would make it hard to request to be the leftmost or rightmost
 > column, I think.

most-negative/positive-fixnum maybe?

 >> BTW is =E2=80=98window-margin-modify=E2=80=99 just for the sake of th=
e line numbers
 >> codes or which other users would it have?
 >
 > Any package whose requirement of the margin width is not constant, but=

 > has to change due to some event.  Even visual-fill-column should need
 > it, I think.

What is visual-fill-column?

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 19:06:02 +0000
Resent-Message-ID: <handler.29279.B29279.15106863391351 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, dgutov@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15106863391351
          (code B ref 29279); Tue, 14 Nov 2017 19:06:02 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 19:05:39 +0000
Received: from localhost ([127.0.0.1]:40565 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEgWf-0000Li-2j
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 14:05:37 -0500
Received: from eggs.gnu.org ([208.118.235.92]:47939)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEgWd-0000LS-D1
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 14:05:35 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEgWU-0003Ev-55
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 14:05:30 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38120)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEgWU-0003Ek-1T; Tue, 14 Nov 2017 14:05:26 -0500
Received: from [176.228.60.248] (port=3968 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEgWS-0004Td-6Q; Tue, 14 Nov 2017 14:05:25 -0500
Date: Tue, 14 Nov 2017 21:05:26 +0200
Message-Id: <83ineck7ex.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <5A0B365E.5000508@HIDDEN> (message from martin rudalics on Tue,
 14 Nov 2017 19:30:54 +0100)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <5A0ABD5C.1050109@HIDDEN> <83zi7okger.fsf@HIDDEN>
 <5A0B365E.5000508@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Tue, 14 Nov 2017 19:30:54 +0100
> From: martin rudalics <rudalics@HIDDEN>
> CC: dgutov@HIDDEN, 29279 <at> debbugs.gnu.org
> 
>  > This would make it hard to request to be the leftmost or rightmost
>  > column, I think.
> 
> most-negative/positive-fixnum maybe?

That's a possibility, but it seems less natural to me.

Anyway, these are small tidbits that are better figured out during
implementation, I think.

>  >> BTW is ‘window-margin-modify’ just for the sake of the line numbers
>  >> codes or which other users would it have?
>  >
>  > Any package whose requirement of the margin width is not constant, but
>  > has to change due to some event.  Even visual-fill-column should need
>  > it, I think.
> 
> What is visual-fill-column?

See 

   http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01171.html

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 14 Nov 2017 22:40:02 +0000
Resent-Message-ID: <handler.29279.B29279.151069918528456 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151069918528456
          (code B ref 29279); Tue, 14 Nov 2017 22:40:02 +0000
Received: (at 29279) by debbugs.gnu.org; 14 Nov 2017 22:39:45 +0000
Received: from localhost ([127.0.0.1]:40735 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEjrt-0007Ou-0y
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 17:39:45 -0500
Received: from mail-wm0-f44.google.com ([74.125.82.44]:40001)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEjrr-0007Oe-Mb
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 17:39:43 -0500
Received: by mail-wm0-f44.google.com with SMTP id b189so17702113wmd.5
 for <29279 <at> debbugs.gnu.org>; Tue, 14 Nov 2017 14:39:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=Esl0MIOA/byimrWHz45K0+d6V7nmobNqPd/wOHpVIvw=;
 b=UHL8xNFDdlbI4oQTrD/eaLkKW843CHRGX4uVC7zhK+ZUqcmpFEDV1GQopJJ0uXIUou
 AgxwVrO7yKTM5uRPp0Lc/1Jk8Z4Vglz7PwQ4xfobNvMkpHWCkwJ9EHBRah3tgC2gdcWN
 uDMg33vUDJPI/gDafTGKCHX884RsXwP4xkrmM6clE1QSDlv5FOaXqe4kcFEc4Q5Wu/1Y
 TKBaKUb7/hETp0XmeX95/h6yGienKcPApNFhnti9fO0d+aMday3HQ9NlzdNt7Is1Ht24
 UhO+425H8P9lzWZFwrEfyxfUFjWUJLMxFTfz9zAaRDrxGr/OljVBpI6Awy2cmSkpc3Tq
 0+Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=Esl0MIOA/byimrWHz45K0+d6V7nmobNqPd/wOHpVIvw=;
 b=aEH25RsJ54ykiGfmx2jGrKXiJ+R30GunUR5MCDQjj9Q9umO0VCfrtWRcH9HuEaXhd+
 bRvBhLCleeVY5veW7YlA9ib0PoJ51upDDl1GygDcH/7icIXfPDHXkQewSrlF4qzZ5Vye
 7ruLWgl3I5SdwfqukOh5JV125G3BSWhfFK9r/Lu2klaTdq6ZKB7ppCDr0EECXBa/pkTe
 TwVIOXEdyLI9OyqdRGWKUGaSAF8f5CqSoXMXINfWB5QEYIHbcbnsl2TTYYl9H1/iw87I
 V+9yt/c/pIVxLjD2HuxgTDZyNBqtbEiEEGTzDDT+oLB6nK/JT59gxuIngjJvZ+SnISB5
 KEoQ==
X-Gm-Message-State: AJaThX4T5dJB+av9oMDluQuWA0Doql47o9COjuF76uyIcdnCAY98nOCf
 TrFOQLrrQe36osFO4xtt/Lk=
X-Google-Smtp-Source: AGs4zMb97wZCkHaZsPALWNzGAINKHPIjsf4cHjC+MbtOUeJUSOsx6gH5Gs70N7CP0m70k3fcwJWFiA==
X-Received: by 10.28.57.11 with SMTP id g11mr7972478wma.92.1510699177654;
 Tue, 14 Nov 2017 14:39:37 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id b206sm815267wme.11.2017.11.14.14.39.35
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 14 Nov 2017 14:39:36 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
Date: Wed, 15 Nov 2017 00:39:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83375glvx4.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/14/17 5:30 PM, Eli Zaretskii wrote:

>> So I'd personally prefer to have all padding on one side.
> 
> But then requests for the rightmost (or leftmost) column will go
> unsatisfied, for apparently no good reason.

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.

Alternatively, the new function will be able to set the padding to 
"justify" as well, but I doubt a lot of users will like it.

>> Doesn't the use of the special area trigger the window configuration
>> changes as well, in similar situations?
> 
> No, and I still hope we can avoid the need to do that.
> tabulated-list-mode came close, but I eventually succeeded in making
> it happy with the other hooks.
>
>> After all, it also changes the accessible window body width, right?
> 
> It depends on your POV.  My POV is that it doesn't, since the window
> dimensions and the dimensions of the text area are unaltered.  At
> least one other person disagreed (vociferously).

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.

If the latter doesn't have to run window-configuration-change-hook, 
maybe the margin changes don't have to either, and "other hooks" will 
suffice as well?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 03:43:02 +0000
Resent-Message-ID: <handler.29279.B29279.151071734023102 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151071734023102
          (code B ref 29279); Wed, 15 Nov 2017 03:43:02 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 03:42:20 +0000
Received: from localhost ([127.0.0.1]:40840 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEoai-00060Y-5L
	for submit <at> debbugs.gnu.org; Tue, 14 Nov 2017 22:42:20 -0500
Received: from eggs.gnu.org ([208.118.235.92]:59741)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eEoag-00060K-Og
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 22:42:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eEoaa-0007mr-FJ
 for 29279 <at> debbugs.gnu.org; Tue, 14 Nov 2017 22:42:13 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47433)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eEoaV-0007iw-Ff; Tue, 14 Nov 2017 22:42:07 -0500
Received: from [176.228.60.248] (port=4423 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eEoaU-0008C4-TH; Tue, 14 Nov 2017 22:42:07 -0500
Date: Wed, 15 Nov 2017 05:42:17 +0200
Message-Id: <83efp0jjhi.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN> (message from
 Dmitry Gutov on Wed, 15 Nov 2017 00:39:34 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Wed, 15 Nov 2017 00:39:34 +0200
> 
> On 11/14/17 5:30 PM, Eli Zaretskii wrote:
> 
> >> So I'd personally prefer to have all padding on one side.
> > 
> > But then requests for the rightmost (or leftmost) column will go
> > unsatisfied, for apparently no good reason.
> 
> 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.  A stretch of white space between the
text and the margin display might not be what the package wants.

> > It depends on your POV.  My POV is that it doesn't, since the window
> > dimensions and the dimensions of the text area are unaltered.  At
> > least one other person disagreed (vociferously).
> 
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 14:24:02 +0000
Resent-Message-ID: <handler.29279.B29279.151075579330304 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151075579330304
          (code B ref 29279); Wed, 15 Nov 2017 14:24:02 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 14:23:13 +0000
Received: from localhost ([127.0.0.1]:41130 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eEyav-0007si-HS
	for submit <at> debbugs.gnu.org; Wed, 15 Nov 2017 09:23:13 -0500
Received: from mail-lf0-f43.google.com ([209.85.215.43]:49342)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eEyau-0007sV-58
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 09:23:12 -0500
Received: by mail-lf0-f43.google.com with SMTP id w21so26389371lfc.6
 for <29279 <at> debbugs.gnu.org>; Wed, 15 Nov 2017 06:23:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=cF6WwxItqHALGs1/qgKkh4s3Sa7qvvv5ekmHV522H4c=;
 b=OcQtFY0baPTMWVQPqgNySJu6QcFHd6xkkb+l6btaiXdvz2+UqyoZhecxX1nYMnnAdW
 wxoNuF65ju9vYGsHeU0DlgwXwallpwmDBIV3gv7mCSTNHDBXiNWQBYHg07cyQF15fvg3
 WOoFH7z+vdZqFoAJA65f3ZYiScSmyKGLosvFmoZll5oXaZ1wvrBxdnlHauJBlAGqIsxC
 3RH4M3KFHIChdxghJwQEhRqGLXwhCrHINRSatKCuUZm58J+M13yBavxMP3MhXVjC1oD/
 rZMCr433JDKI4t48+rgHEW2fZ+vaybMocxZowJ1mH6iuzl1idSu7TNHIpP7hEP9pYnsx
 S/EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=cF6WwxItqHALGs1/qgKkh4s3Sa7qvvv5ekmHV522H4c=;
 b=l5Ch386FwZZ3MUw0jvULEhkOccqeN6lXFWOlMQ2Y4kkBXBx8b2s/jNdggXxnr/vZQa
 DSMUE324kXUE5dAKCe3zZ2mXvB+0mCNfWpadN+8l2fFrSp+eGTl4nH1eOKVfr9BMKmvN
 I3v4k8I5AiwTe/3nREWMUAUGO76FXRhpzraDjtkCBD4qZ3fHtotZ7t9htHwWBSAZbZTC
 BRfUuxWptkZtaMXP98ZQ0mV6dHeaFwuAeayGyCNwEf7rMONyB6P+YSIrbmqJcbRBAxIH
 5cj+Sha/E/dPgPNxItsXatDe75PJP20gkcyzSvxVJi2zQCBHvDCkZh/0PCW8zbYaIBdF
 DDaA==
X-Gm-Message-State: AJaThX6xJuLhYiywDSrAQyLh5rPk+7Gp2ssB2HlAB4kM6X2QYUrKQ0+0
 YZLOmzEaccT3jIOPrJO7wcU=
X-Google-Smtp-Source: AGs4zMbXtvQOH39e0xm3a40/TG2bDB09t+AdlSDpfYoYc61kn4vmS9rNA6JAPXGW89t3YoXjnT/IGQ==
X-Received: by 10.46.88.68 with SMTP id x4mr379951ljd.138.1510755786060;
 Wed, 15 Nov 2017 06:23:06 -0800 (PST)
Received: from [192.168.0.133] (static-nbl2-118.cytanet.com.cy.
 [212.31.107.118])
 by smtp.googlemail.com with ESMTPSA id f21sm4417441lja.25.2017.11.15.06.23.03
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 15 Nov 2017 06:23:04 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
Date: Wed, 15 Nov 2017 16:23:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83efp0jjhi.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

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.

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

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

OK then, what's the practical problem with saying that margins are also 
part of "text-area dimensions"?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 18:01:02 +0000
Resent-Message-ID: <handler.29279.B29279.151076882718509 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151076882718509
          (code B ref 29279); Wed, 15 Nov 2017 18:01:02 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 18:00:27 +0000
Received: from localhost ([127.0.0.1]:42096 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eF1z8-0004oT-QK
	for submit <at> debbugs.gnu.org; Wed, 15 Nov 2017 13:00:27 -0500
Received: from eggs.gnu.org ([208.118.235.92]:58318)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eF1z7-0004oH-CL
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 13:00:25 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eF1yw-00048j-5C
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 13:00:20 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33566)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eF1yp-00042G-LN; Wed, 15 Nov 2017 13:00:07 -0500
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 <eliz@HIDDEN>)
 id 1eF1yn-0002NI-Rr; Wed, 15 Nov 2017 13:00:07 -0500
Date: Wed, 15 Nov 2017 20:00:10 +0200
Message-Id: <83a7znjuc5.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN> (message from
 Dmitry Gutov on Wed, 15 Nov 2017 16:23:01 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 18:51:02 +0000
Resent-Message-ID: <handler.29279.B29279.151077182426913 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151077182426913
          (code B ref 29279); Wed, 15 Nov 2017 18:51:02 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 18:50:24 +0000
Received: from localhost ([127.0.0.1]:42125 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eF2lU-0006zz-LF
	for submit <at> debbugs.gnu.org; Wed, 15 Nov 2017 13:50:24 -0500
Received: from mout.gmx.net ([212.227.17.20]:61782)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1eF2lS-0006yd-Su
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 13:50:23 -0500
Received: from [192.168.1.100] ([46.125.250.53]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lv9lm-1fF9pK0ony-010MHq; Wed, 15
 Nov 2017 19:50:16 +0100
Message-ID: <5A0C8C5D.1070402@HIDDEN>
Date: Wed, 15 Nov 2017 19:50:05 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>	<83375imbaa.fsf@HIDDEN>	<bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <5A0ABD65.1030401@HIDDEN> <83y3n8kgdu.fsf@HIDDEN>
In-Reply-To: <83y3n8kgdu.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:XZgvaVv9bcU+FEcywsdi3k9s8j9ydyLEJiVb4t5Pnf+lTw73IVx
 gezle7A6yFBHsNPpchX4a+vlCKpVWxDcYDFuKXp5X5dmy/VYWjuUdCXdnCUFiMSOLz+KS0a
 BbqbVaNJVwgKZFfUlbUQkPpAIjGeBu57cN+HEBJ0vyHwJGBGAeSOiuIpm1DYF2LhoStLMEk
 HG6YnoLO5MKnOIg8m8G0Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Hd4kp7avosc=:QzbScm3mblR0Ldy3hpg+q1
 feBgVJE/9TQx0mDWht9reQ8R2sfC6Rafm9SSMQi0lpV475O9pBfHdSnL4mivVmjy2xJckdeYu
 v3qwOKVH3VwiAZsSIY6kzEI+biSTcqqr9toO1pFT9AeuMMeXuVEDmpkGR7Rekp62RbqYPJCkT
 2igillGDTdBTKk1rs03neCU5B9VyI7Fj0gJmtSVZbrGHNEH0nfbdzTvkiRYoS/2UXKzFihxrq
 1ofOZgNDRTjek8N2LuXLz3txw2yesO0ayeGQmuc5qPH6z4dn+keoqimGTWRcsLuZxDXGWc8V1
 wpcW2LYy5t3j3UnMdEIg5KpimOwvXvLZBi4nRXTRDq0NI0U/Ghq/emGvgXGsVr2lrL4kcvwzY
 vR+Of6/I4KBID8VjISH/gf6NAoB8Cvr0mBa8xFanIVwKfB34sOYEIjIPiusHAQM+62+5q+gjM
 L5Z50DL9CUgMctxJppGv6ijDWG3cz8PYUrWGUMlKyRlq4KwNM7QrYBizMeDTxC1GH96NjHQ+q
 YEzOj+8eYFxwSFieGt+3Qr7iT/jrhzOeTHVHa/+otyNoSVwh7Vk9Hi4ZTD+V7ESLilWVjWtQ2
 Ojx042F5/v0H50aDZHeT42baOj0EucJxMUAlPwZAJn+NkDTRoae5n6kDYoTzi91355xl9Untb
 qZlD49yy0TjKN5Fv2pA3M1xD7KhtkD/AHM7xnb2+BJ0DSo38+ae5EUVuy4saBdNDJc9WcHa2h
 c7Fi1w9IKO7pI0tQyDnwhIXKN0ehuwmfzULqpknl8OqaIvfz8OJJTsfhNdLvpDc4KSg7/OHBW
 gMmhUVAlCikA3fX4VlX3QvyysX+siHrK4ZFoShAllZSGXcfUO2LjCykSzEBfZJ7a5sxhgu8
X-Spam-Score: -3.5 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.5 (---)

 >>   > Yes.  But using margins from Emacs internals means that the
 >>   > window-parameters which hold the column specs will change behind the
 >>   > back of the Lisp applications, which I'm not sure is a Good Thing.
 >>
 >> I can see no harm in that.
 >
 > It's...unexpected.

Unless we are content with showing only the left part of the left margin
when a window gets too small as we do currently, we might also provide a
solution using "nominal" margin widths which apply when a window is wide
enough, and "realized" margin widths which apply when a window is too
narrow.  For line numbers, the nominal width could be somewhat
stretchable (as for the whiteroom, visual-fill-column cases) while most
others may have it fixed.  Probably, in addition an application may want
to specify that its realized margin width should be reset to zero
whenever the nominal width does not fit (line numbers probably want to
do that) or truncated to what is available.

Note that we earlier did shrink the margins when a window got too small
but did not re-enlarge them when the window was made wide again because
the nominal size was lost.  I eventually dropped that behavior and was
quite surprised that no-one protested.  But if we were to revive such
dynamical adjustment as sketched above, we'd have an unexpected "change
behind the back of the Lisp applications" as well.

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 18:53:01 +0000
Resent-Message-ID: <handler.29279.B29279.151077193128007 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151077193128007
          (code B ref 29279); Wed, 15 Nov 2017 18:53:01 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 18:52:11 +0000
Received: from localhost ([127.0.0.1]:42129 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eF2nD-0007Hd-1K
	for submit <at> debbugs.gnu.org; Wed, 15 Nov 2017 13:52:11 -0500
Received: from mout.gmx.net ([212.227.17.20]:64919)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1eF2nA-0007GG-VU
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 13:52:09 -0500
Received: from [192.168.1.100] ([46.125.250.53]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MLS74-1eFb1O0NuM-000aIr; Wed, 15
 Nov 2017 19:52:00 +0100
Message-ID: <5A0C8CC6.1090203@HIDDEN>
Date: Wed, 15 Nov 2017 19:51:50 +0100
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>	<83375imbaa.fsf@HIDDEN>	<bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>	<83o9o6kp61.fsf@HIDDEN>	<d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>	<83h8tykm99.fsf@HIDDEN>	<aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>	<83375glvx4.fsf@HIDDEN>
 <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
In-Reply-To: <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:st+fU41o/wTLZ+9cgO+DDEztHk0Oe6QNQrXQL8epbXK+PS7e7DM
 zOBr4w5Lu/e+6FPaRtodWdBl5eArbHeijq4z7PYMkAm4KmH0EAHWBTbJdPRBRfucqGYb0H9
 7CZ2TdbfuntTocY/nrYFhEKCq2sp6DDyRu+tbk/1W/Z3s6c5KOzVNa71t0QlIeDM/RQOis0
 K9YLn2z6Ys6ZsMZFW/K/Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:zEPS45fCDs0=:2B37TUP2Cc/nXoHvHqmpgI
 Qj8LRLux40gxsu/0Brf2M7tjdug+2ye+Zz6C5iHqKLJVzuBM9T4zk1KxhlQ1PFrXWpZV2qCmb
 Lf+nV2/TMpR4VdKPW3T9RRpiMLP+zgRcHmGDUFbKLfjOAKWhD1ooiKt5Vqpc7y5mRoFN1JpKY
 HG7Hv1erdsQdDS1MzldrSWHjGtYtDSUXCHEyOtsyoAv7EwgewIUVikGywj0Wg/HOzbqRNl9TQ
 NCt+DG1k7oqWhw2fARPYkv81v03VqqUbzziHCeJIug+t1SGsur2SBXvAeq9O/XepiJy+XMvQH
 pWncZmmJijX7mvHWyDWwt1VELqsnjwFSCqfgj0WGQxoC3G29r7nWHok5SpV4IDPhwlBHr98SU
 qHZEUSNhEdT1tZ1kpLgdv24JWdQ+55DCilueQ+c/F5ahTwVymEXYTbfTuCFCr9EWcKO/amQii
 gao5MGo20L9926IR4CBqVRNJDgYGAB0hjTpaKoDMQzVtasHvDL4ewMlWF0TcUnHwUmmmuVQ+J
 MU7G6dYIASfSMTI3dXNow+TNHFXwGQZ03X48dEp5GeenwtBSG/Enl6Ot07VlTbhpOqx1ubs9n
 Xq2bzsJ2Gy6L2cHCJTOT+KV5+LHKlqpbr1Jm6DGaY2zx/TvH+WCfKMDn1BwNS1S6/6YH6YQwx
 fMFn5rI2fSSHKkn1KpUQ1Rt9lt5aztFn9w38HY+0jhzMqLCzIheDlnTMkBAP2654u8ZFT06eG
 05nuK0/zrlAN+I2AB1EtZLMG3b7vTZrHBfiNyxMS8xu5l6O4uhTgp9maSmap5LId86+cI8YOe
 0yYwMtuUbuX+L+/XGSnbiB+bV3+/OyLi96rgCqjMYhhnfrVGGmT1v0wjqxRm7248m/h0eAT
X-Spam-Score: -3.5 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.5 (---)

 > If the latter doesn't have to run window-configuration-change-hook,
 > maybe the margin changes don't have to either, and "other hooks" will
 > suffice as well?

I intend to drop most calls of 'window-configuration-change-hook' and
replace them by 'window-size-change-functions' if all they do is to
change the sizes of windows only.  Maybe we should then change the
semantics of the latter: Call it when just the window body size changes
too.  Provide a 'window-body-pixel-width-before-size-change' function
which could be used in connection with 'window-body-height'.

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 20:04:01 +0000
Resent-Message-ID: <handler.29279.B29279.15107762277479 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN, dgutov@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15107762277479
          (code B ref 29279); Wed, 15 Nov 2017 20:04:01 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 20:03:47 +0000
Received: from localhost ([127.0.0.1]:42166 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eF3uU-0001wZ-Uf
	for submit <at> debbugs.gnu.org; Wed, 15 Nov 2017 15:03:47 -0500
Received: from eggs.gnu.org ([208.118.235.92]:54357)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eF3uT-0001wN-HC
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 15:03:45 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eF3uN-0007Qj-MI
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 15:03:40 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35837)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eF3uH-0007La-Uk; Wed, 15 Nov 2017 15:03:33 -0500
Received: from [176.228.60.248] (port=1178 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eF3uG-00041r-Ht; Wed, 15 Nov 2017 15:03:33 -0500
Date: Wed, 15 Nov 2017 22:03:39 +0200
Message-Id: <834lpvjomc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <5A0C8CC6.1090203@HIDDEN> (message from martin rudalics on Wed,
 15 Nov 2017 19:51:50 +0100)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>	<83375imbaa.fsf@HIDDEN>	<bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>	<83o9o6kp61.fsf@HIDDEN>	<d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>	<83h8tykm99.fsf@HIDDEN>	<aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>	<83375glvx4.fsf@HIDDEN>
 <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN> <5A0C8CC6.1090203@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Wed, 15 Nov 2017 19:51:50 +0100
> From: martin rudalics <rudalics@HIDDEN>
> CC: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> 
> I intend to drop most calls of 'window-configuration-change-hook' and
> replace them by 'window-size-change-functions' if all they do is to
> change the sizes of windows only.

Regardless of the reasons for this change, it doesn't affect the issue
at hand: calling window-size-change-functions from inside redisplay
has the same issues as calling window-configuration-change-hook.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 21:10:01 +0000
Resent-Message-ID: <handler.29279.B29279.151078017213434 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, martin rudalics <rudalics@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151078017213434
          (code B ref 29279); Wed, 15 Nov 2017 21:10:01 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 21:09:32 +0000
Received: from localhost ([127.0.0.1]:42206 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eF4w8-0003Uc-5x
	for submit <at> debbugs.gnu.org; Wed, 15 Nov 2017 16:09:32 -0500
Received: from mail-wm0-f50.google.com ([74.125.82.50]:32929)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eF4w6-0003UO-9g
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 16:09:30 -0500
Received: by mail-wm0-f50.google.com with SMTP id r68so23201893wmr.0
 for <29279 <at> debbugs.gnu.org>; Wed, 15 Nov 2017 13:09:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=vZA0IbeyqLsCVx/c2bsxs1jHpXAykvQCfMkrLGooYOw=;
 b=gxHuhGnaZwkrE4mFOr2kPZ2rw0VglZWk+aZ7KcWOcf7iBSxPdfjLt+7bvSDDFJCkv6
 nvpkT+HSfceyhDqPYOa4PcTs7bsOy859AbtRMDj1Urg43opsTegKvcUSE9n3YXsikIxY
 e/SYZL8zv2uaHBKp7j2oUk8EUzxF95mHHkXDUNqASDnAwr3ypxA5ZuWap/kGA7F97MGP
 yaWrhu1wgkvZeDRtYQ89A7JoFoeSh5QRUXL8SqTt6B7lQb8tQx6janOHwCYnc/Vv4iuK
 RIKqUrqm5FKTncUxp0JfF5TbNC36gQ6YL9dgftb8gMBVEoXCrMadxX1un7cGWCZJW0YZ
 GBXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=vZA0IbeyqLsCVx/c2bsxs1jHpXAykvQCfMkrLGooYOw=;
 b=qLAySGkYdNmUYF5CHEqNfgxf6Vz3dIkudR6jAWO4++3j9giCUtaaa4HyncRABsN2E9
 WOp5v8dJ4eZYyt+pI7wugU0HoPn4O57PFv3QR+Oo+648iOjpazXNes1WNIJ9HjJNSt9R
 kplXUtKH8vGhNsN693vIc1x/HH3GCZggyZfs+m7qzURfr3pNQIWTKILoxC5bg6S0MRca
 qPS/Jxuaj8bS81NDe59ZPkArUC/HGfTlxnAja9mNkZW0wOidS7Y20D3zkNRs+EK08rPd
 SH8DRRrjWdxkqlpdRXumoM6P8u2S0uWIAMmLUIZNgjlKmz8DbawCiP6/5CDP/1vzFm3I
 8NSg==
X-Gm-Message-State: AJaThX7xA7wOd4gLbYus9nytFoC6kphTcZwROgHGapVprHxMXwSOKML9
 GmoPG75Hc20eDKfa0cWHG6k=
X-Google-Smtp-Source: AGs4zMamBPs45CiJNKDvmxv0F5vLNADHgNgJSbp6TZM6vH6m+cvwg1Opr2XoNJ//sXCpqLc39tnG9g==
X-Received: by 10.80.213.90 with SMTP id f26mr3976886edj.225.1510780164534;
 Wed, 15 Nov 2017 13:09:24 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id x49sm12295784edb.76.2017.11.15.13.09.22
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 15 Nov 2017 13:09:23 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <5A0C8CC6.1090203@HIDDEN> <834lpvjomc.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <0e8009ab-d5b1-f996-0ae1-bd4680e5e81b@HIDDEN>
Date: Wed, 15 Nov 2017 23:09:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <834lpvjomc.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/15/17 10:03 PM, Eli Zaretskii wrote:

>> I intend to drop most calls of 'window-configuration-change-hook' and
>> replace them by 'window-size-change-functions' if all they do is to
>> change the sizes of windows only.
> 
> Regardless of the reasons for this change, it doesn't affect the issue
> at hand: calling window-size-change-functions from inside redisplay
> has the same issues as calling window-configuration-change-hook.

But margin size changes won't have to call window-size-change-functions, 
right? Then it might be possible to move all the heavy consumers to this 
hook, leaving window-configuration-change-hook relatively lightweight 
(right)?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Nov 2017 21:50:02 +0000
Resent-Message-ID: <handler.29279.B29279.151078255517461 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151078255517461
          (code B ref 29279); Wed, 15 Nov 2017 21:50:02 +0000
Received: (at 29279) by debbugs.gnu.org; 15 Nov 2017 21:49:15 +0000
Received: from localhost ([127.0.0.1]:42223 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eF5YZ-0004XZ-GH
	for submit <at> debbugs.gnu.org; Wed, 15 Nov 2017 16:49:15 -0500
Received: from mail-wm0-f51.google.com ([74.125.82.51]:43490)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eF5YY-0004XN-1B
 for 29279 <at> debbugs.gnu.org; Wed, 15 Nov 2017 16:49:14 -0500
Received: by mail-wm0-f51.google.com with SMTP id g141so5806154wmg.2
 for <29279 <at> debbugs.gnu.org>; Wed, 15 Nov 2017 13:49:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=a/TL/X7lp7HMMu4CT5icnDanpTz8RIeVQAtcu2qS5xc=;
 b=LOZPKdg+vZ3JaRRXbyTx9+CUCbuF3rdKgxC68DjQSZLCS+A9xzycBaN02fMaxUXawR
 aY5ZY/Cn2OnAIGLg3URuaa++rhndYwwhlGL2VGelQt2rMqrL20qOQHBArmRvZYXvmHli
 /C5IivWAZ5R2gybEmRt5gN9n7p2qN0CDGeBnaD8ATL82PEFl25Qge75TV+B6IugBKtK9
 IpCObBqKNEPQd1bfh4nBDbKn+szFCTcwptJHFi3u8Xx5mgfP6PMgLEptmO5uBpj+ey4f
 PNOAXjwOwbkrbVhA9hVbRE1J5XlWt4q2CEG5Bm1I9W1BYrm4walcmOraEfMcrrBF1Mv/
 sRfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=a/TL/X7lp7HMMu4CT5icnDanpTz8RIeVQAtcu2qS5xc=;
 b=ick6dBvcXg0VaYAU4NQTEqq8H8My95jygbi5SZOVDfmk/2O7a3ybYCWvKktvAHU5ku
 y2zTOB+BFgXUCdTPaxL4HlnAZaomVsCG6ueVH6zDa6xmRbcjZZAqOIljdQmenRbB2qsn
 Z+3em1I7vTuIKWh10FudQDMs206Z82U84Dek5c/E3yn6AU31JPWEexdgnaMulz4clyP2
 9NJPpIynXQzi+4DBDBhu0rWvaCDeTXg+O0qBH9kUAOFBbhiQzFpO2RLGWdU0a4ydrVFN
 p1QCHTjYkbx0anwpHu10dSfE1/WHVfiPtjL58hsxht5GbcGvv0Zb9MqipbuLRfYaIAOI
 0cBQ==
X-Gm-Message-State: AJaThX4zv3AWMFgUlxbOGuwN2jEDuH+cBJ2bX7eiJBZPTtxj44D7Xii5
 g/fEwt8HIHnS0IdhZmdglNk=
X-Google-Smtp-Source: AGs4zMZWA5w4ic3vKRn7Rp8Qox04nrWhxxHDR53tXY4E7MaDs1mIXSrePNjtLb2+v7ST4VJ5C65I5Q==
X-Received: by 10.80.213.90 with SMTP id f26mr4077661edj.225.1510782548196;
 Wed, 15 Nov 2017 13:49:08 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id x49sm12375793edb.76.2017.11.15.13.49.06
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 15 Nov 2017 13:49:07 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
 <83a7znjuc5.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@HIDDEN>
Date: Wed, 15 Nov 2017 23:49:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <83a7znjuc5.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/15/17 8:00 PM, Eli Zaretskii wrote:

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

Yeah, OK.

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

Sounds straightforward to me. Since we know the sizes of all the columns 
in advance, we can just substract them from the target total width, and 
pad with the resulting number of spaces.

Having extra padding between columns (your original idea) would be more 
complex to implement, IIUC.

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

Still. To the user, the line numbers column is more like an extra margin 
than anything else.

Further, even though we have a separate accessor for its width 
(line-number-display-width), if a package depends on it and needs to 
draw something based on its value, it should want to be notified when 
there is a change (*). window-configuration-change-hook seems natural. 
Unless we have a separate hook for that?

>> 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?

Not necessarily. Can't you save the necessary data to a variable, finish 
redisplay, and then run the hook (if the data says so)?

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

*resigned shrug*

> So I'd like to avoid this if possible.

It's somewhat hypothetical, but I'd like to refer to (*) above. That is, 
somebody will probably ask for that anyway, sooner or later.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 16 Nov 2017 15:40:02 +0000
Resent-Message-ID: <handler.29279.B29279.15108467849351 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, rudalics@HIDDEN, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15108467849351
          (code B ref 29279); Thu, 16 Nov 2017 15:40:02 +0000
Received: (at 29279) by debbugs.gnu.org; 16 Nov 2017 15:39:44 +0000
Received: from localhost ([127.0.0.1]:43729 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eFMGV-0002Ql-QV
	for submit <at> debbugs.gnu.org; Thu, 16 Nov 2017 10:39:43 -0500
Received: from eggs.gnu.org ([208.118.235.92]:49595)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eFMGU-0002QZ-LT
 for 29279 <at> debbugs.gnu.org; Thu, 16 Nov 2017 10:39:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eFMGO-0007j3-Rl
 for 29279 <at> debbugs.gnu.org; Thu, 16 Nov 2017 10:39:37 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53782)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eFMGM-0007cj-BF; Thu, 16 Nov 2017 10:39:34 -0500
Received: from [176.228.60.248] (port=1843 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eFMGL-0002MU-OJ; Thu, 16 Nov 2017 10:39:34 -0500
Date: Thu, 16 Nov 2017 17:39:48 +0200
Message-Id: <83tvxui663.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <0e8009ab-d5b1-f996-0ae1-bd4680e5e81b@HIDDEN> (message from
 Dmitry Gutov on Wed, 15 Nov 2017 23:09:21 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <5A0C8CC6.1090203@HIDDEN> <834lpvjomc.fsf@HIDDEN>
 <0e8009ab-d5b1-f996-0ae1-bd4680e5e81b@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Wed, 15 Nov 2017 23:09:21 +0200
> 
> On 11/15/17 10:03 PM, Eli Zaretskii wrote:
> 
> >> I intend to drop most calls of 'window-configuration-change-hook' and
> >> replace them by 'window-size-change-functions' if all they do is to
> >> change the sizes of windows only.
> > 
> > Regardless of the reasons for this change, it doesn't affect the issue
> > at hand: calling window-size-change-functions from inside redisplay
> > has the same issues as calling window-configuration-change-hook.
> 
> But margin size changes won't have to call window-size-change-functions, 
> right? Then it might be possible to move all the heavy consumers to this 
> hook, leaving window-configuration-change-hook relatively lightweight 
> (right)?

For some value of "lightweight".  The ones that I think about would
want to change window dimensions, e.g. by enlarging or shrinking the
margins, and that is not "lightweight", as I explained up-thread.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 16 Nov 2017 15:51:02 +0000
Resent-Message-ID: <handler.29279.B29279.151084743210351 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151084743210351
          (code B ref 29279); Thu, 16 Nov 2017 15:51:02 +0000
Received: (at 29279) by debbugs.gnu.org; 16 Nov 2017 15:50:32 +0000
Received: from localhost ([127.0.0.1]:43738 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eFMQy-0002gs-2q
	for submit <at> debbugs.gnu.org; Thu, 16 Nov 2017 10:50:32 -0500
Received: from eggs.gnu.org ([208.118.235.92]:52390)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eFMQw-0002gf-7k
 for 29279 <at> debbugs.gnu.org; Thu, 16 Nov 2017 10:50:30 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eFMQp-0001SD-Q1
 for 29279 <at> debbugs.gnu.org; Thu, 16 Nov 2017 10:50:24 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53950)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eFMQj-0001NE-DB; Thu, 16 Nov 2017 10:50:17 -0500
Received: from [176.228.60.248] (port=1956 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eFMQi-000497-R2; Thu, 16 Nov 2017 10:50:17 -0500
Date: Thu, 16 Nov 2017 17:50:31 +0200
Message-Id: <83shdei5o8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@HIDDEN> (message from
 Dmitry Gutov on Wed, 15 Nov 2017 23:49:05 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
 <83a7znjuc5.fsf@HIDDEN> <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Wed, 15 Nov 2017 23:49:05 +0200
> 
> >> 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.
> 
> Sounds straightforward to me. Since we know the sizes of all the columns 
> in advance, we can just substract them from the target total width, and 
> pad with the resulting number of spaces.

Maybe, but IME things are rarely so easy.

> Further, even though we have a separate accessor for its width 
> (line-number-display-width), if a package depends on it and needs to 
> draw something based on its value, it should want to be notified when 
> there is a change (*). window-configuration-change-hook seems natural. 
> Unless we have a separate hook for that?

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.

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

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.  So we gain nothing by making the display engine call
the hook.

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 18 Nov 2017 23:47:01 +0000
Resent-Message-ID: <handler.29279.B29279.151104879924626 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151104879924626
          (code B ref 29279); Sat, 18 Nov 2017 23:47:01 +0000
Received: (at 29279) by debbugs.gnu.org; 18 Nov 2017 23:46:39 +0000
Received: from localhost ([127.0.0.1]:46626 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eGCop-0006P7-03
	for submit <at> debbugs.gnu.org; Sat, 18 Nov 2017 18:46:39 -0500
Received: from mail-wm0-f42.google.com ([74.125.82.42]:33232)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eGCom-0006Of-UG
 for 29279 <at> debbugs.gnu.org; Sat, 18 Nov 2017 18:46:37 -0500
Received: by mail-wm0-f42.google.com with SMTP id g130so2212519wme.0
 for <29279 <at> debbugs.gnu.org>; Sat, 18 Nov 2017 15:46:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=ZEydIakB0JTjJZxh1AP5KlNxE6K7t3uGEgKFpYBU+Lc=;
 b=nU/id3WON1HE89p3EhnDbxE4PG0AUo2AuhOPrZZyyM9OfUhuqN6kfU1zcM+Nv7f5dq
 ddStFsYWLk6mveVVV3q5C+k58vE6zQdmgljUzqdeSc/GByOJZCKfzcULcu6p0renE6pP
 WbS1iirCcgCPG6X8RfoX3awd2T8AnzkBhTtaAnUOAdPoBcUoujycKFZeCtuzqN4d1jMX
 Ue511+ljeh9ij44fat2jwyngR5lv6TrzriIFnovnXUktEn91odXQLhXaWz9YFcjdwUiH
 8FVpu0Rlub6rp+P89WpyiA86rQ5WGS+OHAsldfsa0Jsdv0AY7AQZoROyONLPyjGIPa5W
 4pFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=ZEydIakB0JTjJZxh1AP5KlNxE6K7t3uGEgKFpYBU+Lc=;
 b=su+D61oWI1FfNcUfPzoT00ZHVvD9uOXTkoRZeX1iBdSQZV7A0ogBcmflKKvpSruVcw
 aSrJ7/jHDqLJnfeO1SWz43DgFVrximJXB3kB/zwLujL5njAIIbO85ZQiDiLeEkMDZcmI
 r+rGoFuWTypihzH4dY6srTzyJcfgzIm0DAd686klylE8gq5tDycP4JSmld/hQoo6q5sB
 9WrkPrV/Fb0GCzpPW9zIhB1JNrbUqfXx7jCj1pGqe+8dxwyeQP4fE2sYQQjnoc1W0luz
 MrjfEYYyGCEHm2Ww4r4zxWHhApAQYF2Ae7bWRWz/abbjlTjxW21yDPpGN1OFss8ivpb3
 QOog==
X-Gm-Message-State: AJaThX5M2OwJd2mcCPGTFIXOqrHEAhMkSyM5QV9VWVRGEr7gKska1XpQ
 p36qRijuHzzzVxOa1Vv8Kwk=
X-Google-Smtp-Source: AGs4zMZFrEtlHMDtwwljR/Js+0xokHHvjvAB+W3dd8IilIF2+PnGUZMNOak0edk4m8tbTexALhc0mw==
X-Received: by 10.28.120.19 with SMTP id t19mr7286207wmc.64.1511048791322;
 Sat, 18 Nov 2017 15:46:31 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id c22sm8318709wme.2.2017.11.18.15.46.29
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 18 Nov 2017 15:46:30 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <5A0C8CC6.1090203@HIDDEN> <834lpvjomc.fsf@HIDDEN>
 <0e8009ab-d5b1-f996-0ae1-bd4680e5e81b@HIDDEN> <83tvxui663.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <22787e15-080b-0309-d27e-f5ff937cee9e@HIDDEN>
Date: Sun, 19 Nov 2017 01:46:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
 Thunderbird/57.0
MIME-Version: 1.0
In-Reply-To: <83tvxui663.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/16/17 5:39 PM, Eli Zaretskii wrote:

>>> Regardless of the reasons for this change, it doesn't affect the issue
>>> at hand: calling window-size-change-functions from inside redisplay
>>> has the same issues as calling window-configuration-change-hook.

Could you clarify what is the exact issue, BTW?

>> But margin size changes won't have to call window-size-change-functions,
>> right? Then it might be possible to move all the heavy consumers to this
>> hook, leaving window-configuration-change-hook relatively lightweight
>> (right)?
> 
> For some value of "lightweight".  The ones that I think about would
> want to change window dimensions, e.g. by enlarging or shrinking the
> margins, and that is not "lightweight", as I explained up-thread.

Are window-size-change-functions really supposed to be called when only 
the margin size has changed, but not the window's outer dimensions?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 18 Nov 2017 23:56:02 +0000
Resent-Message-ID: <handler.29279.B29279.151104933325455 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151104933325455
          (code B ref 29279); Sat, 18 Nov 2017 23:56:02 +0000
Received: (at 29279) by debbugs.gnu.org; 18 Nov 2017 23:55:33 +0000
Received: from localhost ([127.0.0.1]:46630 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eGCxQ-0006cU-SN
	for submit <at> debbugs.gnu.org; Sat, 18 Nov 2017 18:55:33 -0500
Received: from mail-wm0-f48.google.com ([74.125.82.48]:40503)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eGCxP-0006cI-3Z
 for 29279 <at> debbugs.gnu.org; Sat, 18 Nov 2017 18:55:31 -0500
Received: by mail-wm0-f48.google.com with SMTP id b189so12380316wmd.5
 for <29279 <at> debbugs.gnu.org>; Sat, 18 Nov 2017 15:55:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=Bao8NrGov917UoK57AFbSsA8ERJXirwNM9Z0f79mjqs=;
 b=LZnQks8QEEFletrNjS6AvH+yGE1XjIk5BWShaSlwZELPrIYjRbjYqSXmPx4fenRJko
 huYlj6fyvc8zBMnwJi7njVwaa1jDVHytIwdS2ILJ5dQOAvxl/Jvw7PBjzudXgUmRFB6S
 /+7F+lxdR6ydfWL4DTOgajxwJyT9b66miQ1fTqb+x7M0TZvPFmEsz1rOPPaVGpqIJOCs
 SzArmcUy2j+yH5C7FLTkz5arwmdixsahk3+5WqmySKtYx304i3KhO85+oGNDmqfrPrlA
 Nam8Rib8M2Fc3iVIw8XstvgYDTnMAMqSC/PJIUUAxsRLHdTBwd58ZZVcofKgKMq0w4fP
 g7Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=Bao8NrGov917UoK57AFbSsA8ERJXirwNM9Z0f79mjqs=;
 b=X61j4v285lfoElFENbWZW9meqmNAk29jN85pRmuArPTwq7f/Yom8rARGtk58UY9F7e
 TbY/+VbSXXTZGQelEoTcgN0l/+sYfrMjOkQdE/07iqHupbKXGYeb1r60TUMALhMtgVei
 8B+rfqmy7cc4/+Y/S7kiDNbOLhQPvAC9LwYlQN0vBFBnbf9Qktn3OnIIuszd5wfLCZnv
 sa1bAnvsUwLBMqOzRtDdjdD2nkYb2H7Qkf9ekV/XP4JD+GInOe8iC+xq5FvDWzF+8HQp
 ie7dSAyzfGChz5LRYlWozb2fsEXh4Xjwu7Co3OT9IZi3vHBTkTe8XJnBHJoHu29ALOq6
 tmHw==
X-Gm-Message-State: AJaThX7hPelxKw+RBpGouCd0iucPt450uverGdOwBZNdhqPVGG+cVRFC
 uBlLqy4e/mVvnVIL+Th4mgk=
X-Google-Smtp-Source: AGs4zMYRuVn/N6FG6GcE7aGygJ/550xO76mDRcIJ57KXkHvyqgu1qJ3zCPemm5YgEsb0kB/9CRbteA==
X-Received: by 10.28.136.15 with SMTP id k15mr7449244wmd.147.1511049325380;
 Sat, 18 Nov 2017 15:55:25 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id p79sm5869326wmf.43.2017.11.18.15.55.24
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 18 Nov 2017 15:55:24 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
 <83a7znjuc5.fsf@HIDDEN> <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@HIDDEN>
 <83shdei5o8.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <463d412b-6a5d-eda5-d882-b4044d4f417d@HIDDEN>
Date: Sun, 19 Nov 2017 01:55:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
 Thunderbird/57.0
MIME-Version: 1.0
In-Reply-To: <83shdei5o8.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On 11/16/17 5:50 PM, Eli Zaretskii wrote:

>> Sounds straightforward to me. Since we know the sizes of all the columns
>> in advance, we can just substract them from the target total width, and
>> pad with the resulting number of spaces.
> 
> Maybe, but IME things are rarely so easy.

In that case, I think we've made sure they are easy (by requiring all 
columns' widths to be known in advance).

>> Further, even though we have a separate accessor for its width
>> (line-number-display-width), if a package depends on it and needs to
>> draw something based on its value, it should want to be notified when
>> there is a change (*). window-configuration-change-hook seems natural.
>> Unless we have a separate hook for that?
> 
> 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.

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

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.

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

>> 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?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Joost Kremers <joostkremers@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Nov 2017 00:48:01 +0000
Resent-Message-ID: <handler.29279.B29279.151105245529961 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151105245529961
          (code B ref 29279); Sun, 19 Nov 2017 00:48:01 +0000
Received: (at 29279) by debbugs.gnu.org; 19 Nov 2017 00:47:35 +0000
Received: from localhost ([127.0.0.1]:46655 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eGDln-0007nA-AY
	for submit <at> debbugs.gnu.org; Sat, 18 Nov 2017 19:47:35 -0500
Received: from out4-smtp.messagingengine.com ([66.111.4.28]:56017)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joostkremers@HIDDEN>) id 1eGDlm-0007n3-3O
 for 29279 <at> debbugs.gnu.org; Sat, 18 Nov 2017 19:47:34 -0500
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
 by mailout.nyi.internal (Postfix) with ESMTP id 8510B2090D;
 Sat, 18 Nov 2017 19:47:33 -0500 (EST)
Received: from frontend2 ([10.202.2.161])
 by compute5.internal (MEProxy); Sat, 18 Nov 2017 19:47:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h=
 cc:content-type:date:from:in-reply-to:message-id:mime-version
 :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm1; bh=MG2EzwwSG7V9JulJ4L0nTKwUVmzx/zPUZvo/TB+A41g=; b=QvgzvI5a
 +KeqlpvaG8YOf3oUvmU0HI310O2pu8bc4JV+GjIPguEhj1UsoPCpF5kQEjHd/1Us
 0PduSMzk1bjrFr3gDcluhIgqqEvJ0cVQRDWVt9Y76yhHLF+H5PnV1hGovx+nYSyj
 i/mhZZ89E5y9+OJptPBPMf6FBz1KdW08x++S792WSUEl5rSBblCwEZX/xCahtZjf
 s8tKH1GPc8YV6NzMXCIIWTd8xgiKD7zFEGf46VIcaxc1M7ec0v+wlx8DM7voBaNe
 PYIg6pkQuJAYMo6pKjLNIMaUis81UAjE1jIozGqrjhx0NfW74MAm/GYhND9dIzvo
 L7HpeU3y2D4+Vg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-sender
 :x-me-sender:x-sasl-enc; s=fm1; bh=MG2EzwwSG7V9JulJ4L0nTKwUVmzx/
 zPUZvo/TB+A41g=; b=rv4jZ+EgHu8E/DbUQkUgGlffkA/IvXtz2eNU3P0oq7NKP
 gszxhsVAZ2IiIUPaaBC4yaq3FciOmi96R+RreaUJZByvQjFQ7MhO2gNLSdSe2UQN
 86rguHu5StcG+uyPR9pg0pxK6rRm4Bc1Rpk9HKwiGRldRT/s0q+mMxsJ8TgvIGqK
 kV75UHqs+349QF+iAn4njMqL54pzI4oQM1+BObUV7u/fTJmPyGTiCXwd10Ulksgf
 YkhuFxpGLGW8HN6YsoNuGiLUTnXDDvwxljnSCF06225TifrPNLuZHfTlW40bj2PL
 7MNt6UjMT6qo8cgH0zZ1amZtD4pwJ/l1G8lB1IdlQ==
X-ME-Sender: <xms:pdQQWspsLl97mykCql2mocJnXEBtC294Cp7hSur1cVyJj4sr1vlNJQ>
Received: from IdeaPad.fastmail.com (ip5f5acb54.dynamic.kabel-deutschland.de
 [95.90.203.84])
 by mail.messagingengine.com (Postfix) with ESMTPA id CF286244A1;
 Sat, 18 Nov 2017 19:47:32 -0500 (EST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
User-agent: mu4e 1.0-alpha0; emacs 25.3.50.1
From: Joost Kremers <joostkremers@HIDDEN>
In-reply-to: <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
Date: Sun, 19 Nov 2017 01:47:30 +0100
Message-ID: <87shdbnlgd.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)


On Mon, Nov 13 2017, Dmitry Gutov wrote:
> On 11/13/17 9:32 PM, Eli Zaretskii wrote:
>>> I imagine workroom-mode might have a idea where they want the 
>>> padding to
>>> end up (to the left or to the right of all columns). So 
>>> instead of
>>> co-opting the ORDINAL argument to mean "cols will  total cols"
>>
>> We need to study the needs of potential users, no doubt, before
>> finalizing the API.
>
> Inviting Joost into the discussion.

Apologies for replying so late, I've been quite busy. I must also 
admit that even though I've been going over the thread, I'm not 
entirely sure what it is you were hoping to find out by inviting 
me into the discussion.

My personal itch prompting me to write writeroom-mode was wanting 
to get rid of any and all on-screen distractions while writing. So 
I want a full-screen Emacs frame (so none of the window manager's 
notification areas, panels, task bars etc. are visible) with only 
a single window displaying the buffer I'm working on, with the 
text centred on the screen, because modern monitors are too wide 
to use the entire width when writing texts.

So if I understand correctly what you're talking about, I don't 
really care whether the margins are padded on the right or the 
left, because I have nothing in the margins, so I wouldn't be able 
to tell.

I know from user feedback that people do use writeroom-mode with 
e.g., (n)linum-mode, or other packages that display stuff in the 
margins. Among them, some want whatever is being displayed in the 
margins to be close to the text, while other want it at the edge 
of the screen.

So, *if* I'm understanding the issue correctly, it would be best 
if the padding side were user-configurable. If that's not an 
option, either side will do, because there doesn't seem to be any 
clear preference either way.

HTH



-- 
Joost Kremers
Life has its moments

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Nov 2017 09:22:01 +0000
Resent-Message-ID: <handler.29279.B29279.151108326818570 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Joost Kremers <joostkremers@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.151108326818570
          (code B ref 29279); Sun, 19 Nov 2017 09:22:01 +0000
Received: (at 29279) by debbugs.gnu.org; 19 Nov 2017 09:21:08 +0000
Received: from localhost ([127.0.0.1]:46790 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eGLml-0004pR-4d
	for submit <at> debbugs.gnu.org; Sun, 19 Nov 2017 04:21:07 -0500
Received: from mail-wm0-f44.google.com ([74.125.82.44]:44978)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eGLmj-0004od-F2
 for 29279 <at> debbugs.gnu.org; Sun, 19 Nov 2017 04:21:05 -0500
Received: by mail-wm0-f44.google.com with SMTP id r68so13537334wmr.3
 for <29279 <at> debbugs.gnu.org>; Sun, 19 Nov 2017 01:21:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=dGGj0HKH8Pc1I8YNFjaCcJooZ0jn2CK6Ci9hlIYm9ZQ=;
 b=AQxV6cbyvos8WXKfq395z3EO228IZDwbM0lzjkLxhlTLTWQ1NSJf0wi3PLV2cgq6yD
 t2uShgbLMWpwgdzC6VEWBJXonEnf9cN2ylZQbJNr+c1kUwrAEHTytufJlIxCse+lLt8U
 cdNleu6/2Amicv79LbRmz2+sCN7+1ExO2jvZ1M1OpbDaswA5BR4t2PmiXgipUPL1u3bD
 T54Qtm5cBJalLkK/3IGlVSzo/gjcZdC78LuK2J2BEpz3P7WuCLG8t+Qwx/jqi03B3bF8
 kEk3ycsvE+2WZ+Nps1x4fQD90XklZ/QRFEFLRk6mJF+eiqa0SAQQoRpWTuhP5GGbJn6F
 b4Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=dGGj0HKH8Pc1I8YNFjaCcJooZ0jn2CK6Ci9hlIYm9ZQ=;
 b=AqQOhjeuOyvfNK3JVP1HYh4BawSRb/LLVgJ07XKmuXE97FTjRDjku4YIfWzQY6gTfH
 Ax3oyEHyBRfyc7O8BBCnaYcedUBJwFYeVY3olPu8lFhVyR1TqKzKcwIR09UOg0WN8UYa
 s913MX60vILDDv96hxvq69VFxC0Inpetx3KbSQsYZO1+HWz4arCDuPt+62qD0OTa/PT4
 jgVCTaN5igEid1MZSMX6m8vdOJatBuLeNBTr5Y6grubnH8EW0cszoO1mgelTto/H/GvL
 SDCCmWt/Gqga+7VHYI9VUfPtUbkkmLY3AKUex5YZ+fjioXcMPc1++fiBuhKuO1DW1SFm
 U0Ow==
X-Gm-Message-State: AJaThX6CgMU7ncKu6Fn/+tcQM3BlKIrFRRDLOGbCrTrqTUQ6zfXH01nF
 3EKUVuaQ2VIzOyGOxgc5tk+f6DZC
X-Google-Smtp-Source: AGs4zMbiByvaJ5P08+a5VhMytEX5FXOE37YVqPzC+qgc+cofZnnW08/tjaZQSCX1KbqUCNMxLDDtEw==
X-Received: by 10.80.204.152 with SMTP id q24mr14887770edi.108.1511083259311; 
 Sun, 19 Nov 2017 01:20:59 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id x17sm2177603edx.9.2017.11.19.01.20.57
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Sun, 19 Nov 2017 01:20:58 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <87shdbnlgd.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <f08012f3-673e-1d8f-67f9-d4232582faa7@HIDDEN>
Date: Sun, 19 Nov 2017 11:20:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
 Thunderbird/57.0
MIME-Version: 1.0
In-Reply-To: <87shdbnlgd.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

Hi Joost!

On 11/19/17 2:47 AM, Joost Kremers wrote:

> So if I understand correctly what you're talking about, I don't really 
> care whether the margins are padded on the right or the left, because I 
> have nothing in the margins, so I wouldn't be able to tell.
> 
> I know from user feedback that people do use writeroom-mode with e.g., 
> (n)linum-mode, or other packages that display stuff in the margins. 
> Among them, some want whatever is being displayed in the margins to be 
> close to the text, while other want it at the edge of the screen.
> 
> So, *if* I'm understanding the issue correctly, it would be best if the 
> padding side were user-configurable. If that's not an option, either 
> side will do, because there doesn't seem to be any clear preference 
> either way.

That's what we've been wondering about. Thanks!

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Nov 2017 15:31:01 +0000
Resent-Message-ID: <handler.29279.B29279.15111054253379 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15111054253379
          (code B ref 29279); Sun, 19 Nov 2017 15:31:01 +0000
Received: (at 29279) by debbugs.gnu.org; 19 Nov 2017 15:30:25 +0000
Received: from localhost ([127.0.0.1]:47673 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eGRY9-0000sR-7W
	for submit <at> debbugs.gnu.org; Sun, 19 Nov 2017 10:30:25 -0500
Received: from eggs.gnu.org ([208.118.235.92]:37166)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eGRY7-0000sD-9t
 for 29279 <at> debbugs.gnu.org; Sun, 19 Nov 2017 10:30:23 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eGRXy-0003zx-Li
 for 29279 <at> debbugs.gnu.org; Sun, 19 Nov 2017 10:30:17 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49510)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eGRXv-0003yB-NK; Sun, 19 Nov 2017 10:30:11 -0500
Received: from [176.228.60.248] (port=1915 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eGRXv-0007oX-4H; Sun, 19 Nov 2017 10:30:11 -0500
Date: Sun, 19 Nov 2017 17:30:01 +0200
Message-Id: <8360a6ffra.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <22787e15-080b-0309-d27e-f5ff937cee9e@HIDDEN> (message from
 Dmitry Gutov on Sun, 19 Nov 2017 01:46:29 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <5A0C8CC6.1090203@HIDDEN> <834lpvjomc.fsf@HIDDEN>
 <0e8009ab-d5b1-f996-0ae1-bd4680e5e81b@HIDDEN> <83tvxui663.fsf@HIDDEN>
 <22787e15-080b-0309-d27e-f5ff937cee9e@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Sun, 19 Nov 2017 01:46:29 +0200
> 
> On 11/16/17 5:39 PM, Eli Zaretskii wrote:
> 
> >>> Regardless of the reasons for this change, it doesn't affect the issue
> >>> at hand: calling window-size-change-functions from inside redisplay
> >>> has the same issues as calling window-configuration-change-hook.
> 
> Could you clarify what is the exact issue, BTW?

The same ones described up-thread: the adverse effects of calling
these due to change in line-number width.

> >> But margin size changes won't have to call window-size-change-functions,
> >> right? Then it might be possible to move all the heavy consumers to this
> >> hook, leaving window-configuration-change-hook relatively lightweight
> >> (right)?
> > 
> > For some value of "lightweight".  The ones that I think about would
> > want to change window dimensions, e.g. by enlarging or shrinking the
> > margins, and that is not "lightweight", as I explained up-thread.
> 
> Are window-size-change-functions really supposed to be called when only 
> the margin size has changed, but not the window's outer dimensions?

It's the other way around: in the cases discussed here the hooks will
most probably _want_ to change the margins or some other window
dimensions.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Nov 2017 15:35:01 +0000
Resent-Message-ID: <handler.29279.B29279.15111056933791 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15111056933791
          (code B ref 29279); Sun, 19 Nov 2017 15:35:01 +0000
Received: (at 29279) by debbugs.gnu.org; 19 Nov 2017 15:34:53 +0000
Received: from localhost ([127.0.0.1]:47682 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eGRcT-0000z4-18
	for submit <at> debbugs.gnu.org; Sun, 19 Nov 2017 10:34:53 -0500
Received: from eggs.gnu.org ([208.118.235.92]:38121)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eGRcQ-0000yr-E2
 for 29279 <at> debbugs.gnu.org; Sun, 19 Nov 2017 10:34:50 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eGRcK-0005qZ-68
 for 29279 <at> debbugs.gnu.org; Sun, 19 Nov 2017 10:34:45 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49558)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eGRcE-0005n3-Li; Sun, 19 Nov 2017 10:34:38 -0500
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 <eliz@HIDDEN>)
 id 1eGRcE-0004P2-3P; Sun, 19 Nov 2017 10:34:38 -0500
Date: Sun, 19 Nov 2017 17:34:28 +0200
Message-Id: <834lpqffjv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <463d412b-6a5d-eda5-d882-b4044d4f417d@HIDDEN> (message from
 Dmitry Gutov on Sun, 19 Nov 2017 01:55:23 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
 <83a7znjuc5.fsf@HIDDEN> <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@HIDDEN>
 <83shdei5o8.fsf@HIDDEN> <463d412b-6a5d-eda5-d882-b4044d4f417d@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 20 Nov 2017 22:24:02 +0000
Resent-Message-ID: <handler.29279.B29279.15112166159334 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15112166159334
          (code B ref 29279); Mon, 20 Nov 2017 22:24:02 +0000
Received: (at 29279) by debbugs.gnu.org; 20 Nov 2017 22:23:35 +0000
Received: from localhost ([127.0.0.1]:49606 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eGuTX-0002QU-Kq
	for submit <at> debbugs.gnu.org; Mon, 20 Nov 2017 17:23:35 -0500
Received: from mail-wr0-f182.google.com ([209.85.128.182]:41704)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1eGuTW-0002QG-JO
 for 29279 <at> debbugs.gnu.org; Mon, 20 Nov 2017 17:23:34 -0500
Received: by mail-wr0-f182.google.com with SMTP id z14so9514265wrb.8
 for <29279 <at> debbugs.gnu.org>; Mon, 20 Nov 2017 14:23:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=dJKf0ImW/thIkwfoCA9CFBGQLm4ymALaDzIDvdj+hro=;
 b=nucN/7UAH++tYqeqA7OzlABKn+50btkspFAqt80vA+Vs/VnDw3bO2dOJjtKooLr8r/
 7v7+xn5sKLol1SFTvZ+3xLTuMFx/YmkzyouY9ievLHrYpw0/CXhAjooKejK1Qe734IvO
 jmsWMAM5Wnb9YUi4d774F0GH+pzjIQicPj/TCBpMUed5itdM/w5+NkOwYFYkl6pXK9s4
 2mwpJjfC/tahhalH7pJ8sTUMR70oIK5hDiAiTQ2d21KRa/6OLIEniJi2tYEGKMGZqwoi
 naulgODRW/sqSZYGYiKMssDeMaznmv0crKew+o00qxOuGBr9o0hleFoc1RXhHr2XISYD
 bxYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=dJKf0ImW/thIkwfoCA9CFBGQLm4ymALaDzIDvdj+hro=;
 b=V77iQ2MuWwQ5LGNmQ47XKBXnYQi1LnikNJJcZ1Wed33pvvbNdkjTubUXLsl2HI5W6U
 UbQgWzotRSOkgTnCLPcKdHX8fq/LttYWqiBxa2JUCpP2fB9kH76KC/aj1a+GzWdg89kV
 8XSA6dbmR7Ygfm+F4mqP8mhg2BFXtGr3AJrlJsFA2pbHmSTA3SUJ+mwR3EUtrBmkqsYF
 BCNcdP4Y/eAu2oSTltdJDRsqSN7FrfvpGqJmVDQNwQOsWtSdCDZUhKs9t1M5NJWNV9Tq
 +eIFnFQSUUS24IhrDPGz9vaka1DOcATgSyJ9/Wb6/dRyEictiRIyvXQyDvGaPWZb7ty7
 Twxw==
X-Gm-Message-State: AJaThX4+CKu24BC6tdEjylmJ7hQXZgeJmpvgVN0wBaJy+ZhnqQdnPACk
 dTKD3dSxp0b50IpMmEtHSbk=
X-Google-Smtp-Source: AGs4zMbAukxAqkjar5ff/N2VCsBecj6+vwbc18fQrwH6MZFEGwz02qM0tQ6s0xVaSI2wlNIRCMUI6A==
X-Received: by 10.223.175.199 with SMTP id y7mr13455654wrd.207.1511216608877; 
 Mon, 20 Nov 2017 14:23:28 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id i8sm12562217wrb.29.2017.11.20.14.23.27
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 20 Nov 2017 14:23:28 -0800 (PST)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
 <83a7znjuc5.fsf@HIDDEN> <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@HIDDEN>
 <83shdei5o8.fsf@HIDDEN> <463d412b-6a5d-eda5-d882-b4044d4f417d@HIDDEN>
 <834lpqffjv.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <a693cdce-b5e1-0768-2c64-c60115e116c7@HIDDEN>
Date: Tue, 21 Nov 2017 00:23:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
 Thunderbird/57.0
MIME-Version: 1.0
In-Reply-To: <834lpqffjv.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

On 11/19/17 5:34 PM, Eli Zaretskii wrote:

>> 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?

The latter approach requires more user code.

I'd say it's a bit like the difference between having a 
post-self-insert-hook and not having it, asking users to rely on 
post-command-hook.

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

I don't know these uses, so can't really comment, I guess.

> Anyway, could we please stop mixing these two issues?

Sure. I think we've collected the requirements by now, though. Time for 
an implementation?

 > This discussion
 > is about margin sharing, not about a (missing) hook for changes in
 > line-number width.

IMHO the question of removing the irregularity introduced by the native 
line numbers using the new shared margins support is a fairly important 
one. But it's not urgent, of course.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#29279: Sharing the margins
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 21 Nov 2017 15:41:01 +0000
Resent-Message-ID: <handler.29279.B29279.15112788314175 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 29279
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 29279-submit <at> debbugs.gnu.org id=B29279.15112788314175
          (code B ref 29279); Tue, 21 Nov 2017 15:41:01 +0000
Received: (at 29279) by debbugs.gnu.org; 21 Nov 2017 15:40:31 +0000
Received: from localhost ([127.0.0.1]:51249 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eHAf1-00015H-3N
	for submit <at> debbugs.gnu.org; Tue, 21 Nov 2017 10:40:31 -0500
Received: from eggs.gnu.org ([208.118.235.92]:56058)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1eHAez-000155-Ah
 for 29279 <at> debbugs.gnu.org; Tue, 21 Nov 2017 10:40:29 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1eHAet-0002Ch-2l
 for 29279 <at> debbugs.gnu.org; Tue, 21 Nov 2017 10:40:23 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39660)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1eHAel-0002AH-RH; Tue, 21 Nov 2017 10:40:15 -0500
Received: from [176.228.60.248] (port=3701 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1eHAel-0006D2-8W; Tue, 21 Nov 2017 10:40:15 -0500
Date: Tue, 21 Nov 2017 17:40:10 +0200
Message-Id: <83lgizd4it.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <a693cdce-b5e1-0768-2c64-c60115e116c7@HIDDEN> (message from
 Dmitry Gutov on Tue, 21 Nov 2017 00:23:26 +0200)
References: <0a54e927-cab1-1f1d-4996-85bb36949a33@HIDDEN>
 <83375imbaa.fsf@HIDDEN> <bcfec133-44a0-cc87-1966-5f6f862bbf01@HIDDEN>
 <83o9o6kp61.fsf@HIDDEN> <d9e4b108-c738-73f8-3257-61219ebeee8b@HIDDEN>
 <83h8tykm99.fsf@HIDDEN> <aff8eef4-a8cc-ab2d-dea6-bbb0ad15e3d7@HIDDEN>
 <83375glvx4.fsf@HIDDEN> <0547e92c-a574-0fe4-6122-1d11b24ee3c5@HIDDEN>
 <83efp0jjhi.fsf@HIDDEN> <77ddb7fc-d57f-05fa-026c-e23e3bcd3432@HIDDEN>
 <83a7znjuc5.fsf@HIDDEN> <9bbfd79b-9e80-db5a-fe57-d0d629477d5d@HIDDEN>
 <83shdei5o8.fsf@HIDDEN> <463d412b-6a5d-eda5-d882-b4044d4f417d@HIDDEN>
 <834lpqffjv.fsf@HIDDEN> <a693cdce-b5e1-0768-2c64-c60115e116c7@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Cc: 29279 <at> debbugs.gnu.org, joostkremers@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> Date: Tue, 21 Nov 2017 00:23:26 +0200
> 
> > What is the difference between being notified when the width changed,
> > and figuring out when it was changed by comparing two numbers?
> 
> The latter approach requires more user code.

Yes, but not a lot more, and the code is fairly straightforward.

> I'd say it's a bit like the difference between having a 
> post-self-insert-hook and not having it, asking users to rely on 
> post-command-hook.

You know me well enough: if the hook you are asking for were easy to
implement safely, it would have been written long ago.

> I think we've collected the requirements by now, though. Time for an
> implementation?

Yes.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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