Artifacts on the fringes

Artifacts on the fringes

[Óscar Fuentes]

After using Emacs for some minutes, characters on the fringes are not
always removed when they should. For instance, on Gnus an arrowhead is
displayed on the left fringe to indicate the current article on the
summary list; pressing `n' moves you to the next article and a new
arrowhead is displayed on the line below, but the old arrowhead is not
deleted. It is happening right now while I type this message: when a
line grows too long, it is wrapped and the indicators are shown on each
fringe; filling the paragraph (M-q) splits the long line but the
indicators stay.

Covering and uncovering the Emacs frame with some other application's
window (i.e. forcing a repaint) makes the stale characters go away from
the affected area.

I'm struggling to reproduce the problem on reasonable terms so I'm
commenting here just case it rings any bell. So far I can repro the
issue but with a non-trivial setup consisting on using a certain theme
(solarized) and running a custom command through `compile'.

I'm using today's Emacs on GNU/Linux (Lucid toolkit) but the problem
comes from some months ago. I think that it is not as bad as it used to
be so maybe some change ameliorated it recently.

Hints appreciated.

Re: Artifacts on the fringes

[Alex Bennée]

ofv@wanadoo.es writes:

> After using Emacs for some minutes, characters on the fringes are not
> always removed when they should. For instance, on Gnus an arrowhead is
> displayed on the left fringe to indicate the current article on the
> summary list; pressing `n' moves you to the next article and a new
> arrowhead is displayed on the line below, but the old arrowhead is not
> deleted. It is happening right now while I type this message: when a
> line grows too long, it is wrapped and the indicators are shown on each
> fringe; filling the paragraph (M-q) splits the long line but the
> indicators stay.
>
> Covering and uncovering the Emacs frame with some other application's
> window (i.e. forcing a repaint) makes the stale characters go away from
> the affected area.
<snip>

What WM manager are you using?

I'm seeing the same effect (with flycheck fringe elements) which
disappear if I focus on another window and then back in i3. It looks as
the a redraw event is not getting done.

-- 
Alex Bennée

Re: Artifacts on the fringes

[Óscar Fuentes]

Alex Bennée <kernel-hacker@bennee.com> writes:

> What WM manager are you using?

I'm using KDE 4.11.3.

> I'm seeing the same effect (with flycheck fringe elements) which
> disappear if I focus on another window and then back in i3. It looks as
> the a redraw event is not getting done.

AFAIK redrawing the fringe when its contents change is something that
Emacs does independently of the window manager.

It is good to know that I'm not the only one experiencing this problem.

Re: Artifacts on the fringes

[Nix]

On 21 Jan 2014, Óscar Fuentes said:

> Alex Bennée <kernel-hacker@bennee.com> writes:
>
>> What WM manager are you using?
>
> I'm using KDE 4.11.3.
>
>> I'm seeing the same effect (with flycheck fringe elements) which
>> disappear if I focus on another window and then back in i3. It looks as
>> the a redraw event is not getting done.
>
> AFAIK redrawing the fringe when its contents change is something that
> Emacs does independently of the window manager.
>
> It is good to know that I'm not the only one experiencing this problem.

It is certainly not universal: using fvwm and a recent Emacs (2.6.x) and
making fairly heavy use of the fringes, I have never seen it.

-- 
NULL && (void)

Re: Artifacts on the fringes

[Óscar Fuentes]

Nix <nix@esperi.org.uk> writes:

>> AFAIK redrawing the fringe when its contents change is something that
>> Emacs does independently of the window manager.
>>
>> It is good to know that I'm not the only one experiencing this problem.
>
> It is certainly not universal: using fvwm and a recent Emacs (2.6.x) and
> making fairly heavy use of the fringes, I have never seen it.

I'm using Bozhidar Batsov's solarized-dark theme. With

(setq solarized-distinct-fringe-background t)

the problem happened /almost/ predictably with my configuration (not
with Emacs -Q). It also happened without that setq but not predictably
at all. That's odd because the effect of that variable is just selecting
among two possible background colors for the fringe.

After updating the theme to the latest git sources and 5 days of Emacs
usage, the fringe display still works fine. AFAIK nothing changed on the
theme spec wrt the fringe.

Re: Artifacts on the fringes

[Nix]

On 29 Jan 2014, nix@esperi.org.uk uttered the following:
> It is certainly not universal: using fvwm and a recent Emacs (2.6.x) and

Hm, that got garbaged a bit. fvwm is 2.6.0, not Emacs, obviously :)

-- 
NULL && (void)

Re: Artifacts on the fringes

[David Engster]

Óscar Fuentes writes:
> Nix <nix@esperi.org.uk> writes:
>
>>> AFAIK redrawing the fringe when its contents change is something that
>>> Emacs does independently of the window manager.
>>>
>>> It is good to know that I'm not the only one experiencing this problem.
>>
>> It is certainly not universal: using fvwm and a recent Emacs (2.6.x) and
>> making fairly heavy use of the fringes, I have never seen it.
>
> I'm using Bozhidar Batsov's solarized-dark theme. With
>
> (setq solarized-distinct-fringe-background t)
>
> the problem happened /almost/ predictably with my configuration (not
> with Emacs -Q). It also happened without that setq but not predictably
> at all. That's odd because the effect of that variable is just selecting
> among two possible background colors for the fringe.
>
> After updating the theme to the latest git sources and 5 days of Emacs
> usage, the fringe display still works fine. AFAIK nothing changed on the
> theme spec wrt the fringe.

I noticed this for a while as well, and today I finally managed to
reliably reproduce it. At least in my case, the fringe doesn't correctly
get updated when you switch to(!) a buffer where

 - point is on a tabulator
 - there's an overlay from beginning to end of line
 - that overlay has a face background identical to the fringe color

No wonder not many people are seeing this... In my case, this was
usually triggered by the Magit status buffer, where the list of changed
files is indented with tabulators, and the files are highlighted with
the face `magit-item-highlight'. I'm using Bozhidar Batsov's zenburn
theme, and there this face has the same background color as the fringe.

This is now bug#16932, probably the weirdest one I've ever filed...

-David