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

Full log

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 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: Tue, 17 May 2016 21:06:01 +0200

[Message part 1 (text/plain, inline)]

Hi!

I can repeat this using a slightly different recipe:

    emacs -Q
    (setq truncate-partial-width-windows nil)
    C-x 3
    C-x o
    C-u 37 x
       Here, the cursor which is in text area blinks, while the part in the
fringe doesn't.

       Wait until the the cursor stop blinking
    C-a
        Now, the right fringe contains half a cursor.

    -- Anders


On Tue, May 17, 2016 at 8:30 PM, Alan Third <alan <at> idiocy.org> wrote:

> martin rudalics <rudalics <at> gmx.at> writes:
>
> >> 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:
>
> I believe this behaviour is no longer present in Emacs 25.
>
> I don't think there's anything else in this bug report that needs
> addressed, and as such, I'll close it in a couple of weeks if nobody
> objects.
> --
> Alan Third
>

[Message part 2 (text/html, inline)]

Previous Next

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