bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Robert Dallas Gray]

On starting emacs and entering linum-mode, with a vertical split,
vertical border periodically disappears or becomes 'broken' while scrolling.

Changing fringe-mode to left-only fixes the problem, but only if it is
done in the minibuffer. Using fringe-mode, set-fringe-mode or
set-fringe-style from lisp code does not help.


In GNU Emacs 24.1.50.1 (i386-apple-darwin11.4.0, NS apple-appkit-1138.47)
of 2012-05-24 on pud.default
Windowing system distributor `Apple', version 10.3.1138
Configured using:
`configure '--prefix=/usr/local/Cellar/emacs/HEAD' '--without-dbus'
'--enable-locallisppath=/usr/local/share/emacs/site-lisp'
'--infodir=/usr/local/Cellar/emacs/HEAD/share/info/emacs' '--with-ns'
'--disable-ns-self-contained' 'CC=/usr/bin/llvm-gcc' 'CFLAGS=-Os -w
-pipe -march=core2 -msse4''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Speedbar

Minor modes in effect:
  multi-web-global-mode: t
  show-paren-mode: t
  global-smart-tab-mode: t
  cua-mode: t
  global-auto-revert-mode: t
  autopair-global-mode: t
  ido-everywhere: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t <return>

Recent messages:
Loading /Users/robertdallasgray/.emacs.d/custom.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
~/.emacs.d/custom hides /Applications/Emacs.app/Contents/Resources/lisp/custom
/Users/robertdallasgray/.emacs.d/elpa/magit-20120805/.dir-locals hides /Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils graphene-theme
solarized-light-theme solarized-definitions multi-web-mode php+-mode
php+-zf php-test php-tags etags php-string php-refactor php-lineup
php-help php-font-lock php-edit php-format php-structure php-utils
hideshow php-doc php-project dired php-funcs thingatpt php-parse
string-utils php-const php-completion cc-langs cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs paren
smart-tab easy-mmode ace-jump-mode cua-base autorevert autopair
expand-region expand-region-custom expand-region-core edmacro kmacro
smex ido sr-speedbar warnings cl speedbar sb-image ezimage dframe
easymenu tramp tramp-compat auth-source gnus-util mm-util mail-prsvr
password-cache shell pcomplete comint ansi-color ring format-spec advice
help-fns advice-preload tramp-loaddefs ace-jump-mode-autoloads
autopair-autoloads coffee-mode-autoloads color-theme-solarized-autoloads
color-theme-autoloads expand-region-autoloads flymake-coffee-autoloads
flymake-css-autoloads flymake-jslint-autoloads flymake-php-autoloads
flymake-ruby-autoloads gh-autoloads eieio byte-opt bytecomp byte-compile
cconv macroexp logito-autoloads magit-push-remote-autoloads
magit-simple-keys-autoloads magithub-autoloads magit-autoloads
markdown-mode-autoloads multi-web-mode-autoloads nginx-mode-autoloads
pcache-autoloads finder-inf php+-mode-autoloads popup-autoloads
rainbow-mode-autoloads rsense-autoloads smart-tab-autoloads
smex-autoloads yaml-mode-autoloads package time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process ns multi-tty emacs)

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Eli Zaretskii]

> From: Robert Dallas Gray <mail@robertdallasgray.com>
> Date: Sat, 25 Aug 2012 15:43:05 +0100
> 
> On starting emacs and entering linum-mode, with a vertical split,
> vertical border periodically disappears or becomes 'broken' while scrolling.
> 
> Changing fringe-mode to left-only fixes the problem, but only if it is
> done in the minibuffer. Using fringe-mode, set-fringe-mode or
> set-fringe-style from lisp code does not help.

Could you please provide a detailed recipe, starting with "emacs -Q",
for reproducing the problem?  I cannot reproduce this on my system,
but I'm not sure I understood the procedure (e.g., what are "vertical
split" and "vertical border"?).

Also, you are using a very old snapshot of the development sources;
could you update to the latest code and see if the problem is still
there?

Thanks.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Robert Dallas Gray]

On 25 Aug 2012, at 20:01, Eli Zaretskii wrote:

