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

Previous Next

Package: emacs;

Reported by: Anders Lindgren <andlind <at> gmail.com>

Date: Sun, 23 Feb 2014 21:41:02 UTC

Severity: normal

Tags: unreproducible

Found in version 24.3.50

Done: Anders Lindgren <andlind <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 16856 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a
 request: width of fringes + scroll bar should be full characters)
Date: Mon, 24 Feb 2014 16:12:38 +0100
[Message part 1 (text/plain, inline)]
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 <rudalics <at> gmx.at> 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  <mituharu <at> 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 <at> 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
>
[Message part 2 (text/html, inline)]

This bug report was last modified 7 years and 192 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.