Re: display margin errors on a tty
Richard Stallman [EMAIL PROTECTED] writes: It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. I think this is a good solution, if it works. It is simple, and it is safe. And the slowdown is insignificant compared with everything else that is going on when you change window sizes. However, KFS wrote No, the problem seems to come up as long as there is a window with a marginal area in use. Does that mean your fix doesn't actually solve the problem? It papers over it. An optimization in dispnew.c gets screwed up when display margins are present for terminal display. I just checked in a patch that basically disables the optimization when we are in that situation. So it's not *really* solving the problem. But it's a lot safer, and AFAICT it completely prevents the problem from appearing. So we can probably live with it for now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
It papers over it. An optimization in dispnew.c gets screwed up when display margins are present for terminal display. I just checked in a patch that basically disables the optimization when we are in that situation. So it's not *really* solving the problem. But it's a lot safer, and AFAICT it completely prevents the problem from appearing. So we can probably live with it for now. It looks good to me. Thanks. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Chong Yidong [EMAIL PROTECTED] writes: Could you test if the current window has non-empty left margin, and only set the garbaged flag in that case? No, the problem seems to come up as long as there is a window with a marginal area in use. It seems fairly easy to check all windows too see if that's the case. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. I think this is a good solution, if it works. It is simple, and it is safe. And the slowdown is insignificant compared with everything else that is going on when you change window sizes. However, KFS wrote No, the problem seems to come up as long as there is a window with a marginal area in use. Does that mean your fix doesn't actually solve the problem? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Chong Yidong [EMAIL PROTECTED] writes: I managed to reproduce the bug. emacs -nw M-: (set-window-margins (selected-window) 1) RET C-x 2 C-x ^ Pressing left and right button and inserting text now makes it clear that redisplay is broken. The call to enlarge-window and set-window-margins appears to be essential to producing this bug. I can't seem to track down this bug. There seems to be some subtle bug in the optimizations for reusing glyph matrices on text terminals, which only shows up when display margins are present. For the release, I propose the following hack. It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. I'll try to track this down completely after the release. Any objections? (I'll also insert the appropriate comments explaining the situation, of course.) *** emacs/src/window.c.~1.575.~ 2007-03-31 10:10:14.0 -0400 --- emacs/src/window.c 2007-04-14 11:43:03.0 -0400 *** *** 4415,4422 XSETFASTINT (p-last_modified, 0); XSETFASTINT (p-last_overlay_modified, 0); /* Adjust glyph matrices. */ ! adjust_glyphs (XFRAME (WINDOW_FRAME (XWINDOW (window; } --- 4415,4425 XSETFASTINT (p-last_modified, 0); XSETFASTINT (p-last_overlay_modified, 0); + if (!FRAME_WINDOW_P (WINDOW_XFRAME (XWINDOW (window + SET_FRAME_GARBAGED (WINDOW_XFRAME (XWINDOW (window))); + /* Adjust glyph matrices. */ ! adjust_glyphs (WINDOW_XFRAME (XWINDOW (window))); } ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
From: Chong Yidong [EMAIL PROTECTED] Date: Sat, 14 Apr 2007 11:58:53 -0400 It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. Are you sure redisplay is ``so fast''? what about remote connections via a slow link? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Eli Zaretskii [EMAIL PROTECTED] writes: It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. Are you sure redisplay is ``so fast''? what about remote connections via a slow link? I don't have a way to test this, but I believe the cost should be negligible even for that case. In the very worst case scenario it, will only lead to one extra screen redraw every time you do C-x ^. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Chong Yidong [EMAIL PROTECTED] writes: Eli Zaretskii [EMAIL PROTECTED] writes: It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. Are you sure redisplay is ``so fast''? what about remote connections via a slow link? I don't have a way to test this, but I believe the cost should be negligible even for that case. In the very worst case scenario it, will only lead to one extra screen redraw every time you do C-x ^. Could you test if the current window has non-empty left margin, and only set the garbaged flag in that case? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
[EMAIL PROTECTED] (Kim F. Storm) writes: Chong Yidong [EMAIL PROTECTED] writes: Eli Zaretskii [EMAIL PROTECTED] writes: It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. Are you sure redisplay is ``so fast''? what about remote connections via a slow link? I don't have a way to test this, but I believe the cost should be negligible even for that case. In the very worst case scenario it, will only lead to one extra screen redraw every time you do C-x ^. Could you test if the current window has non-empty left margin, and only set the garbaged flag in that case? No, the problem seems to come up as long as there is a window with a marginal area in use. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
I managed to reproduce the bug. emacs -nw M-: (set-window-margins (selected-window) 1) RET C-x 2 C-x ^ Pressing left and right button and inserting text now makes it clear that redisplay is broken. The call to enlarge-window and set-window-margins appears to be essential to producing this bug. A related error that may/may not help: when I do this I can only drag the mode-line in one direction. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
display margin errors on a tty
I might have reported this before but display seems all over the place when the buffer has a left margin in a tty. To see this start Emacs in an xterm, debug a program with M-x gdb, set a breakpoint, run and click alternately on the GUD and source buffer, or even repeatedly in the source buffer. The margin appears and disappears, so does the breakpoint symbol, B. Also various source lines get indented. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Nick Roberts [EMAIL PROTECTED] writes: I might have reported this before but display seems all over the place when the buffer has a left margin in a tty. To see this start Emacs in an xterm, debug a program with M-x gdb, set a breakpoint, run and click alternately on the GUD and source buffer, or even repeatedly in the source buffer. The margin appears and disappears, so does the breakpoint symbol, B. Also various source lines get indented. I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Nick Roberts [EMAIL PROTECTED] writes: I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. I got the mouse working, but I still don't see any problems. Notice that _if_ the margin is bound to the window, rather than the buffer, then calling set-window-buffer may clear the margin. Try setting left-margin-width in the buffer to see if it has a healing effect. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Nick Roberts [EMAIL PROTECTED] writes: I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. I can't seem to reproduce this, even with xterm-mouse-mode enabled. Can you give a more precise recipe? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
I managed to reproduce the bug. emacs -nw M-: (set-window-margins (selected-window) 1) RET C-x 2 C-x ^ Pressing left and right button and inserting text now makes it clear that redisplay is broken. The call to enlarge-window and set-window-margins appears to be essential to producing this bug. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. I can't seem to reproduce this, even with xterm-mouse-mode enabled. Can you give a more precise recipe? Actually now I can only seem to reproduce it when the xterm has a scrollbar (with or without xterm-mouse-mode). I thought I also saw it in the Linux console but I'm moving between machines/terminal types. It's probably best to disregard this bug report - sorry. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