>> From: Robert Dallas Gray <mail@robertdallasgray.com>
>> Date: Sat, 25 Aug 2012 15:43:05 +0100
>> 
>> On starting emacs and entering linum-mode, with a vertical split,
>> vertical border periodically disappears or becomes 'broken' while scrolling.
>> 
>> Changing fringe-mode to left-only fixes the problem, but only if it is
>> done in the minibuffer. Using fringe-mode, set-fringe-mode or
>> set-fringe-style from lisp code does not help.
> 
> Could you please provide a detailed recipe, starting with "emacs -Q",
> for reproducing the problem?  I cannot reproduce this on my system,
> but I'm not sure I understood the procedure (e.g., what are "vertical
> split" and "vertical border"?).
> 
> Also, you are using a very old snapshot of the development sources;
> could you update to the latest code and see if the problem is still
> there?
> 
> Thanks.

Bearing in mind this affects Cocoa Emacs on OS X, in windowed mode:

cd /Applications/Emacs.app/Contents/MacOS
./Emacs -Q
M-x scroll-bar-mode (to turn scroll bars off)
(now visit a file with contents large enough to require scrolling)
C-x 3 (to split the window vertically)
M-x linum-mode

Now scroll the right-hand window (using the mouse wheel seems to reproduce the glitch more often). The black vertical bar between the two windows intermittently disappears or becomes 'broken'.

Enlarging the window beyond the default startup size also seems to help reproduce the bug.

I have a screenshot of the bug occurring, but I'm not sure on the rules for posting images here.

I've just checked the default gtk+ version of Emacs in Ubuntu (which is v23) and am able to reproduce the bug there also).

Also confirmed the bug exists in Cocoa Emacs 24.1.50 HEAD.

I have found a workaround for this by doing:

(set-fringe-mode '(0 . 8))

in init.el (it seems the fringe-mode [mnemonic] command doesn't work properly when used from lisp code.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Eli Zaretskii]

> From: Robert Dallas Gray <mail@robertdallasgray.com>
> Date: Mon, 27 Aug 2012 09:37:14 +0100
> 
> Bearing in mind this affects Cocoa Emacs on OS X, in windowed mode:
> 
> cd /Applications/Emacs.app/Contents/MacOS
> ./Emacs -Q
> M-x scroll-bar-mode (to turn scroll bars off)
> (now visit a file with contents large enough to require scrolling)
> C-x 3 (to split the window vertically)
> M-x linum-mode
> 
> Now scroll the right-hand window (using the mouse wheel seems to reproduce the glitch more often). The black vertical bar between the two windows intermittently disappears or becomes 'broken'.

When the vertical line separating the two windows disappears or
becomes broken, does it get corrected if you wait for a while, or does
it stay corrupted forever, until the next scroll?

FWIW, all I see on my MS-Windows machine is slow scrolling (due to
linum-mode), but no redisplay problems.

> I have a screenshot of the bug occurring, but I'm not sure on the rules for posting images here.

Please do post the screenshots.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Robert Dallas Gray]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]


On 31 Aug 2012, at 10:05, Eli Zaretskii wrote:

>> From: Robert Dallas Gray <mail@robertdallasgray.com>
>> Date: Mon, 27 Aug 2012 09:37:14 +0100
>> 
>> Bearing in mind this affects Cocoa Emacs on OS X, in windowed mode:
>> 
>> cd /Applications/Emacs.app/Contents/MacOS
>> ./Emacs -Q
>> M-x scroll-bar-mode (to turn scroll bars off)
>> (now visit a file with contents large enough to require scrolling)
>> C-x 3 (to split the window vertically)
>> M-x linum-mode
>> 
>> Now scroll the right-hand window (using the mouse wheel seems to reproduce the glitch more often). The black vertical bar between the two windows intermittently disappears or becomes 'broken'.
> 
> When the vertical line separating the two windows disappears or
> becomes broken, does it get corrected if you wait for a while, or does
> it stay corrupted forever, until the next scroll?

It stays corrupted until the next scroll (or M-x redraw-display, or a window resize).

> FWIW, all I see on my MS-Windows machine is slow scrolling (due to
> linum-mode), but no redisplay problems.
> 

I wasn't able to reproduce it in Emacs 24.1 on Windows 7.

>> I have a screenshot of the bug occurring, but I'm not sure on the rules for posting images here.
> 
> Please do post the screenshots.

Attached.


