bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Constantine Vetoshev]

The Emacs pretest released earlier today has a window width
calculation problem on Mac OS X when the window left fringe is turned
off. This bug seems similar to #18601 and #16470.

To reproduce, do the following:

1. Start Emacs 25.0.92 (with -Q to avoid loading initialization file).
2. Execute this Elisp: (set-fringe-mode '(0 . 7))
3. Execute M-x ansi-term and select /bin/zsh as your shell.
4. Resize the frame to make it slightly wider (I used the mouse to
make the frame one character wider).
5. Run 'ls' in the shell. Notice the spurious % characters printed
everywhere. This is the bug.

Setting the fringe to '(1 . 7) makes the problem go away.

I noticed that the fringe needs to be set wider in Emacs 25 compared
to 24. I used fringe '(0 . 2) in the past, but that's now too small.
It seems that the fringe window width calculation has changed, and
re-introduced this bug.


In GNU Emacs 25.0.92.1 (x86_64-apple-darwin15.3.0, NS appkit-1404.34
Version 10.11.3 (Build 15D21))
 of 2016-03-02 built on athena.local
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
 'configure --with-ns'

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LC_COLLATE: C
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Term

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
((left-fringe . 0) (right-fringe . 0))
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode cl-loaddefs pcase cl-lib
mail-prsvr mail-utils term disp-table easymenu ehelp ring time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel ns-win ucs-normalize term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 199926 9804)
 (symbols 48 19902 0)
 (miscs 40 63 188)
 (strings 32 16034 4798)
 (string-bytes 1 462558)
 (vectors 16 33606)
 (vector-slots 8 650873 6522)
 (floats 8 162 177)
 (intervals 56 293 0)
 (buffers 976 13))

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[martin rudalics]

 > The Emacs pretest released earlier today has a window width
 > calculation problem on Mac OS X when the window left fringe is turned
 > off. This bug seems similar to #18601 and #16470.
 >
 > To reproduce, do the following:
 >
 > 1. Start Emacs 25.0.92 (with -Q to avoid loading initialization file).
 > 2. Execute this Elisp: (set-fringe-mode '(0 . 7))
 > 3. Execute M-x ansi-term and select /bin/zsh as your shell.
 > 4. Resize the frame to make it slightly wider (I used the mouse to
 > make the frame one character wider).
 > 5. Run 'ls' in the shell. Notice the spurious % characters printed
 > everywhere. This is the bug.
 >
 > Setting the fringe to '(1 . 7) makes the problem go away.
 >
 > I noticed that the fringe needs to be set wider in Emacs 25 compared
 > to 24. I used fringe '(0 . 2) in the past, but that's now too small.
 > It seems that the fringe window width calculation has changed, and
 > re-introduced this bug.
 >
 >
 > In GNU Emacs 25.0.92.1 (x86_64-apple-darwin15.3.0, NS appkit-1404.34
 > Version 10.11.3 (Build 15D21))
 >   of 2016-03-02 built on athena.local

Sorry, this mail ended up in the wrong folder so it went by unnoticed
for such long time.  I have no idea which change could have caused this.
Could you please try to bisect to find the offending commit?

Thanks, martin

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Anders Lindgren]

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

Hi!

I took a look at this from the NS port point of view.

Setting the `left-frame' frame parameter to any from 1 and up change the
width of the fringe, while retaining the width of the text area (80
characters). However, setting it to 0 makes the text area wrap on 79
characters (despite there being space for the 80:th character) while
`window-width' still returns 80.

Presumably, this is the root cause of the ansi-term problem.

However, to check if this was a NS specific problem, I tested this on a
freshly built GTK+ emacs on LinuxMint. It turned out that it, too, suffers
from the same problem, so I'm handing over this to you, Martin.

Steps to repeat:

   emacs -Q
   C-u 8 0 x RET
        ;; This inserts a line wide enough to reach the right side of the
