bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

There appears to be a change to `window-min-size' that gives an erroneously large minimum horizontal window size when the combined size of window margins exceed that of the body text, e.g. in a frame 80 columns wide, with left margin 20 columns and right margin 20 columns, would return a minimum horizontal size of 42, when body text would be 40. This causes `split-window-right' to fail.

To reproduce:

1. emacs -Q
2. in a frame 80 columns wide...
3. M-: (set-window-margins nil 20 20)
4. C-x 3
    => "Window #<window 1 on *scratch*> too small for splitting (2)"
5. M-: (window-min-size nil t)
    => 42

Expected results:

Window should split horizontally. Minimum window width should not be dictated by margin width.

Actual results:

Margin width dictates minimum window width and prevents window splitting.

Configuration:

GNU Emacs 25.1.1 (x86_64-apple-darwin15.6.0, NS appkit-1404.47 Version 10.11.6 (Build 15G31)) of 2016-08-09

MacBook Pro (Retina, 15-inch, Mid 2014)
2.2 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel Iris Pro 1536 MB

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[martin rudalics]

 > 1. emacs -Q
 > 2. in a frame 80 columns wide...
 > 3. M-: (set-window-margins nil 20 20)
 > 4. C-x 3
 >      => "Window #<window 1 on *scratch*> too small for splitting (2)"
 > 5. M-: (window-min-size nil t)
 >      => 42
 >
 > Expected results:
 >
 > Window should split horizontally. Minimum window width should not be dictated by margin width.
 >
 > Actual results:
 >
 > Margin width dictates minimum window width and prevents window splitting.