[-- Attachment #2.1: Type: text/html, Size: 2445 bytes --]

[-- Attachment #2.2: Screen Shot 2012-08-26 at 11.12.22.png --]
[-- Type: image/png, Size: 240737 bytes --]

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

Hello.

This is similar but not the same as 11052.

This is reproducable on Gtk and Lucid so I think it is a general redisplay problem.  It is harder to reproduce on those platforms, as they seem to redraw more often.  It may also be a timing issue.
But I found a simpler way to reproduce the bug:

./emacs -Q
M-x scroll-bar-mode (to turn off scrollbars).
C-x 3
M-x linum-mode

Then double-click on a line to mark a word on that line.  The redisplay engine will then redraw the whole line, but the black border between windows will be gone from that line and to the end of the window (why Emacs redisplays from the marked word to the end of the window I don't know, it does not seem efficient).

Screenshots attached, taken from a lucid build.  If you look at the zoomed in version, you can see that if you extend the one-pixel black line down to the "4", it would actually draw over pixels belonging to the "4", thus indicating that this bug is due to the display engine redrawing line numbers over the black line.

This recepie also shows that there are cursor redrawing bugs in the X port, remnants show up in the line number column.  But that is a separate issue :-).

	Jan D.





3 sep 2012 kl. 12:38 skrev Robert Dallas Gray <mail@robertdallasgray.com>:

> 
> On 31 Aug 2012, at 10:05, Eli Zaretskii wrote:
> 
>>> From: Robert Dallas Gray <mail@robertdallasgray.com>
>>> Date: Mon, 27 Aug 2012 09:37:14 +0100
>>> 
>>> Bearing in mind this affects Cocoa Emacs on OS X, in windowed mode:
>>> 
>>> cd /Applications/Emacs.app/Contents/MacOS
>>> ./Emacs -Q
>>> M-x scroll-bar-mode (to turn scroll bars off)
>>> (now visit a file with contents large enough to require scrolling)
>>> C-x 3 (to split the window vertically)
>>> M-x linum-mode
>>> 
>>> Now scroll the right-hand window (using the mouse wheel seems to reproduce the glitch more often). The black vertical bar between the two windows intermittently disappears or becomes 'broken'.
>> 
>> When the vertical line separating the two windows disappears or
>> becomes broken, does it get corrected if you wait for a while, or does
>> it stay corrupted forever, until the next scroll?
> 
> It stays corrupted until the next scroll (or M-x redraw-display, or a window resize).
> 
>> FWIW, all I see on my MS-Windows machine is slow scrolling (due to
>> linum-mode), but no redisplay problems.
>> 
> 
> I wasn't able to reproduce it in Emacs 24.1 on Windows 7.
> 
>>> I have a screenshot of the bug occurring, but I'm not sure on the rules for posting images here.
>> 
>> Please do post the screenshots.
> 
> Attached.
> 
> <Screen Shot 2012-08-26 at 11.12.22.png>


[-- Attachment #2.1: Type: text/html, Size: 4089 bytes --]

[-- Attachment #2.2: border.png --]
[-- Type: image/png, Size: 7746 bytes --]

[-- Attachment #2.3: border-zoomed.png --]
[-- Type: image/png, Size: 13267 bytes --]

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 8 Sep 2012 14:22:39 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  12277@debbugs.gnu.org
> 
> But I found a simpler way to reproduce the bug:
> 
> ./emacs -Q
> M-x scroll-bar-mode (to turn off scrollbars).
> C-x 3
> M-x linum-mode
> 
> Then double-click on a line to mark a word on that line.  The redisplay engine will then redraw the whole line, but the black border between windows will be gone from that line and to the end of the window

Thanks, I can reproduce this here.  Will take a look when I have time.

> why Emacs redisplays from the marked word to the end of the window I
> don't know, it does not seem efficient

Probably because the 'region' face can specify a different font,
which, if its size is significantly different from the default, could
require redrawing of more than one screen line.  Perhaps it's possible
to invent optimizations that redraw less in at least some of the
cases, but no one has come up with such optimizations, and I'm not
sure it's worth our while.  Each optimization adds to the complexity
of the display engine, so IMO we should only introduce new ones if the
normal redisplay is unbearably slow.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Eli Zaretskii]

> Date: Sat, 08 Sep 2012 16:01:38 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: mail@robertdallasgray.com, 12277@debbugs.gnu.org
> 
> > From: Jan Djärv <jan.h.d@swipnet.se>
> > Date: Sat, 8 Sep 2012 14:22:39 +0200
> > Cc: Eli Zaretskii <eliz@gnu.org>,
> >  12277@debbugs.gnu.org
> > 
> > But I found a simpler way to reproduce the bug:
> > 
> > ./emacs -Q
> > M-x scroll-bar-mode (to turn off scrollbars).
> > C-x 3
> > M-x linum-mode
> > 
> > Then double-click on a line to mark a word on that line.  The redisplay engine will then redraw the whole line, but the black border between windows will be gone from that line and to the end of the window
> 
> Thanks, I can reproduce this here.  Will take a look when I have time.

Should be fixed in trunk revision 109957.  Please test.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 8 Sep 2012 14:22:39 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  12277@debbugs.gnu.org
> 
> This recepie also shows that there are cursor redrawing bugs in the X port, remnants show up in the line number column.  But that is a separate issue :-).

Fixed this one as well, in trunk revision 109958, please test.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Jan Djärv]

Hello.

9 sep 2012 kl. 20:02 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Sat, 08 Sep 2012 16:01:38 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: mail@robertdallasgray.com, 12277@debbugs.gnu.org
>> 
>>> From: Jan Djärv <jan.h.d@swipnet.se>
>>> Date: Sat, 8 Sep 2012 14:22:39 +0200
>>> Cc: Eli Zaretskii <eliz@gnu.org>,
>>> 12277@debbugs.gnu.org
>>> 
>>> But I found a simpler way to reproduce the bug:
>>> 
>>> ./emacs -Q
>>> M-x scroll-bar-mode (to turn off scrollbars).
>>> C-x 3
>>> M-x linum-mode
>>> 
>>> Then double-click on a line to mark a word on that line.  The redisplay engine will then redraw the whole line, but the black border between windows will be gone from that line and to the end of the window
>> 
>> Thanks, I can reproduce this here.  Will take a look when I have time.
> 
> Should be fixed in trunk revision 109957.  Please test.

Confirmed on OSX and X11.

	Jan D.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Jan Djärv]

Hello.

9 sep 2012 kl. 22:12 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sat, 8 Sep 2012 14:22:39 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> 12277@debbugs.gnu.org
>> 
>> This recepie also shows that there are cursor redrawing bugs in the X port, remnants show up in the line number column.  But that is a separate issue :-).
> 
> Fixed this one as well, in trunk revision 109958, please test.