screen without wrapping)
   (set-frame-parameter (selected-frame) 'left-fringe 50)
        ;; This makes the left fringe wide, the text area still holds the
80 x:s nicely.
   (window-width)
        ;; 80
   (set-frame-parameter (selected-frame) 'left-fringe 1)
        ;; Narrow left fringe. Text area still holds the x:s
   (window-width)
        ;; 80
   (set-frame-parameter (selected-frame) 'left-fringe 0)
        ;; The line of x:s wrap
   (window-width)
        ;; 80 -- inconsistent with what is displayed on screen.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1766 bytes --]

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Eli Zaretskii]

> Date: Thu, 14 Apr 2016 07:33:15 +0200
> From: Anders Lindgren <andlind@gmail.com>
> 
> Setting the `left-frame' frame parameter to any from 1 and up change the width of the fringe, while retaining
> the width of the text area (80 characters). However, setting it to 0 makes the text area wrap on 79 characters
> (despite there being space for the 80:th character) while `window-width' still returns 80.

This is all as expected: setting any of the fringes to zero requires
displaying a continuation glyph in the text area, and since Emacs
supports bidirectional display, we need to usurp one character cell
from the other edge of the window as well, to make the geometry of L2R
and R2L screen lines symmetrical.

> Presumably, this is the root cause of the ansi-term problem.

If this causes trouble in ansi-term, then ansi-term should be fixed to
take this into consideration.  (Presumably, ansi-term uses wrong
interfaces to get at the width of the text area.)

> However, to check if this was a NS specific problem, I tested this on a freshly built GTK+ emacs on
> LinuxMint. It turned out that it, too, suffers from the same problem, so I'm handing over this to you, Martin.

This is not Martin's problem, this is a problem in ansi-term (AFAIU).

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Anders Lindgren]

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

Hi!


> > Setting the `left-frame' frame parameter to any from 1 and up change the
> width of the fringe, while retaining
> > the width of the text area (80 characters). However, setting it to 0
> makes the text area wrap on 79 characters
> > (despite there being space for the 80:th character) while `window-width'
> still returns 80.
>
> This is all as expected: setting any of the fringes to zero requires
> displaying a continuation glyph in the text area, and since Emacs
> supports bidirectional display, we need to usurp one character cell
> from the other edge of the window as well, to make the geometry of L2R
> and R2L screen lines symmetrical.
>

Oh, this was a bit unexpected...

However, I don't understand why you need it. If the right fringe is
visible, it can hold the continuation character. In fact, I just tried this
with the left fringe set to 0 with a bidirectional text stretching multiple
lines, and the last text column didn't appear to be used at all.

