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

[martin rudalics]

> 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