This is also ok now.  Good work.

	Jan D.

bug#12277: 24.1.50; Graphical issues with linum-mode and fringe

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Mon, 10 Sep 2012 16:54:49 +0200
> Cc: mail@robertdallasgray.com,
>  12277@debbugs.gnu.org
> 
> Hello.
> 
> 9 sep 2012 kl. 20:02 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> >> Date: Sat, 08 Sep 2012 16:01:38 +0300
> >> From: Eli Zaretskii <eliz@gnu.org>
> >> Cc: mail@robertdallasgray.com, 12277@debbugs.gnu.org
> >> 
> >>> From: Jan Djärv <jan.h.d@swipnet.se>
> >>> Date: Sat, 8 Sep 2012 14:22:39 +0200
> >>> Cc: Eli Zaretskii <eliz@gnu.org>,
> >>> 12277@debbugs.gnu.org
> >>> 
> >>> But I found a simpler way to reproduce the bug:
> >>> 
> >>> ./emacs -Q
> >>> M-x scroll-bar-mode (to turn off scrollbars).
> >>> C-x 3
> >>> M-x linum-mode
> >>> 
> >>> Then double-click on a line to mark a word on that line.  The redisplay engine will then redraw the whole line, but the black border between windows will be gone from that line and to the end of the window
> >> 
> >> Thanks, I can reproduce this here.  Will take a look when I have time.
> > 
> > Should be fixed in trunk revision 109957.  Please test.
> 
> Confirmed on OSX and X11.

Thanks, I'm closing the bug.

bug#12277: Thanks

[Robert Dallas Gray]

Marvellous, that fixes it for me, along with miscellaneous other screen glitches. Thank you.

Robert