Ok, I think that I understand more of how the new layout works, and that I need to work on the pixel level. Hence, I drop my request to make the width of the fringes + scroll bars a multiple of the frame character width. The problem with the cursor leaving garbage in the right fringe still remains, though. -- Anders On Mon, Feb 24, 2014 at 11:53 AM, martin rudalics wrote: > >> 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 > > * 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 > > * 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 >