bug#18601: 24.3.94; set-fringe-mode with left fringe 0 breaks window width calculations on Mac OS

[martin rudalics <rudalics@gmx.at>]

 > After (set-fringe-mode '(0 . 2)), executing (window--dump-frame) puts
 > the following contents into *window-frame-dump*:

 > frame pixel: 600 x 494   cols/lines: 86 x 35   units: 7 x 14

 > width left fringe: 0
 > width right fringe: 7

 > After (set-fringe-mode '(1 . 2)), executing (window--dump-frame) puts
 > the following contents into *window-frame-dump*:

 > body pixel: 574 x 462   char: 82 x 33
 > width left fringe: 3
 > width right fringe: 4

Here is the old fringe compensation code at work which apaprently adds 4
or 5 pixels to the specified value in order to get the sum of the widths
of the fringes equal to 7 (the frame's nominal character width).  I
removed that code for NS on Emacs 25 but never did so for Emacs 24-4.
Even now I don't know whether it works correctly (see also bug #16856).

In any case I don't see why this should have any impact on what happens
in ansi-term.  Apparently `term-window-width' kicks in and due to

(/= (frame-parameter nil 'right-fringe) 0))

it eventually stores in `term-width' a value that is one less than if
both fringes are present.

Since Eli now confirmed that what you observe is a result of one of his
fixes all I can suggest at the moment is to play with

(defun term-window-width ()
   (if (and (not (featurep 'xemacs))
	   (display-graphic-p)
	   overflow-newline-into-fringe
	   (/= (frame-parameter nil 'right-fringe) 0))
       (window-body-width)
     (1- (window-body-width))))

What happens when you make it always return (window-body-width)?

(defun term-window-width ()
   (window-body-width))

martin