Furthermore, I don't think this is what people want -- some people would
surely like to hide the fringes (especially the left) without losing one
text column. (Most Emacs users don't use bidirectional text anyway.)

When it comes to documentation, there is very little, if any, information
about this. For example, this is the description of the fringe frame
properties, it doesn't mention that setting either to zero would make Emacs
reserve a column for the continuation glyph:

    `left-fringe'
    `right-fringe'
         The default width of the left and right fringes of windows in this
         frame (*note Fringes::).  If either of these is zero, that
         effectively removes the corresponding fringe.

In the documentation of `window-width' (a.k.a. `window-body-width') it is
mentioned that the width includes the continuation glyph. However, in
`window-text-width' it is not.

It took some time to find the function `window-max-chars-per-line', which
seems to be the only way to check if there is a column reserved for the
continuation character. (term.el has replicated the logic in
`term-window-width'.)


Anyway, I think I found the real problem this time. ansi-term picks the
window size from both `term-window-width' (which correctly returns 79) and
`window-adjust-process-window-size-smallest' which doesn't take the
continuation glyph into account and says that the width is 80.

Again, I'l leaving it to others to fix it, as this is code I'm not at all
familiar with.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 3207 bytes --]

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Eli Zaretskii]

> Date: Thu, 14 Apr 2016 20:19:36 +0200
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22891@debbugs.gnu.org, martin rudalics <rudalics@gmx.at>
> 
> However, I don't understand why you need it. If the right fringe is visible, it can hold the continuation character.

R2L lines display the continuation glyph on the left.

> In fact, I just tried this with the left fringe set to 0 with a bidirectional text stretching multiple lines, and the last
> text column didn't appear to be used at all.

Sorry, I don't understand what you tried.  Please show a screenshot.

> Furthermore, I don't think this is what people want -- some people would surely like to hide the fringes
> (especially the left) without losing one text column. (Most Emacs users don't use bidirectional text anyway.)

They should set the fringes to 1-pixel width, then.  Or make their
frames 1 character wider.  Sorry, I simply didn't find any other
reasonable way to make the display code sane and the results on the
screen plausible.  Breaking bidirectional display is a no-starter
nowadays, I certainly won't agree to that.  Motivated volunteers are
welcome to find a better solution.

(Once upon a time, Emacs couldn't display continuation glyphs on GUI
frames at all, until someone convinced me to add this feature.  The
rest is history.)

> When it comes to documentation, there is very little, if any, information about this.

Suggestions for how and where to document this, and patches to that
effect, are welcome.

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Constantine Vetoshev]

On Sun, Apr 10, 2016 at 11:58 PM, martin rudalics <rudalics@gmx.at> wrote:
> Could you please try to bisect to find the offending commit?

Yes, of course. It seems to have been commit 165bea78. Please let me
know if I can help further.

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 2962 bytes --]

>
> > However, I don't understand why you need it. If the right fringe is
> visible, it can hold the continuation character.
>
> R2L lines display the continuation glyph on the left.
>
> > In fact, I just tried this with the left fringe set to 0 with a
> bidirectional text stretching multiple lines, and the last
> > text column didn't appear to be used at all.
>
> Sorry, I don't understand what you tried.  Please show a screenshot.
>

I've attached a screenshot where I've:

    C-u 80 x        ;; To get a reference 80 character line
    Copied bidirectional text from http://www.i18nguy.com/unicode/shma.html
    (set-frame-parameter (selected-frame) 'left-fringe 0)

Here, I only see continuation marks in the right fringe only. The column
reserved for the continuation glyph isn't used at all, neither to the left
or to the right, despite the text being wrapped.

As far as I can tell, it's the same on the NS port and when using GTK.



Also, I noticed that `window-max-chars-per-line' does not take into account
the variable `left-frame-width' (and presumably `right-frame-width').

    emacs -Q
    C-u 81 x
    (setq left-fringe-width 0)
    ;; This doesn't take effect immediately, temporary display another
buffer.
    C-x b RET
    C-x b RET
    ;; Now, the line with 81 x:s wrap.
    (window-max-chars-per-line)
    ;; Now, this function return 81, which is inconsistent with the display.


In the short term, I would like to see a function like
`(continuation-glyph-visible-p WIN)' which could be used by functions like
`window-max-chars-per-line' to get the logic correct without having to
resort to replicate the details of the display engine (which, apparently,
is non-trivial).

In the long term, it would be great to have a `continuation-glyph-visible'
frame property and corresponding buffer-local variable. That way a user
could decide the layout for themselves.



Back to the original question. I think the following patch solve the
ansi-term problem. In addition, I would suggest that we retire
`term-window-width' if favour of `window-max-chars-per-line', so that the
complex logic needed to determine if there is a continuation character only
is in one place.

diff --git a/lisp/window.el b/lisp/window.el
index 7e46aa8..371fcab 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8485,10 +8485,10 @@ window-adjust-process-window-size
 a two-argument function used to combine the widths and heights of
 the given windows."
   (when windows
-    (let ((width (window-body-width (car windows)))
+    (let ((width (window-max-chars-per-line (car windows)))
           (height (window-body-height (car windows))))
       (dolist (window (cdr windows))
-        (setf width (funcall reducer width (window-body-width window)))
+        (setf width (funcall reducer width (window-max-chars-per-line
window)))
         (setf height (funcall reducer height (window-body-height window))))
       (cons width height))))

Sincerely,
    Anders

[-- Attachment #1.2: Type: text/html, Size: 4097 bytes --]

[-- Attachment #2: Screen Shot 2016-04-15 at 6.35.59 .png --]
[-- Type: image/png, Size: 108755 bytes --]

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Eli Zaretskii]

> Date: Fri, 15 Apr 2016 09:11:12 +0200
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22891@debbugs.gnu.org, martin rudalics <rudalics@gmx.at>
> 
>  R2L lines display the continuation glyph on the left.
> 
>  > In fact, I just tried this with the left fringe set to 0 with a bidirectional text stretching multiple lines, and
>  the last
>  > text column didn't appear to be used at all.
> 
>  Sorry, I don't understand what you tried. Please show a screenshot.
> 
> I've attached a screenshot where I've:

You did that in *scratch*, which forces all lines to be L2R (because
its major mode is Emacs Lisp, a programming language mode).  See the
value of bidi-paragraph-direction in that buffer.  So all of your
lines are L2R, they just display text in R2L script.

To see what I meant, create a new buffer with "C-x b", then paste the
same text there, after setting the left fringe width to zero.

> Also, I noticed that `window-max-chars-per-line' does not take into account the variable `left-frame-width' (and
> presumably `right-frame-width').

You mean left-fringe-width, I presume?  Yes, that's probably a bug.

> In the short term, I would like to see a function like `(continuation-glyph-visible-p WIN)' which could be used by
> functions like `window-max-chars-per-line' to get the logic correct without having to resort to replicate the
> details of the display engine (which, apparently, is non-trivial).
> 
> In the long term, it would be great to have a `continuation-glyph-visible' frame property and corresponding
> buffer-local variable. That way a user could decide the layout for themselves.

Why is this useful, when we already have window-max-chars-per-line?
IOW, when would you like to know about the continuation glyph, and not
about how many characters can be displayed on a line?

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Anders Lindgren]

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

Hi!

To see what I meant, create a new buffer with "C-x b", then paste the
> same text there, after setting the left fringe width to zero.
>

Yes, now I see it. (However, the continuation characters disappeared when
L2R text was entered on the line before the R2L text.)


> Also, I noticed that `window-max-chars-per-line' does not take into
> account the variable `left-frame-width' (and
> > presumably `right-frame-width').
>
> You mean left-fringe-width, I presume?  Yes, that's probably a bug.
>

Yes, I mean `left-fringe-width'.



> Why is this useful, when we already have window-max-chars-per-line?
> IOW, when would you like to know about the continuation glyph, and not
> about how many characters can be displayed on a line?
>

I intended it as a way to implement `window-max-chars-per-line' in a more
robust way than today.

In addition, I can think of a use case. If you want to create a window of a
specific width, excluding the continuation glyph, this can be used:

   (split-window-right (if (continuation-glyph-visible-p (selected-window))
                                  (+ width 1)
                                width))

    -- Anders

[-- Attachment #2: Type: text/html, Size: 2170 bytes --]

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Eli Zaretskii]

> Date: Fri, 15 Apr 2016 10:05:19 +0200
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22891@debbugs.gnu.org, martin rudalics <rudalics@gmx.at>
> 
>  To see what I meant, create a new buffer with "C-x b", then paste the
>  same text there, after setting the left fringe width to zero.
> 
> Yes, now I see it. (However, the continuation characters disappeared when L2R text was entered on the line
> before the R2L text.)

If there was no empty line between the L2R and the R2L lines, then
inserting that L2R line made the entire paragraph be L2R, and you are
back at what happened in *scratch*.  (How Emacs determines the base
paragraph direction is documented in the Emacs User manual, in the
node "Bidirectional Editing".)

> In addition, I can think of a use case. If you want to create a window of a specific width, excluding the
> continuation glyph, this can be used:
> 
> (split-window-right (if (continuation-glyph-visible-p (selected-window))

You can implement this using window-max-chars-per-line.

bug#22891: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[martin rudalics]

 >> Could you please try to bisect to find the offending commit?
 >
 > Yes, of course. It seems to have been commit 165bea78. Please let me
 > know if I can help further.

Thank you.  Let's see whether Daniel can help us (he'll get two mails
from me ;-))

martin

bug#22891:

[Anders Lindgren]

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

Hi!

I think that I already have solved this, but awaiting confirmation I
haven't committed the change. In short, when either fringe is zero, Emacs
reserves one column for a terminal-style continuation character. The
function `window-adjust-process-window-size' in window.el should use
`window-max-chars-per-line' rather than `window-body-width' to take the
continuation character into consideration.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22891#26 for details.

In that message I also suggested removing `term-window-width' and instead
use `window-max-chars-per-line', as both functions use a complex algorithm
to determine whether or not a column is reserved for the continuation
character. Well, since I wrote the suggestion, a bug was found and fixed in
`window-max-chars-per-line' while the bug still remains in
`term-window-width'...

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1029 bytes --]

bug#22891:

[Daniel Colascione]

[-- Attachment #1.1: Type: text/plain, Size: 974 bytes --]

On 04/23/2016 11:42 AM, Anders Lindgren wrote:
> Hi!
> 
> I think that I already have solved this, but awaiting confirmation I
> haven't committed the change. In short, when either fringe is zero,
> Emacs reserves one column for a terminal-style continuation character.
> The function `window-adjust-process-window-size' in window.el should use
> `window-max-chars-per-line' rather than `window-body-width' to take the
> continuation character into consideration.
> 
> See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22891#26 for details.
> 
> In that message I also suggested removing `term-window-width' and
> instead use `window-max-chars-per-line', as both functions use a complex
> algorithm to determine whether or not a column is reserved for the
> continuation character. Well, since I wrote the suggestion, a bug was
> found and fixed in `window-max-chars-per-line' while the bug still
> remains in `term-window-width'...

Sounds good to me.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#22891:

[martin rudalics]

 > I think that I already have solved this, but awaiting confirmation I
 > haven't committed the change.

Please either post a patch or install your changes.  From my experience,
Constantine very reliably confirms whether it will work or not.

martin

bug#22891:

[Anders Lindgren]

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

>
> Please either post a patch or install your changes.  From my experience,
> Constantine very reliably confirms whether it will work or not.


Message #26 contains a patch that fix the problem.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 472 bytes --]

bug#22891:

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 694 bytes --]

Hi!

Here comes a new patch with both changes. Unless anybody complains, I will
push it to "master".

Just a little concern: I just took a look at the Emacs lisp directory. I
estimate is that a majority (but no all) of calls to `window-width',
`window-text-width', and `window-body-width' really should be to
`window-max-chars-per-line'.

    -- Anders


On Sun, Apr 24, 2016 at 10:40 AM, martin rudalics <rudalics@gmx.at> wrote:

> > I think that I already have solved this, but awaiting confirmation I
> > haven't committed the change.
>
> Please either post a patch or install your changes.  From my experience,
> Constantine very reliably confirms whether it will work or not.
>
> martin
>

[-- Attachment #1.2: Type: text/html, Size: 1209 bytes --]

[-- Attachment #2: term.diff --]
[-- Type: text/plain, Size: 2050 bytes --]

diff --git a/lisp/term.el b/lisp/term.el
index 2d5d3e9..28be8c8 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -919,19 +919,6 @@ is buffer-local."
 
 (term-set-escape-char (or term-escape-char ?\C-c))
 
-(defvar overflow-newline-into-fringe)
-
-(defun term-window-width ()
-  (if (and (not (featurep 'xemacs))
-	   (display-graphic-p)
-	   overflow-newline-into-fringe
-	   ;; Subtract 1 from the width when any fringe has zero width,
-	   ;; not just the right fringe.  Bug#18601.
-	   (/= (frame-parameter nil 'left-fringe) 0)
-	   (/= (frame-parameter nil 'right-fringe) 0))
-      (window-body-width)
-    (1- (window-body-width))))
-
 \f
 (put 'term-mode 'mode-class 'special)
 
@@ -1018,7 +1005,7 @@ Entry to this mode runs the hooks on `term-mode-hook'."
   (setq buffer-display-table term-display-table)
   (set (make-local-variable 'term-home-marker) (copy-marker 0))
   (set (make-local-variable 'term-height) (1- (window-height)))
-  (set (make-local-variable 'term-width) (term-window-width))
+  (set (make-local-variable 'term-width) (window-max-chars-per-line))
   (set (make-local-variable 'term-last-input-start) (make-marker))
   (set (make-local-variable 'term-last-input-end) (make-marker))
   (set (make-local-variable 'term-last-input-match) "")
diff --git a/lisp/window.el b/lisp/window.el
index e086efb..9f63e86 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8560,10 +8560,10 @@ WINDOWS is a list of windows associated with PROCESS.  REDUCER is
 a two-argument function used to combine the widths and heights of
 the given windows."
   (when windows
-    (let ((width (window-body-width (car windows)))
+    (let ((width (window-max-chars-per-line (car windows)))
           (height (window-body-height (car windows))))
       (dolist (window (cdr windows))
-        (setf width (funcall reducer width (window-body-width window)))
+        (setf width (funcall reducer width (window-max-chars-per-line window)))
         (setf height (funcall reducer height (window-body-height window))))
       (cons width height))))
 

bug#22891:

[martin rudalics]

 > Here comes a new patch with both changes. Unless anybody complains, I will
 > push it to "master".

The fix for bug#22891 should go into emacs-25.  Otherwise, we release code
that worked for emacs 24.5.

 > Just a little concern: I just took a look at the Emacs lisp directory. I
 > estimate is that a majority (but no all) of calls to `window-width',
 > `window-text-width', and `window-body-width' really should be to
 > `window-max-chars-per-line'.

These should be probably fixed on master.

martin

bug#22891:

[Eli Zaretskii]

> Date: Tue, 26 Apr 2016 08:34:23 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 22891@debbugs.gnu.org, Constantine Vetoshev <vetoshev@gmail.com>
> 
>  > Here comes a new patch with both changes. Unless anybody complains, I will
>  > push it to "master".
> 
> The fix for bug#22891 should go into emacs-25.  Otherwise, we release code
> that worked for emacs 24.5.

I agree.

>  > Just a little concern: I just took a look at the Emacs lisp directory. I
>  > estimate is that a majority (but no all) of calls to `window-width',
>  > `window-text-width', and `window-body-width' really should be to
>  > `window-max-chars-per-line'.
> 
> These should be probably fixed on master.

Yes; and I'd prefer to see this discussed first, as I'm not so sure
the conclusion is correct.  This is a tricky issue; in particular, the
units in which window-max-chars-per-line measures are different from
those of the other functions, so the question is how the result is
being used, not just whether the character cell reserved for
continuation and truncation glyphs counts.

bug#22891:

[Constantine Vetoshev]

On Sun, Apr 24, 2016 at 12:07 PM, Anders Lindgren <andlind@gmail.com> wrote:
> Here comes a new patch with both changes. Unless anybody complains, I will
> push it to "master".

I applied this patch to the emacs-25 branch (as of commit ccb75d7),
and it works. Thank you!

PS: Sorry I didn't get a chance to test and reply earlier; I was away
this past weekend.

bug#22891:

[Anders Lindgren]

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

Hi!

> Here comes a new patch with both changes. Unless anybody complains, I will
> > push it to "master".
>
> The fix for bug#22891 should go into emacs-25.  Otherwise, we release code
> that worked for emacs 24.5.



I just pushed this to master. See
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5b5403289888efe8783ae6a405845b925f544ec1
for details.

If you think this is important enough to go into emacs-25, please merge it
to that branch as well.


> Just a little concern: I just took a look at the Emacs lisp directory. I
> > estimate is that a majority (but no all) of calls to `window-width',
> > `window-text-width', and `window-body-width' really should be to
> > `window-max-chars-per-line'.
>
> These should be probably fixed on master.


I agree to 100% -- it will require quite an effort as someone will have to
look at each instance and check if the continuation glyph should be
included or not. (That "someone" won't be me, though.)


Constantine Vetoshev:

>  applied this patch to the emacs-25 branch (as of commit ccb75d7),
and it works. Thank you!

Thanks for testing and confirming!

    -- Anders

[-- Attachment #2: Type: text/html, Size: 2267 bytes --]

bug#22891:

[Eli Zaretskii]

> Date: Tue, 26 Apr 2016 21:10:58 +0200
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 22891@debbugs.gnu.org, Constantine Vetoshev <vetoshev@gmail.com>
> 
>  The fix for bug#22891 should go into emacs-25. Otherwise, we release code
>  that worked for emacs 24.5.
> 
> I just pushed this to master. See
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5b5403289888efe8783ae6a405845b925f544ec1 for
> details.
> 
> If you think this is important enough to go into emacs-25, please merge it to that branch as well.

Cherry-pick, not merge.  With a "backport" in the log message, please.

bug#22891:

[Anders Lindgren]

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

>
> Cherry-pick, not merge.  With a "backport" in the log message, please.
>

Unfortunately, I'm new to git, so I have to read up on how to do that.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 512 bytes --]

bug#22891:

[Eli Zaretskii]

> Date: Tue, 26 Apr 2016 23:07:20 +0200
> From: Anders Lindgren <andlind@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 22891@debbugs.gnu.org, 
> 	Constantine Vetoshev <vetoshev@gmail.com>
> 
>  Cherry-pick, not merge. With a "backport" in the log message, please.
> 
> Unfortunately, I'm new to git, so I have to read up on how to do that.

In a nutshell, do the following in the emacs-25 branch's checkout:

   git cherry-pick -x SHA1 -e

where SHA1 is the hash of the commit you want to cherry-pick.  The -e
switch will let you edit the commit message, which is needed for
adding the "backport" thing.

Thanks.

bug#22891:

[Anders Lindgren]

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

Hi!


> In a nutshell, do the following in the emacs-25 branch's checkout:
>
>    git cherry-pick -x SHA1 -e
>
> where SHA1 is the hash of the commit you want to cherry-pick.  The -e
> switch will let you edit the commit message, which is needed for
> adding the "backport" thing.
>

Done!

Thanks for your support!

    -- Anders

[-- Attachment #2: Type: text/html, Size: 677 bytes --]

bug#22891: Fixed: 25.0.92; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS (again)

[Anders Lindgren]

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

This problem has been fixed and published on "master" and backported to
"emacs-25" (after being approved by Eli).

In the end it was not related to OS X. Instead, it was a function in
window.el used to by terminal windows to track the window width that didn't
take the continuation glyph into account. (The continuation glyph is
visible when the width of a fringe is zero.)

See the following for details:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5b5403289888efe8783ae6a405845b925f544ec1

http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=ff7e201ed87d206334afedd4366deebba440efde

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

bug#22891:

[martin rudalics]

> Thanks for your support!

Thanks for the fix!

martin