Eli Zaretskii wrote: > I'd like to solve this problem, not paper over it. I hope you agree > that solving it is better than working around it. Sure, given that it's practical to solve. > I find it hard to believe that we won't find the root cause, so I > think we don't need to consider that possibility. I'm glad to hear it! I'll do whatever I can to help you figure this out. :-) > Here are the first instructions to get information that will help us > start digging into this. (These are in addition to what Martin > already requested.) I've replied to Martin's request already. > First, please build Emacs without optimizations and with extra > checking code enabled: > > CFLAGS='-O0 -g3' ./configure --prefix=/home/felix/opt/emacs-24.4 --with-x-toolkit=athena --enable-checking='yes,glyphs' > > (I only care about CFLAGS and the --enable-checking= option; the rest > I just copied from your original report, but feel free to change them > if you want. The --enable-checking= option is required to compile the > dump-glyph-matrix command I ask you to use below.) Here is what Emacs says about the configuration step: Configured using: `configure --prefix=/home/felix/opt/emacs-24.4-debug --with-x-toolkit=athena --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'' I did a VPATH build, though. > After 'configure' finishes, invoke "make". You don't have to invoke > "make install", as Emacs can be run from the src/ directory where it > was built. I did that: ran it right away from the build directory. > Now start Emacs you've just build with "emacs -Q", type the "C-x d" > command that you say is sufficient to reproduce the problem, and then > type this: > > M-x dump-glyph-matrix RET > > This outputs to the standard error stream the description of the > internal data structure, called "glyph matrix", which Emacs maintains > for each window on a GUI frame. Please post that output (you may wish > to redirect stderr to a file when you invoke Emacs, to make that > easier). > > Please do this once for the "good" configuration, and another time for > the "bad" configuration, but please make sure you invoke Emacs the > same in both cases and type the same "C-x d" command in each case. The outputs of the 'dump-glyph-matrix' command for both the good and bad configurations are in the attached files 'dump-glyph-matrix-good.txt' and 'dump-glyph-matrix-bad.txt', respectively; they are identical, though. > Next, in the "bad" configuration and with the listing of /dev and > corrupted mode line displayed, type this: > > M-: (setq frame-resize-pixelwise t) RET > > Now carefully decrease the frame's height by dragging its upper or > lower edge with the mouse. Please drag it slowly and carefully, so > that the frame is resized one pixel at a time. After each resize, > please see if the mode line is no longer corrupted. Perhaps kill the > buffer and type "C-x d" again to make sure the corruption disappeared > for good. The first time the mode line stops being corrupted, type > > M-x dump-glyph-matrix RET > > again, and include this (3rd) output in your message. Also, please > tell how many pixels did you subtract from the original frame height > before the corruption disappeared (assuming it ever does). For the sake of precision I used the method suggested by Martin: evaluating the expression (while (y-or-n-p "decrease?") (set-frame-height nil (1- (frame-text-height)) nil t)) in the requested condition. In order to not be fooled by a spurious mode-line redrawing, I killed the buffer and invoked 'C-x d /dev RET' again and the glitch was gone, after one iteration (minus 1 pixel). The output of the command 'dump-glyph-matrix' is in the attached file named 'dump-glyph-matrix-bad-resized.txt'. This one is different from the other two. Then, to be sure I executed immediately the inverse procedure by evaluating the expression (while (y-or-n-p "increase?") (set-frame-height nil (1+ (frame-text-height)) nil t)) and therefore incrementing the frame's height by 1 pixel. After killing and getting again to the Dired buffer, the glitch was back. > Where are the instructions to use the debugger, you ask? Well, not > yet, but maybe after we see what the above tells us. I'm waiting for further instructions. :-P -- ,= ,-_-. =. Bruno FĂ©lix Rezende Ribeiro (oitofelix) [0x28D618AF] ((_/)o o(\_)) There is no system but GNU; `-'(. .)`-' GNU Linux-Libre is one of its official kernels; \_/ All software must be free as in freedom;