Indeed, it does help! No more crash, on Linux as well as on AIX. But, umm ... there's another misbehaviour I already have forgotten about, as I had set ediff-window-setup-function to ediff-setup-windows-plain because of the aforesaid crash and this does not happen if you have no separate frame for the ediff control panel. If you *do have* one, have the toolbar for the ediff control panel enabled (i.e. ediff-use-toolbar-p set to t) and press the "Toggle split mode between side-to-side and one-on-top-of-another" button, all toolbar buttons except for the "A" and "B" buttons and the "filled space" between the "Help" and the "Quit" button disappear. (No matter whether the control panel is "small" or "large", i.e. short or long help is selected.) See attached GIF image. Selecting a different frame (e.g. the one showing the buffers to be ediff'ed) and then going back to the control panel makes all buttons reappear again (only on Linux, not on AIX). So does toggling between short and long help (on both Linux and AIX). As noted above, this does not happen with ediff-setup-windows-plain. This is 21.2.31, but I see it also with 21.1. Am I the only one having this weird behaviour or can anyone reproduce this? Markus (See attached file: control-panel.gif) Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; on 02/26/2000 03:18:36 PM Please respond to Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; To: Markus Alt/Germany/IBM＠IBMDE cc: xemacs-beta(a)xemacs.org Subject: Re: Fix window geometry altmark(a)de.ibm.com writes: story? Does my patch I posted in a separate thread help? Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.41 diff -u -u -r1.55.2.41 redisplay.c --- redisplay.c 2000/02/17 14:16:46 1.55.2.41 +++ redisplay.c 2000/02/24 17:48:24 ＠＠ -5157,6 +5157,9 ＠＠ else prop = 0; + /* Make sure this is set always */ + /* Note the conversion at end */ + w->window_end_pos[type] = start_pos; while (ypos < yend) { struct display_line dl; ＠＠ -5260,10 +5263,14 ＠＠ Dynarr_free (prop); /* #### More not quite right, but close enough. */ - /* #### Ben sez: apparently window_end_pos[] is measured + /* Ben sez: apparently window_end_pos[] is measured as the number of characters between the window end and the end of the buffer? This seems rather weirdo. What's - the justification for this? */ + the justification for this? + + JV sez: Because BUF_Z (b) would be a good initial value, however + that can change. This representation allows initalizing with 0. + */ w->window_end_pos[type] = BUF_Z (b) - w->window_end_pos[type]; if (need_modeline) ＠＠ -7553,11 +7560,20 ＠＠ displayed. The end of the last line is also know as the window end position. + WARNING: Under some circumstances it is possible that rediplay failed + to layout any lines for the windows. In that case this function returns + 0 as an error condition when may_error is non-zero and a normalized + value of startp otherwise. + Under normal circumstances this is rare. However it seems that it seems + that in can occur when computing the window a mouse event occured in and + the code their can handle the 0 error condition. + #### With a little work this could probably be reworked as just a call to start_with_line_at_pixpos. */ static Bufpos -start_end_of_last_line (struct window *w, Bufpos startp, int end) +start_end_of_last_line (struct window *w, Bufpos startp, int end, + int may_error) { struct buffer *b = XBUFFER (w->buffer); line_start_cache_dynarr *cache = w->line_start_cache; ＠＠ -7577,8 +7593,11 ＠＠ start_elt = point_in_line_start_cache (w, cur_start, 0); if (start_elt == -1) - abort (); /* this had better never happen */ - + { + stderr_out ("Soft assert triggered (start_end_of_last_line)\n"); + return may_error ? 0 : startp; + } + while (1) { int height = Dynarr_atp (cache, start_elt)->height; ＠＠ -7641,7 +7660,7 ＠＠ Bufpos start_of_last_line (struct window *w, Bufpos startp) { - return start_end_of_last_line (w, startp, 0); + return start_end_of_last_line (w, startp, 0 , 0); } /* For the given window W, if display starts at STARTP, what will be ＠＠ -7651,9 +7670,16 ＠＠ Bufpos end_of_last_line (struct window *w, Bufpos startp) { - return start_end_of_last_line (w, startp, 1); + return start_end_of_last_line (w, startp, 1, 0); } +static Bufpos +end_of_last_line_may_error (struct window *w, Bufpos startp) +{ + return start_end_of_last_line (w, startp, 1, 1); +} + + /* For window W, what does the starting position have to be so that the line containing POINT will cover pixel position PIXPOS. */ ＠＠ -8807,7 +8833,7 ＠＠ if (!MARKERP ((*w)->start[CURRENT_DISP])) *closest = 0; else - *closest = end_of_last_line (*w, + *closest = end_of_last_line_may_error (*w, marker_position ((*w)->start[CURRENT_DISP])); *col = 0; UPDATE_CACHE_RETURN;