Correct.  The Elisp manual states

  -- Function: window-min-size &optional window horizontal ignore
           pixelwise
      This function returns the minimum size of WINDOW.  WINDOW must be
      a valid window and defaults to the selected one.  The optional
      argument HORIZONTAL non-`nil' means to return the minimum number
      of columns of WINDOW; otherwise return the minimum number of
      WINDOW's lines.

      The return value makes sure that all components of WINDOW remain
      fully visible if WINDOW's size were actually set to it.  With
      HORIZONTAL `nil' it includes the mode and header line, the
      horizontal scroll bar and the bottom divider, if present.  With
      HORIZONTAL non-`nil' it includes the margins and fringes, the
      vertical scroll bar and the right divider, if present.

If you want to make a smaller window you have to explicitly specify its
size:

(defun split-window-right-ignore (&optional size)
   (interactive)
   (split-window-right (or size (/ (window-total-width) 2))))

(define-key ctl-x-map "3" 'split-window-right-ignore)

martin

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

martin rudalics <rudalics@gmx.at> on Tue, 09 Aug 2016 11:49 +0200:
> Correct.  The Elisp manual states
>
> [...]
>
> If you want to make a smaller window you have to explicitly specify
> its size:
>
> (defun split-window-right-ignore (&optional size)   (interactive) (split-window-
> right (or size (/ (window-total-width) 2))))
>
> (define-key ctl-x-map "3" 'split-window-right-ignore)

The bug is not necessarily with `window-min-size' rather with the on-
flow effect it has on C-x 3 `split-window-right', which needs to work
reliably for users without resorting to writing elisp.

This is already having real-life negative effects. See
https://github.com/rnkn/olivetti/issues/12

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[martin rudalics]

 > The bug is not necessarily with `window-min-size' rather with the on-
 > flow effect it has on C-x 3 `split-window-right', which needs to work
 > reliably for users without resorting to writing elisp.

I share your opinion that "C-x 3 needs to work reliably for users
without resorting to writing elisp".

 > This is already having real-life negative effects. See
 > https://github.com/rnkn/olivetti/issues/12

There you say:

    Someone seems to have made a very poor design
    decision in changing the way window-min-size works.

Now with emacs -Q evaluate the following forms

(defun split-window-right-ignore (&optional size)
   (interactive)
   (split-window-right (or size (/ (window-total-width) 2))))

(define-key ctl-x-map "3" 'split-window-right-ignore)

(set-window-margins nil 20 20)

do C-x 3 and look at the resulting windows.  That's what I would call a
"poor design decision".

martin

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

martin rudalics <rudalics@gmx.at> on Tue, 09 Aug 2016 12:15 +0200:
> I share your opinion that "C-x 3 needs to work reliably for users
> without resorting to writing elisp".

Excellent.

> There you say:
> 
>     Someone seems to have made a very poor design
>     decision in changing the way window-min-size works.
> 
> Now with emacs -Q evaluate the following forms
> 
> (defun split-window-right-ignore (&optional size)
>    (interactive)
>    (split-window-right (or size (/ (window-total-width) 2))))
> 
> (define-key ctl-x-map "3" 'split-window-right-ignore)
> 
> (set-window-margins nil 20 20)
> 
> do C-x 3 and look at the resulting windows.  That's what I would call a
> "poor design decision".

https://gfycat.com/ZestyBeautifulEmeraldtreeskink

How about we maybe focus instead on solving this?

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Date: Tue, 09 Aug 2016 20:37:13 +1000
> Cc: 24193@debbugs.gnu.org
> 
> How about we maybe focus instead on solving this?

If you have ideas for how to solve this, please tell.

Thanks.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

Eli Zaretskii <eliz@gnu.org> on Tue, 09 Aug 2016 17:56 +0300:
> I don't think I understand what exactly you expected to happen.  In
> "emacs -Q" with no margins, "C-x 3" produces 2 windows: one that is
> 38-column wide, the other 37-column wide.  Since you requested 2 20-
> column margins, they alone need 40 columns.  How can Emacs produce a
> window with such margins out of 38 columns it has at its disposal?
> That isn't enough even for the margins, let alone the text area.

On the one hand, splitting an 80 column wide window naturally halves the
window width, and as such the minimum margin width should also be
halved, so window-min-size is not calculating a logical minimum size.

On the other hand, I kinda just wanna say whatever 24.5 was, because it
worked perfectly there and now it's broken. It's hard to see that as
anything but a regression.

> In such a situation, I think refusing to split is a reasonable
> response: the user asked for something that is not doable.  What
> alternative behavior did you expect?

No this is nuts. To go from perfectly working behaviour in Emacs 24.5 to
a refusal to function and an ambiguous error message is not what any
user should expect.

"Window #<window 1 on *scratch*> too small for splitting (2)" implies
that the window is 2 columns wide, which is confusing, but the 2 is
actually just the code author's numbering of error messages. Again, not
what the user expects.

Eli Zaretskii <eliz@gnu.org> on Tue, 09 Aug 2016 17:57 +0300:
> If you have ideas for how to solve this, please tell.

The gfycat.com link shows the behaviour in 24.5, which works perfectly.
I'd urge a rollback to the relevant 24.5 code here to prevent this bug
going into the 25.1 release.

I understand Emacs is very code-centric, but many people use it also for
prose writing, and there are several prose packages that set the window
margins in this same way... olivetti, writeroom-mode, darkroom- mode,
visual-fill-column... I haven't tested these all but predict a few
related bugs...

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Cc: rudalics@gmx.at, 24193@debbugs.gnu.org
> Date: Wed, 10 Aug 2016 01:18:32 +1000
> 
> Eli Zaretskii <eliz@gnu.org> on Tue, 09 Aug 2016 17:56 +0300:
> > I don't think I understand what exactly you expected to happen.  In
> > "emacs -Q" with no margins, "C-x 3" produces 2 windows: one that is
> > 38-column wide, the other 37-column wide.  Since you requested 2 20-
> > column margins, they alone need 40 columns.  How can Emacs produce a
> > window with such margins out of 38 columns it has at its disposal?
> > That isn't enough even for the margins, let alone the text area.
> 
> On the one hand, splitting an 80 column wide window naturally halves the
> window width, and as such the minimum margin width should also be
> halved, so window-min-size is not calculating a logical minimum size.

Decreasing the width of the margins when splitting a window causes
worse problems: if the smaller margin cannot display the stuff (text,
image, etc.) that the application wants to display there, that stuff
will be truncated, or not shown at all.  E.g., the line numbers shown
by linum-mode will become truncated if the margins are made narrower
than what linum-mode needs.  Worse, linum-mode recalculates the margin
width from time to time, and so it will try to enlarge the margin,
making the text area smaller than it can possibly be.  These are
catastrophic failures that we cannot impose on Lisp applications.

> On the other hand, I kinda just wanna say whatever 24.5 was, because it
> worked perfectly there and now it's broken. It's hard to see that as
> anything but a regression.

From my POV, the 24.x behavior was broken, see above.  We changed that
to avoid those problems.  An application that sets a margin of a
certain width has every right to expect Emacs not to change that.

> "Window #<window 1 on *scratch*> too small for splitting (2)" implies
> that the window is 2 columns wide, which is confusing, but the 2 is
> actually just the code author's numbering of error messages.

If the error message is unclear, we can and should improve it.  But I
don't think this is the main issue at hand here.

> > If you have ideas for how to solve this, please tell.
> 
> The gfycat.com link shows the behaviour in 24.5, which works perfectly.
> I'd urge a rollback to the relevant 24.5 code here to prevent this bug
> going into the 25.1 release.

Sorry, rolling this back is out of the question.  The current behavior
was discussed at length, and was introduced to fix problems that I
think are much worse.

> I understand Emacs is very code-centric, but many people use it also for
> prose writing, and there are several prose packages that set the window
> margins in this same way... olivetti, writeroom-mode, darkroom- mode,
> visual-fill-column... I haven't tested these all but predict a few
> related bugs...

Emacs cannot possibly know that the application which set the margins
can cope with decreasing the margins.  Only the application (or the
user) know that.

Anyway, I think these particular modes were also discussed in the
context of this change in behavior.  I think one way of dealing with
this issue in the modes you mention is to bind "C-x 3" to a
specialized command that reduces the margins before it calls
window-split.  An application can do this because it knows its
features and limitations; Emacs core cannot.

Thanks.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

Eli Zaretskii <eliz@gnu.org> on Tue, 09 Aug 2016 18:53 +0300:
> Decreasing the width of the margins when splitting a window causes
> worse problems: if the smaller margin cannot display the stuff (text,
> image, etc.) that the application wants to display there, that stuff
> will be truncated, or not shown at all.  E.g., the line numbers shown
> by linum-mode will become truncated if the margins are made narrower
> than what linum-mode needs.  Worse, linum-mode recalculates the margin
> width from time to time, and so it will try to enlarge the margin,
> making the text area smaller than it can possibly be.  These are
> catastrophic failures that we cannot impose on Lisp applications.

I'm not suggesting that Emacs resize the margins, just that Emacs ought
not make the assumption that wide margins mean that splitting the window
is unsafe.

I think your ordering of priorities is a bit off. The top priority here
is that the user needs to be able to press C-x 3 and have the window
split in this use case. e.g. If the user has a window 204 columns wide
with margins each set at 62 columns (with a remaining text body width of
80 columns), attempts to split that window with C-x 3 and receives a
"Window X too small for splitting" error, given that the window is quite
wide and Emacs is saying it's too small, the user's justifiable
assumption is that Emacs is broken.

Also, buffer contents is truncated all the time... Whenever a line
exceeds the window width and truncate lines is t then we get a $ with
truncated text. I don't get your concern here, and especially why
truncating content is worse than breaking core Emacs functionality (C-x
3) with these use cases...

> From my POV, the 24.x behavior was broken, see above.  We changed that
> to avoid those problems.  An application that sets a margin of a
> certain width has every right to expect Emacs not to change that.

Your POV is valid as someone focused on the code, but here it's a
different POV to that of a user, who sees a large window and expects
splitting it to work, because it did in 24.x, so why not now.

Really, Emacs is making a false assumption here, which is that when I
split the window I am not also somehow controlling the margin width (in
this case, with one of a variety of minor modes). So this attempt to
perform some user mind-reading is the root of the design failure.

When Emacs doesn't know, Emacs ought to adopt the position "idk?" and
just do what it's told. When you assume you make an ass of u & Emacs.

> If the error message is unclear, we can and should improve it.  But I
> don't think this is the main issue at hand here.

Yeah it seems the author wants to include something like an error code,
which here is misleading because it resembles (list 2).

> Sorry, rolling this back is out of the question.  The current behavior
> was discussed at length, and was introduced to fix problems that I
> think are much worse.

So too should failing in a common use-case be out of the question.

It would appear that these discussions adopted a very ungracious view of
the mentioned prose-writing packages, that is, rather than find a
solution for both cases, that these packages should just fail?

> Emacs cannot possibly know that the application which set the margins
> can cope with decreasing the margins.  Only the application (or the
> user) know that.
>
> Anyway, I think these particular modes were also discussed in the
> context of this change in behavior.  I think one way of dealing with
> this issue in the modes you mention is to bind "C-x 3" to a
> specialized command that reduces the margins before it calls window-
> split.  An application can do this because it knows its features and
> limitations; Emacs core cannot.

I think rebinding C-x 3 is a messy solution. The problem isn't really
with split-window-right, it's with window-min-size.

For example, one use-case I've come up against a lot is when working
with a text file under git version control with olivetti on (which
automatically sets the margins quite wide) in a single window.
Activating magit would usually split the window horizontally, but
because of the wide margins, the window will split vertically.

This behaviour is not a big deal, but the user expectation when
looking at a wide window with wide margins containing lots of empty
space is that the window ought to split horizontally. Other results
look a bit off.

An idea I just thought of, so feel free to poke holes in it, is to
introduce a local variable, something like window-margins-resizable,
which defaults to nil, but could also be t left or right. This
alleviates the problem of Emacs needing to read the user's mind when it
comes to whether the margins really are too big to split the window or
being controlled otherwise.

Thoughts?

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Cc: rudalics@gmx.at, 24193@debbugs.gnu.org
> Date: Sun, 14 Aug 2016 15:11:30 +1000
> 
> > Decreasing the width of the margins when splitting a window causes
> > worse problems: if the smaller margin cannot display the stuff (text,
> > image, etc.) that the application wants to display there, that stuff
> > will be truncated, or not shown at all.  E.g., the line numbers shown
> > by linum-mode will become truncated if the margins are made narrower
> > than what linum-mode needs.  Worse, linum-mode recalculates the margin
> > width from time to time, and so it will try to enlarge the margin,
> > making the text area smaller than it can possibly be.  These are
> > catastrophic failures that we cannot impose on Lisp applications.
> 
> I'm not suggesting that Emacs resize the margins, just that Emacs ought
> not make the assumption that wide margins mean that splitting the window
> is unsafe.

The function in question keeps the margins at their original size, so
it cannot split the window when doing so leaves no screen space for
buffer text.  The only way to allow it to split such windows is by
resizing the margins.  Otherwise, what does "not make the assumption"
mean in practice?  We cannot rely on the application to resize the
margins, because not every application does that (most don't).

> I think your ordering of priorities is a bit off. The top priority here
> is that the user needs to be able to press C-x 3 and have the window
> split in this use case.

Not if the user does something that makes no sense.  We have such
"user errors" in Emacs all over the place.  E.g., when the user tries
to delete the only window of a frame.  This case is no different, IMO.

> e.g. If the user has a window 204 columns wide
> with margins each set at 62 columns (with a remaining text body width of
> 80 columns), attempts to split that window with C-x 3 and receives a
> "Window X too small for splitting" error, given that the window is quite
> wide and Emacs is saying it's too small, the user's justifiable
> assumption is that Emacs is broken.

I already agreed that we should probably improve the error message, so
let's not reiterate this particular aspect, as we are in agreement.
IOW, the error message we issue now should no longer be an argument
that what Emacs does in this case is wrong, let alone nonsensical.

> Also, buffer contents is truncated all the time... Whenever a line
> exceeds the window width and truncate lines is t then we get a $ with
> truncated text.

When we do so, we display hints about the truncation, and allow
horizontal scrolling to display the truncated text.  No such features
are available for the stuff displayed on the margins, it just
disappears without a trace.  The example I provided, with linum-mode,
is a relevant case in point: the line numbers will appear incorrect
and/or corrupted.

> I don't get your concern here, and especially why
> truncating content is worse than breaking core Emacs functionality (C-x
> 3) with these use cases...

It is worse because the effect is a corrupted display with no hint to
the user.

> > From my POV, the 24.x behavior was broken, see above.  We changed that
> > to avoid those problems.  An application that sets a margin of a
> > certain width has every right to expect Emacs not to change that.
> 
> Your POV is valid as someone focused on the code, but here it's a
> different POV to that of a user, who sees a large window and expects
> splitting it to work, because it did in 24.x, so why not now.

The error message, when we fix it, will explain why not now.

> Really, Emacs is making a false assumption here, which is that when I
> split the window I am not also somehow controlling the margin width (in
> this case, with one of a variety of minor modes). So this attempt to
> perform some user mind-reading is the root of the design failure.

The function in question doesn't change the margins, so it cannot do
its job when no screen estate is left for the text area.  IOW, there's
no assumptions here, only facts.

> > Sorry, rolling this back is out of the question.  The current behavior
> > was discussed at length, and was introduced to fix problems that I
> > think are much worse.
> 
> So too should failing in a common use-case be out of the question.

No, it isn't, because we do that in other cases.

> I think rebinding C-x 3 is a messy solution. The problem isn't really
> with split-window-right, it's with window-min-size.

I'm not sure we want to change window-min-size.  That function is used
for purposes that have nothing to do with splitting the window.  E.g.,
we also use its value when deciding whether a window can be resized,
when fitting window to buffer, etc.

The lowest level function for splitting windows is split-window, so
the change should IMO be either in split-window-right or in
split-window.  Martin, WDYT?

> An idea I just thought of, so feel free to poke holes in it, is to
> introduce a local variable, something like window-margins-resizable,
> which defaults to nil, but could also be t left or right. This
> alleviates the problem of Emacs needing to read the user's mind when it
> comes to whether the margins really are too big to split the window or
> being controlled otherwise.
> 
> Thoughts?

See above.

Also, this proposal is incomplete, because it doesn't tell what should
window-splitting functions do when the margins are too wide for one or
both of the two windows after the split.  You explicitly say that you
don't suggest that margins be resized when such windows are split, so
it is not clear what should be done in those cases.

Thanks.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

 > I'm not sure we want to change window-min-size.  That function is used
 > for purposes that have nothing to do with splitting the window.  E.g.,
 > we also use its value when deciding whether a window can be resized,
 > when fitting window to buffer, etc.
 >
 > The lowest level function for splitting windows is split-window, so
 > the change should IMO be either in split-window-right or in
 > split-window.  Martin, WDYT?

This wouldnn't help much because as soon as a user has two side-by-side
windows she might want to drag the divider between those windows and
complain that it doesn't move.  We can install the attached hack in
Emacs 25.1 and leave this subject alone until someone has a better
solution.

martin

[-- Attachment #2: min-margins.diff --]
[-- Type: text/plain, Size: 2535 bytes --]

diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index 55d90bd..7c07dd1 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -4349,6 +4349,24 @@ Window Parameters
 The fourth element is the buffer whose display caused the creation of
 this parameter.  @code{quit-restore-window} deletes the specified window
 only if it still shows that buffer.
+
+@item @code{min-margins}
+The value of this parameter is a cons cell specifying the minimum values
+(in columns) for the left and right margin of this window.  When
+present, Emacs will use these values instead of the real margin widths
+for determining whether a window can be split or shrunk.
+
+Emacs does not auto-adjust the margins of any window after splitting or
+resizing it.  It is sole responsibility of the application that sets
+this parameter to adjust the margins of this window as well as those of
+any new window created by a split.  The hooks to achieve that are
+@code{window-configuration-change-hook} and
+@code{window-size-change-functions} (@pxref{Window Hooks}).
+
+This parameter was introduced in Emacs version 25.1 as a conspiracy hack
+for applications that use large margins to center buffer text within a
+window and should be used with extreme care.  It can be replaced by an
+improved solution in future versions of Emacs.
 @end table

 There are additional parameters @code{window-atom} and @code{window-side};
diff --git a/lisp/window.el b/lisp/window.el
index f7a547b..ca8141b 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -1383,10 +1383,17 @@ window--min-size-1
 	  (let* ((char-size (frame-char-size window t))
 		 (fringes (window-fringes window))
 		 (margins (window-margins window))
+                 (min-margins (window-parameter window 'min-margins))
+                 (left-min-margin (and min-margins
+                                       (numberp (car min-margins))
+                                       (car min-margins)))
+                 (right-min-margin (and min-margins
+                                        (numberp (cdr min-margins))
+                                        (cdr min-margins)))
 		 (pixel-width
 		  (+ (window-safe-min-size window t t)
-		     (* (or (car margins) 0) char-size)
-		     (* (or (cdr margins) 0) char-size)
+		     (* (or left-min-margin (car margins) 0) char-size)
+		     (* (or right-min-margin(cdr margins) 0) char-size)
 		     (car fringes) (cadr fringes)
 		     (window-scroll-bar-width window)
 		     (window-right-divider-width window))))

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

martin rudalics <rudalics@gmx.at> on Mon, 15 Aug 2016 10:28 +0200:
>  > I'm not sure we want to change window-min-size.  That function is used
>  > for purposes that have nothing to do with splitting the window.  E.g.,
>  > we also use its value when deciding whether a window can be resized,
>  > when fitting window to buffer, etc.
>  >
>  > The lowest level function for splitting windows is split-window, so
>  > the change should IMO be either in split-window-right or in
>  > split-window.  Martin, WDYT?
> 
> This wouldnn't help much because as soon as a user has two side-by-side
> windows she might want to drag the divider between those windows and
> complain that it doesn't move.  We can install the attached hack in
> Emacs 25.1 and leave this subject alone until someone has a better
> solution.

Ah brilliant! Thank you Martin :)

If/when this is replaced, would this bug thread to be referenced? It would certainly help with updating the modes affected.

I guess etiquette would dictate that a mode should set these to the maximum of the existing value or its own for cases when two modes want control of minimum margin width.... is that a case that can arise? I guess it is.....

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[martin rudalics]

 > If/when this is replaced, would this bug thread to be referenced? It
 > would certainly help with updating the modes affected.

The commit references the bug number.

 > I guess etiquette would dictate that a mode should set these to the
 > maximum of the existing value or its own for cases when two modes want
 > control of minimum margin width.... is that a case that can arise? I
 > guess it is.....

Hopefully such a case never arises.  Having two modes use the same hooks
to impose their idea of how to size margins is asking for trouble.

martin

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Eli Zaretskii]

> Date: Mon, 15 Aug 2016 10:28:12 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 24193@debbugs.gnu.org
> 
> We can install the attached hack in Emacs 25.1 and leave this
> subject alone until someone has a better solution.

Fine with me, modulo the provocative wording in the doc.

Thanks.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[martin rudalics]

 >> We can install the attached hack in Emacs 25.1 and leave this
 >> subject alone until someone has a better solution.
 >
 > Fine with me, modulo the provocative wording in the doc.

Installed with, hopefully, less provocative wording in the doc.

martin

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Eli Zaretskii]

> Date: Tue, 16 Aug 2016 09:35:33 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: hello@paulwrankin.com, 24193@debbugs.gnu.org
> 
>  >> We can install the attached hack in Emacs 25.1 and leave this
>  >> subject alone until someone has a better solution.
>  >
>  > Fine with me, modulo the provocative wording in the doc.
> 
> Installed with, hopefully, less provocative wording in the doc.

Thanks.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

Eli Zaretskii <eliz@gnu.org> on Tue, 16 Aug 2016 17:19 +0300:
> > Date: Tue, 16 Aug 2016 09:35:33 +0200
> > From: martin rudalics <rudalics@gmx.at>
> > CC: hello@paulwrankin.com, 24193@debbugs.gnu.org
> > 
> >  >> We can install the attached hack in Emacs 25.1 and leave this
> >  >> subject alone until someone has a better solution.
> >  >
> >  > Fine with me, modulo the provocative wording in the doc.
> > 
> > Installed with, hopefully, less provocative wording in the doc.
> 
> Thanks.

Turns out there is a better solution, so the patch can be removed before stable 25.1 release if you prefer :)

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[martin rudalics]

 > Turns out there is a better solution, so the patch can be removed
 > before stable 25.1 release if you prefer :)

Thanks for the information.  But that ship has sailed now.

martin

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Lars Ingebrigtsen]

Paul Rankin <hello@paulwrankin.com> writes:

>> >  >> We can install the attached hack in Emacs 25.1 and leave this
>> >  >> subject alone until someone has a better solution.
>> >  >
>> >  > Fine with me, modulo the provocative wording in the doc.
>> > 
>> > Installed with, hopefully, less provocative wording in the doc.
>> 
>> Thanks.
>
> Turns out there is a better solution, so the patch can be removed
> before stable 25.1 release if you prefer :)

Skimming this thread, Martin's patch was applied (which seemed to fix
the issue?), but then Paul said there's a better solution?  (But not
what it was.)

So I'm not sure whether there's more to do here, or whether the bug
report should be closed.  Anybody?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  24193@debbugs.gnu.org,  martin rudalics
>  <rudalics@gmx.at>
> Date: Fri, 04 Sep 2020 15:09:59 +0200
> 
> > Turns out there is a better solution, so the patch can be removed
> > before stable 25.1 release if you prefer :)
> 
> Skimming this thread, Martin's patch was applied (which seemed to fix
> the issue?), but then Paul said there's a better solution?  (But not
> what it was.)
> 
> So I'm not sure whether there's more to do here, or whether the bug
> report should be closed.  Anybody?

It should be closed; done.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul W. Rankin via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2020-09-04 23:09, Lars Ingebrigtsen wrote:
> Paul Rankin <hello@paulwrankin.com> writes:
>> Turns out there is a better solution, so the patch can be removed
>> before stable 25.1 release if you prefer :)
> 
> Skimming this thread, Martin's patch was applied (which seemed to fix
> the issue?), but then Paul said there's a better solution?  (But not
> what it was.)
> 
> So I'm not sure whether there's more to do here, or whether the bug
> report should be closed.  Anybody?

I was mistaken. The min-margins parameter is still required. Sorry for 
the confusion.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Lars Ingebrigtsen]

"Paul W. Rankin" <pwr@bydasein.com> writes:

> On 2020-09-04 23:09, Lars Ingebrigtsen wrote:
>> Paul Rankin <hello@paulwrankin.com> writes:
>>> Turns out there is a better solution, so the patch can be removed
>>> before stable 25.1 release if you prefer :)
>> Skimming this thread, Martin's patch was applied (which seemed to
>> fix
>> the issue?), but then Paul said there's a better solution?  (But not
>> what it was.)
>> So I'm not sure whether there's more to do here, or whether the bug
>> report should be closed.  Anybody?
>
> I was mistaken. The min-margins parameter is still required. Sorry for
> the confusion.

OK, then I guess everything discussed here was fixed, and I'm closing
this bug report.  If there's any more to be done here, please respond to
the debbugs address, and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[martin rudalics]

 > https://gfycat.com/ZestyBeautifulEmeraldtreeskink
 >
 > How about we maybe focus instead on solving this?

I supoose you have designed a mode to auto-adjust margins so that text
appears centered in a window.  You can add the following function

(defun split-window-right-ignore (&optional size)
   (if (car size) size (list (/ (window-total-width) 2))))

and use

(add-function
  :filter-args (symbol-function 'split-window-right) #'split-window-right-ignore)

when activating your mode and

(remove-function
  (symbol-function 'split-window-right) #'split-window-right-ignore)

when deactivating it.

martin

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Paul Rankin]

martin rudalics <rudalics@gmx.at> on Tue, 09 Aug 2016 18:08 +0200:
> I supoose you have designed a mode to auto-adjust margins so that text
> appears centered in a window.  You can add the following function
> 
> (defun split-window-right-ignore (&optional size)
>    (if (car size) size (list (/ (window-total-width) 2))))
> 
> and use
> 
> (add-function
>   :filter-args (symbol-function 'split-window-right) #'split-window-right-ignore)
> 
> when activating your mode and
> 
> (remove-function
>   (symbol-function 'split-window-right) #'split-window-right-ignore)
> 
> when deactivating it.

Many thanks, this is helpful. Although I think patching C-x 3 is not the right solution.

I'd like to find a solution that fixes window-min-size for everyone, including those who use Emacs to write prose.

bug#24193: 25.1; `window-min-size' fails for horizontal width when margins >= body text

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Date: Tue, 09 Aug 2016 19:14:27 +1000
> 
> There appears to be a change to `window-min-size' that gives an erroneously large minimum horizontal window size when the combined size of window margins exceed that of the body text, e.g. in a frame 80 columns wide, with left margin 20 columns and right margin 20 columns, would return a minimum horizontal size of 42, when body text would be 40. This causes `split-window-right' to fail.
> 
> To reproduce:
> 
> 1. emacs -Q
> 2. in a frame 80 columns wide...
> 3. M-: (set-window-margins nil 20 20)
> 4. C-x 3
>     => "Window #<window 1 on *scratch*> too small for splitting (2)"
> 5. M-: (window-min-size nil t)
>     => 42
> 
> Expected results:
> 
> Window should split horizontally. Minimum window width should not be dictated by margin width.
> 
> Actual results:
> 
> Margin width dictates minimum window width and prevents window splitting.

I don't think I understand what exactly you expected to happen.  In
"emacs -Q" with no margins, "C-x 3" produces 2 windows: one that is
38-column wide, the other 37-column wide.  Since you requested 2
20-column margins, they alone need 40 columns.  How can Emacs produce
a window with such margins out of 38 columns it has at its disposal?
That isn't enough even for the margins, let alone the text area.

In such a situation, I think refusing to split is a reasonable
response: the user asked for something that is not doable.  What
alternative behavior did you expect?

Thanks.