bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a request: width of fringes + scroll bar should be full characters)

[martin rudalics <rudalics@gmx.at>]

 >> The pixel widths of fringes and scrollbars are customizable on a per
 >> frame/window basis so you should be able to set them up on you system
 >> as you need.  Does that fail?
 >
 >
 > Well, it's much more work to handle things on the pixel level than working
 > with characters as the base unit.
 >
 > For example, I'm currently writing a package to set up multiple
 > side-by-size windows. When figuring out a suitable frame width, I used to
 > multiply the number of side-by-side windows with the sum of the column
 > width and the width (in characters) of the fringe and scroll bars, to get
 > the number of characters to set the width to. Now, I would have to work on
 > the pixel level to do this properly -- this is much more error prone and I
 > can't use the code on old Emacs versions.

If you do that, you already preclude your code from working correctly on
maximized or fullscreen frames.  These might have widths that are not an
integral multiple of your character widths.  And toolkit scrollbars may
have a width that is not an integral multiple either - so you would have
to adjust the combined size anyway.

 > It doesn't help that functions doesn't seem to be designed to work
 > together, for example I would expect:
 >     (set-frame-size (selected-frame) (frame-pixel-width)
 > (frame-pixel-height) t)'
 > to be a no-op, but instead the frame increases its size both on the width
 > and on the height.

`set-frame-size' expects as argument the new _text_ width of the frame
and adds the width of fringes, a scrollbar and internal borders to that.

 > Another argument of not having a "odd" width is that when splitting windows
 > side-by-side, you will end up with an unused gap to the right of almost a
 > full character. Steps to repeat:
 >
 >     emacs -Q
 >     (setq truncate-partial-width-windows nil) C-j
 >     C-x 3
 >
 >         Here, the right window have an unused space between the rightmost
 > character and the fringe, the space is almost a character wide. It's not
 > possible to resize the frame manually to correct this, as the frame can
 > only be resized full characters (as it should be). (When
 > `truncate-partial-width-windows' is t, the gap is used to display a partial
 > character.)
 >
 > To conclude, I would be much happier if the sum of the fringes and the
 > scroll bar would be an even five characters rather than five characters and
 > one pixel, as it is today.
 >
 > The question is if this is due to some display bug (maybe OS X specific) or
 > if this is the way it is supposed to work now?

This used to happen with Emacs 24.3 here and should be gone now.  But OS
X still has the old extended fringes code in place - maybe that
interferes.  Could you try to remove it - I can't compile for OS X so I
won't do that.  If you want to know how, have a look at these changes:

2013-12-02  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>

	* xterm.h (struct scroll_bar): Remove member `fringe_extended_p'.

	* xterm.c (x_draw_fringe_bitmap, x_scroll_run): Remove code for
	fringe background extension.
	(x_scroll_bar_create): Remove variables `sb_left' and `sb_width',
	because they are now always the same as `left' and `width',
	respectively.  Remove code for the case that `width' and
	`sb_width' are different.

2013-12-21  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>

	* w32term.h (struct scroll_bar): Remove member `fringe_extended_p'.

	* w32term.c (w32_draw_fringe_bitmap, x_scroll_run): Remove code for
	fringe background extension.
	(x_scroll_bar_create): Remove variables `sb_left' and `sb_width',
	because they are now always the same as `left' and `width',
	respectively.  Remove code for the case that `width' and
	`sb_width' are different.

martin