February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Ediff control buffer defects (Was: Re: Fix window geometry) 24 years, 2 months

Markus Alt

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> on 02/26/2000 03:18:36 PM Please respond to Jan Vroonhof <vroonhof(a)math.ethz.ch> To: Markus Alt/Germany/IBM＠IBMDE cc: xemacs-beta(a)xemacs.org Subject: Re: Fix window geometry altmark(a)de.ibm.com writes: > control panel, and have gutter visible, XEmacs crashes when the mouse > pointer enters the ediff control buffer (I reported this some time ago: > http://www.xemacs.org/list-archives/xemacs-beta/199911/msg00101.html). > > Does this fix also cover this issue? Or is it a completely different 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;

1 participants
0 comments

Re: cvs removal of auto-autoloads.el and custom-loads.el 24 years, 2 months

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > I've just reversed Ben's change, since the Unix build was broken with > this change, and I didn't want to leave it in its broken state for too > long. Thanks. > The sad story appears to be that, just like a compiler that's > been incestuously compiling itself for too long, Unix XEmacs needs a > working auto-autoloads.el file to update the auto-autoloads.el file, > and I'm not up to fixing it tonight. > The very best fix would involve a rework of the entire build structure. Actually, it wouldn't. At a minimum, it would require a rewrite of autoload.el to run out of temacs, so that one could insert an autoloads generation step between creating temacs, and bytecompiling the dumped lisp. This is a pain for various reasons. If we could zap the entire interactive interface to autoloads generation it would be somewhat less painful. My preferred solution was to entirely zap autoloads from core lisp. This doesn't solve the custom loads problem, however, custom-loads.el isn't needed to get to an xemacs binary.

1 participants
0 comments

OT: Installing FreeBSD 24 years, 2 months

Kirill 'Big K' Katsnelson

I finally ceased by attempts to tame Linux, and trying to install FreeBSD 3.4. In the installer, I selected Novice installation, passed through fdisk, disk label, select packages menus, and stuck with "Select X components". In this menu, I have 6 choices: X Exit Exit this menu (go to previous) All Select All components Reset Resel All components Basic Basic component menu X Server Select X Server components fonts Font Set menu OK Cancel The last 3 options, when I select them and press Enter or space, bring up dialogs where I can chose (mark with X's) subcomponents. 'All' selects all checkboxes in these menus. 'Reset' resets them. 'X Exit' crashes the program with signal 11. FreeBSD gurus: How do I press OK in this dialog to get past it? TIA, Big K

1 participants
0 comments

kill-buffers-save-emacs 24 years, 2 months

Adrian Aichner

this is what I just tried after too much jet lag and a bit of Enzian[1]. Perhaps we should alias this to save-buffers-kill-emacs Adrian :-) Footnotes: [1] Gentiana Lutea L., calling it Schnaps would be an insult to this fine medicine.

1 participants
0 comments

Re: Gutters and resize-minibuffer-mode 24 years, 2 months

Adrian Aichner

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: Jan> Working through the remain glitches in order of annoyance. >> >> for 21.2, I assume? Jan> Yep. See subject. The subject in my mailbox sez: Subject: Re: Gutters and resize-minibuffer-mode Hmmh? Jan> xemacs -vanilla Jan> M-x resize-minibuffer-mode Jan> C-x C-f C-u 500 a >> >> This has annoyed me for a long time. Jan> For me it seems quite new (and least I cannot remember seeing it Jan> before 21.2.30 or so). >> Much to my surprise the above procedure leaves nothing to be desired >> in an XEmacs 21.1.9 built from a cvs update some minutes before Feb 23 >> 19:11 CET. Jan> It doesn't surprise me. For me 21.2 works fine too if you Jan> turn the gutters off. In the redisplay code there is a lot of Jan> ad hoc That's what you get when turning off new features ;-> I have the gutters turned on, of course. I'll try to find a testcase for my minibuffer annoyance, which may be unrelated after all... Best regards, Adrian Jan> window_height = WINDOW_HEIGHT(w) + WINDOW_SCROLLBAR_HEIGHT(w) - Jan> WINDOW_THIS(w) - WINDOW_THAT(w). Jan> Probably Andy put in a + GUTTER_HEIGHT to few or to many in there. Jan> Jan

1 participants
0 comments

Re: Gutters and resize-minibuffer-mode 24 years, 2 months

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Jan> Working through the remain glitches in order of annoyance. > > for 21.2, I assume? Yep. See subject. > Jan> xemacs -vanilla > Jan> M-x resize-minibuffer-mode > Jan> C-x C-f C-u 500 a > > This has annoyed me for a long time. For me it seems quite new (and least I cannot remember seeing it before 21.2.30 or so). > Much to my surprise the above procedure leaves nothing to be desired > in an XEmacs 21.1.9 built from a cvs update some minutes before Feb 23 > 19:11 CET. It doesn't surprise me. For me 21.2 works fine too if you turn the gutters off. In the redisplay code there is a lot of ad hoc window_height = WINDOW_HEIGHT(w) + WINDOW_SCROLLBAR_HEIGHT(w) - WINDOW_THIS(w) - WINDOW_THAT(w). Probably Andy put in a + GUTTER_HEIGHT to few or to many in there. Jan

1 participants
0 comments

Re: Gutters and resize-minibuffer-mode 24 years, 2 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: Jan> xemacs -vanilla Jan> M-x resize-minibuffer-mode Jan> C-x C-f C-u 500 a APA> This has annoyed me for a long time. APA> Much to my surprise the above procedure leaves nothing to be APA> desired in an XEmacs 21.1.9 built from a cvs update some APA> minutes before Feb 23 19:11 CET. APA> minibuffer risizes prefectly. It also works prefectly with all my site-start.el and .emacs customizations, which are manyfold[1]. APA> Best regards, APA> Adrian Footnotes: [1] available on request

1 participants
0 comments

Re: Gutters and resize-minibuffer-mode 24 years, 2 months

Adrian Aichner

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Working through the remain glitches in order of annoyance. for 21.2, I assume? Jan> [This started about the same time as the ispell window-size Jan> fixes went it.] Jan> xemacs -vanilla Jan> M-x resize-minibuffer-mode Jan> C-x C-f C-u 100 a Jan> Now the minibuffer is resized. However the modeline has moved Jan> much more upwards leaving behind artifacts from its Jan> shadow. After the minibuffer is size back the modeline never Jan> moves downwards until the frame is resized. Jan> Jan Jan> For really weird stuff, do Jan> xemacs -vanilla Jan> M-x resize-minibuffer-mode Jan> C-x C-f C-u 500 a This has annoyed me for a long time. Much to my surprise the above procedure leaves nothing to be desired in an XEmacs 21.1.9 built from a cvs update some minutes before Feb 23 19:11 CET. minibuffer risizes prefectly. Best regards, Adrian

1 participants
0 comments

Gutters and resize-minibuffer-mode 24 years, 2 months

Jan Vroonhof

Working through the remain glitches in order of annoyance. [This started about the same time as the ispell window-size fixes went it.] xemacs -vanilla M-x resize-minibuffer-mode C-x C-f C-u 100 a Now the minibuffer is resized. However the modeline has moved much more upwards leaving behind artifacts from its shadow. After the minibuffer is size back the modeline never moves downwards until the frame is resized. Jan For really weird stuff, do xemacs -vanilla M-x resize-minibuffer-mode C-x C-f C-u 500 a

1 participants
0 comments

New European XEmacs Mirror 24 years, 2 months

XEmacs Webmaster

A new XEmacs download location has been added to our list of distribution sites. This full mirror located in FRANCE can be reached through the following URLs: <URL:ftp://ftp.oleane.net/pub/xemacs/> <URL:http://ftp.oleane.net/pub/xemacs/> The most up-to-date list of mirror sites can always be be found at: <URL:http://www.xemacs.org/Download/> Enjoy.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta February 2000