September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [crash] redisplay after widening 27 years

Gunnar Evermann

I have now gotten a bit closer to fixing the redisplay bug related to widening. As mentioned earlier the problem is that the redisplay start-marker is not set correctly and that the line start cache contains a bogus entry (this actually causes the crash in 21.0). The problem is to detect in redisplay if this situation occurs. One approach that works in some cases is to rely on the start_at_line_beg member of the window structure. When this is true and we are not at the line beginning we have to readjust the marker. The problem with this approach is that 'start_at_line_beg' is not always set correctly. The appended patch partially corrects this. We still lose if start is not at the beginning of a line before widening. Unless I have missed something this is only supposed to happen with long wrapped lines. In this case we seem to produce bogus line_start_cache entries anyway (unrelated to narrowing/widening). I need to look at this more closely. Also I have to check where start_at _line_beg gets clobbered. I guess we could put this patch in 21.0 if some redisplay-experts agree, after all it fixes Collin's reproduction recipe, but it's still possible to get crashes after some scrolling. For 21.2 I plan to examine in more detail in which cases startp is allowed to be in the middle of a line and what to enter in the cache then. Helpful comments are always appreciated. Gunnar Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/redisplay.c,v retrieving revision 1.55 diff -u -r1.55 redisplay.c --- redisplay.c 1998/06/30 06:36:00 1.55 +++ redisplay.c 1998/09/07 17:03:12 ＠＠ -5066,7 +5066,10 ＠＠ temporary change to the echo area. */ && !(MINI_WINDOW_P (w) && f->buffers_changed) && !f->frame_changed - && !truncation_changed) + && !truncation_changed + /* check whether start is really at the begining of a line GE */ + && (!w->start_at_line_beg || beginning_of_line_p (b, startp))) { /* Check if the cursor has actually moved. */ if (EQ (Fmarker_buffer (w->last_point[CURRENT_DISP]), w->buffer) Index: window.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/window.c,v retrieving revision 1.41 diff -u -r1.41 window.c --- window.c 1998/06/30 06:36:06 1.41 +++ window.c 1998/09/07 17:03:17 ＠＠ -3163,7 +3163,9 ＠＠ make_int (XBUFFER (buffer)->last_window_start), buffer); Fset_marker (w->sb_point, w->start[CURRENT_DISP], buffer); - w->start_at_line_beg = 0; + /* set start_at_line_beg correctly. GE */ + w->start_at_line_beg = beginning_of_line_p (XBUFFER (buffer), + XBUFFER (buffer)->last_window_start); w->force_start = 0; /* Lucid fix */ SET_LAST_MODIFIED (w, 1); SET_LAST_FACECHANGE (w);

1 participants
0 comments

Re: Not for 21.0: mswindows font selection dialog 27 years

Jan Vroonhof

Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: > Patch is against 21.0 pre12 "Irish Goat". Adds an "Options / Font..." > font selection dialog to mswindows frames. The resulting font is _not_ > saved by "Options / Save Options" because it is not registered with > customize. This remains to be fixed. Note that Irish Goat contains patches by me to this for the X version. I tried making the interface funtion 'custom-set-face-update-spec' as general as possible so it should work for you. Jan

1 participants
0 comments

[Urgent] Missing part of font-menu patch 27 years

Jan Vroonhof

Alas, this part of the font-menu patch didn't make it into p55. 1998-08-27 Jan Vroonhof <vroonhof(a)math.ethz.ch> * x-font-menu.el (font-menu-set-font): Add "pt" units to size argument. Index: x-font-menu.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/x-font-menu.el,v retrieving revision 1.2 diff -u -u -r1.2 x-font-menu.el --- x-font-menu.el 1998/09/06 03:11:11 1.2 +++ x-font-menu.el 1998/09/07 18:38:02 ＠＠ -494,8 +494,8 ＠＠ (when (and family (not (equal family from-family))) (setq new-props (append (list :family family) new-props))) (when (and size (not (equal size from-size))) - (setq new-props (append (list :size (int-to-string - (/ size 10))) new-props))) + (setq new-props (append (list :size (concat (int-to-string + (/ size 10)) "pt")) new-props))) (custom-set-face-update-spec 'default '((type x)) new-props) ;;; WMP - we need to honor font-menu-this-frame-only-p here! ; (set-face-font 'default new-default-face-font

1 participants
0 comments

Re: Experimental implementation of extent modification hooks 27 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > This patch is *not* meant for application to any XEmacs. > > So I didn't and just looked at the patch :-) These are just some > stupid remarks. I cannot say anything other about the implementation > other than it looks surprisingly simple. > > > * insdel.c (signal_before_change): Don't check for Armageddon. > > Why? Or is Armageddon gone totally now? Because most of Armageddon checks were wrong. I see no reason why XEmacs should be completely hosed (ignoring hooks is what I call hosed) when exiting. As an example: there used to be code in save_excursion_save() that simply ignored the whole save-excursion if preparing_for_armageddon. If that's not bogus, I don't know what is. > > + /* #### It's a shame that we can't use any of the existing run_hook* > > + functions here. This is so because all of them work with > > + symbols, to be able to retrieve default values of local hooks. > > + <sigh> */ > > Shouldn't that be changed then? The change is non-trivial. If you wish to write it, go ahead! -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- HOW YOU CAN TELL THAT IT'S GOING TO BE A ROTTEN DAY: #15 Your pet rock snaps at you.

1 participants
0 comments

Re: Experimental implementation of extent modification hooks 27 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > This patch is *not* meant for application to any XEmacs. So I didn't and just looked at the patch :-) These are just some stupid remarks. I cannot say anything other about the implementation other than it looks surprisingly simple. > * insdel.c (signal_before_change): Don't check for Armageddon. Why? Or is Armageddon gone totally now? > + /* #### It's a shame that we can't use any of the existing run_hook* > + functions here. This is so because all of them work with > + symbols, to be able to retrieve default values of local hooks. > + <sigh> */ Shouldn't that be changed then? Jan

1 participants
0 comments

Re: Missing png leak fix 27 years

Jareth Hein

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> [1 <text/plain; us-ascii (7bit)>] This didn't make it into Andy> b55. I didn't see it vetoed and there's definietly a leak wrt Andy> png support. Andy> andy Andy> 1998-08-28 Andy Piper <andyp(a)parallax.co.uk> Andy> * glyphs-eimage.c (png_instantiate_unwind): clean up eimage Andy> after use. Reviewed and approved... (jareth is asleep at the keyboard...) -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder

1 participants
0 comments

The chicken or the egg? -or- Tastes great or less filling? 27 years

SL Baur

I'm going to be making an intermediate package update tomorrow/later today. Please do at least some rudimentary testing of it. For release it is my intention to rebytecompile and repackage all the packaged lisp prior to having someone cons up the SUMO tarball (the ancient Gnus 5.4 package dies, there is no reason to keep it around any more). If there are any dissenting opinions that this isn't the Right Thing to do, please let me know now. Thanks. I expect to have core distribution tarballs and preliminary lisp package tarballs out sometime before midnight and after some testing make the 'net announcement sometime later this week depending upon further input from Jason.

1 participants
0 comments

Missing png leak fix 27 years

Andy Piper

This didn't make it into b55. I didn't see it vetoed and there's definietly a leak wrt png support. andy 1998-08-28 Andy Piper <andyp(a)parallax.co.uk> * glyphs-eimage.c (png_instantiate_unwind): clean up eimage after use. --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Re: Egcs flaming rubble 27 years

SL Baur

P E Jareth Hein <jareth(a)camelot.co.jp> writes in xemacs-beta(a)xemacs.org: > I just tried to build 'Irish' with egcs-1.1b (which reports itself as > egcs-2.91.57) and got a flaming crash whilst trying to dump. I got my first pgcc/egcs-related crash with 1.1a. Turn down the optimization. I had to add the now-familiar pgcc flags `-fno-risc -fno-peep-spills'. I think these are named something different in pure egcs.

1 participants
0 comments

Re: XEmacs 21.0-pre12 "Irish Goat" is released 27 years

Andy Piper

SL Baur <steve(a)xemacs.org> writes: > If we can't hit that, it'll be October at the soonest. I'd just as > soon put it off, but it's been put off way too long as it is, and we > might as well release what we have and fix all the problems in 21.1. > Comments? Release it now - but make people aware that 20.4 is more stable and 21.1 will be released soon. The quality is a lot higher than some FSF major releases I've used in the past. I think we should do binary kits as well. andy

1 participants
0 comments

2025

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 September 1998