May 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Small windows with scroll-step set 24 years, 8 months

Jan Vroonhof

Mike Alexander <mta(a)arbortext.com> writes: > I did that. It doesn't lay out any lines because the height of the > window is less than the height of one line. I don't know enough > about the redisplay code to know if this is supposed to be impossible > or if it is normal but the redisplay code isn't handling it right. Could you try whether this (untested) attempt at fixing update_line_start_cache helps? Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/redisplay.c,v retrieving revision 1.55.2.56 diff -u -r1.55.2.56 redisplay.c --- redisplay.c 2000/05/09 11:54:57 1.55.2.56 +++ redisplay.c 2000/05/11 18:15:14 ＠＠ -87,16 +87,10 ＠＠ #define LEFT_GLYPHS 2 #define RIGHT_GLYPHS 3 -/* Set the vertical clip to 0 if we are currently updating the line - start cache. Otherwise for buffers of line height 1 it may fail to - be able to work properly because regenerate_window will not layout - a single line. */ #define VERTICAL_CLIP(w, display) \ - (updating_line_start_cache \ - ? 0 \ - : ((WINDOW_TTY_P (w) | (!display && scroll_on_clipped_lines)) \ + ((WINDOW_TTY_P (w) | (!display && scroll_on_clipped_lines)) \ ? INT_MAX \ - : vertical_clip)) + : vertical_clip) /* The following structures are completely private to redisplay.c so we put them here instead of in a header file, for modularity. */ ＠＠ -328,9 +322,6 ＠＠ /* Minimum visible pixel width of clipped glyphs at right margin. */ int horizontal_clip; -/* Set if currently inside update_line_start_cache. */ -static int updating_line_start_cache; - /* Nonzero means reading single-character input with prompt so put cursor on minibuffer after the prompt. */ int cursor_in_echo_area; ＠＠ -5098,6 +5089,7 ＠＠ int ypos = WINDOW_TEXT_TOP (w); int yend; /* set farther down */ int yclip = WINDOW_TEXT_TOP_CLIP (w); + int force; prop_block_dynarr *prop; layout_bounds bounds; ＠＠ -5151,10 +5143,14 ＠＠ else prop = 0; + /* When we are computing things for scrolling purposes, make + sure at least one line is always generated */ + force = (type == CMOTION_DISP); + /* Make sure this is set always */ /* Note the conversion at end */ w->window_end_pos[type] = start_pos; - while (ypos < yend) + while (ypos < yend || force) { struct display_line dl; struct display_line *dlp; ＠＠ -5207,7 +5203,7 ＠＠ the top clip and the bottom clip. */ visible_height -= (dlp->clip + dlp->top_clip); - if (visible_height < VERTICAL_CLIP (w, 1)) + if (visible_height < VERTICAL_CLIP (w, 1) && !force) { if (local) free_display_line (dlp); ＠＠ -5251,6 +5247,8 ＠＠ generate_display_line call. */ if (start_pos > BUF_ZV (b)) break; + + force = 0; } if (prop) ＠＠ -7834,7 +7832,6 ＠＠ validate_line_start_cache (w); w->line_cache_validation_override++; - updating_line_start_cache = 1; if (from < BUF_BEGV (b)) from = BUF_BEGV (b); ＠＠ -7843,7 +7840,6 ＠＠ if (from > to) { - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -7856,7 +7852,6 ＠＠ /* Check to see if the desired range is already in the cache. */ if (from >= low_bound && to <= high_bound) { - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -7885,7 +7880,6 ＠＠ update_internal_cache_list (w, DESIRED_DISP); if (!Dynarr_length (internal_cache)) { - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -7913,7 +7907,6 ＠＠ { Dynarr_add_many (cache, Dynarr_atp (internal_cache, 0), Dynarr_length (internal_cache)); - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -7922,7 +7915,6 ＠＠ the bounds of the DESIRED structs in the first place. */ if (start >= low_bound && end <= high_bound) { - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -7945,7 +7937,6 ＠＠ Dynarr_reset (cache); Dynarr_add_many (cache, Dynarr_atp (internal_cache, 0), Dynarr_length (internal_cache)); - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -7971,7 +7962,6 ＠＠ Dynarr_reset (cache); Dynarr_add_many (cache, Dynarr_atp (internal_cache, 0), Dynarr_length (internal_cache)); - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -7980,7 +7970,6 ＠＠ Dynarr_length (internal_cache) - ic_elt); } - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -8000,23 +7989,9 ＠＠ update_internal_cache_list (w, CMOTION_DISP); /* If this assert is triggered then regenerate_window failed - to layout a single line. That is not supposed to be - possible because we impose a minimum height on the buffer - and override vertical clip when we are in here. */ - /* #### Ah, but it is because the window may temporarily - exist but not have any lines at all if the minibuffer is - real big. Look into that situation better. */ - if (!Dynarr_length (internal_cache)) - { - if (old_lb == -1 && low_bound == -1) - { - updating_line_start_cache = 0; - w->line_cache_validation_override--; - return; - } - - assert (Dynarr_length (internal_cache)); - } + to layout a single line. This is not possible since we + force at least a single line to be layout for CMOTION_DISP */ + assert (Dynarr_length (internal_cache)); assert (startp == Dynarr_atp (internal_cache, 0)->start); ic_elt = Dynarr_length (internal_cache) - 1; ＠＠ -8062,7 +8037,6 ＠＠ startp = new_startp; if (startp > BUF_ZV (b)) { - updating_line_start_cache = 0; w->line_cache_validation_override--; return; } ＠＠ -8096,7 +8070,6 ＠＠ while (to > high_bound); } - updating_line_start_cache = 0; w->line_cache_validation_override--; assert (to <= high_bound); } ＠＠ -9268,15 +9241,8 ＠＠ } void -reinit_vars_of_redisplay (void) -{ - updating_line_start_cache = 0; -} - -void vars_of_redisplay (void) { - reinit_vars_of_redisplay (); #if 0 staticpro (&last_arrow_position);

3 participants
2 comments

build problem with HP audio? 25 years

Gunnar Evermann

I seem to remember that there was some problem building on HP-UX with certain (new) audio libraries. Could somebody summarize what that was and (more importantly) if appropriate write an entry for PROBLEMS? thanks in advance Gunnar

3 participants
2 comments

Who wants to work on Ps-print? 25 years

Jan Vroonhof

Is there somebody with time to hack on ps-print. Mostly testing. The current ps-print-nomule package is really old and the mule-version never materialized. In addition ps-print-nomule has problems on NT. Attached to this message is a recent version of ps-print.el (from FSF 20.4) that has been made to work on a non-mule XEmacs. That is joint work by Kevin Delia and me. Kudos to Handa San for making the mule stuff so modular. So what needs to be done. 1. The hooks for Mule have been commented out below. They need to be replaced by the appropriate fboundp and featurep checks. 2. The other (mule) parts of ps-print should be gotten from FSF 20.5 (maybe even contact Handa San for his latest version). They should be made to work on XEmacs-mule. Then they should be in a new ps-print-mule package. Jan P.S. With the version below there is not reason to keep the old version form ps-print-nomule. -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

3 participants
2 comments

Better toolbar button descriptions (was Re: question about the new widget/glyph code...) 25 years, 1 month

William M. Perry

Andy Piper <andy(a)xemacs.org> writes: > At 09:22 PM 5/29/00 -0500, William M. Perry wrote: > >so, since the widgets are glyphs, and glyphs go in toolbars, would I be > >able to put a text-entry or combo-box into the toolbar now? > > Theory says yes. Reality says no because for windows at least its down to > the supported button types. It might work under X though. This is the > problem with working with native widgets - lowest common denominator and > all that. > > The combo-box style is a specific toolbar style I think, we would have to > fix up the code to cope. MIght not be too hard though ... Oh, windows doesn't let you stick arbitrary widgets into the toolbar? Hrm. Would anyone be interesting in revamping the toolbar stuff real soon? I like ben's proposal on the web site, but I hate having the series-of-glyphs crap in there. A toolbar button description should look like: ["Open" CALLBACK :glyph GLYPH ; A single glyph to show :active FORM ; normal menubar-ish :active slot :tooltip FORM-OR-STRING ; Tooltip to show :help FORM-OR-STRING ; whats-this type help ] This is easily distinguishable from the current XEmacs toolbar specs, and would look much nicer on GTK or Windows where we could use more of the standard functionality. We would need to add code to auto-generate a disabled version of the pixmap, but that should be fairly simple. There is code in Emacs 21.x to do this. The toolbar code would draw the first string under the glyph if necessary, so there is no need to supply pixmaps/etc for them. This would make the toolbar buttons much more readable as well. -Bill P.

1 participants
0 comments

Re: 21.2.34 crash 25 years, 1 month

Raymond Toy

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 03:41 PM 5/30/00 +0400, Nick V. Pakoulin wrote: >> My newly built 21.2.34 crashed while spell checking. No LISP trace, Andy> sorry, but Andy> Please update from CVS - it should be fixed. If you have the time, can you point out which patch fixes this? I can't access the CVS sources, and I'm getting this crash every hour or two depending on how often I read my mail and news with XEmacs. This makes it unusable for me. Ray

2 participants
1 comments

Latest CVS - tiny buglet... 25 years, 1 month

Valdis Kl=?iso8859-4?Q?=BA?=tnieks

Some compilers (IBM ibmcxx 3.6 for example) don't like trailing commas... Patch attached... /Valdis *** src/glyphs.h.dist Tue May 30 11:31:28 2000 --- src/glyphs.h Tue May 30 11:31:30 2000 *************** *** 91,97 **** IMAGE_GEOMETRY, IMAGE_DESIRED_GEOMETRY, IMAGE_MIN_GEOMETRY, ! IMAGE_MAX_GEOMETRY, }; #define IMAGE_UNSPECIFIED_GEOMETRY -1 --- 91,97 ---- IMAGE_GEOMETRY, IMAGE_DESIRED_GEOMETRY, IMAGE_MIN_GEOMETRY, ! IMAGE_MAX_GEOMETRY }; #define IMAGE_UNSPECIFIED_GEOMETRY -1

3 participants
4 comments

Re: http://www.xemacs.org/list-archives/xemacs-* are all down 25 years, 1 month

Jason R Mastaler

The XEmacs mailing list archives should now be working again. Thanks for your patience.

1 participants
0 comments

Re: lwlib expertise anyone? Menubar construction... 25 years, 1 month

William M. Perry

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > The X specific code just creates the widget_value list... does lwlib do > > something smart like delay the creation of the menu until the next > > redisplay? > > Doesn't the general menubar code do that?. I though the menubar > updating was in redisplay-frame and the menu code sets a flag whenever > the menus (might) have changed. Here is a test case: (defun flubber () (interactive) (find-file "~/.emacs") (find-file "/tmp/ldap.c") (while t (save-window-excursion (save-excursion (set-buffer "ldap.c") (sit-for 0) (set-buffer ".emacs"))))) With XEmacs/GTK the menubar basically disappears while this is running, and f->menubar_changed is _always_ 1. But under stock XEmacs 21.1.10, the menubar does not appear to update at all. -Bill P.

1 participants
0 comments

Re: lwlib expertise anyone? Menubar construction... 25 years, 1 month

William M. Perry

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > The X specific code just creates the widget_value list... does lwlib do > > something smart like delay the creation of the menu until the next > > redisplay? > > Doesn't the general menubar code do that?. I though the menubar updating > was in redisplay-frame and the menu code sets a flag whenever the menus > (might) have changed. If it is, then something is screwed up there. :) I put some debug statements in update_frame_menubars () (and update_frame_menubar_internal ()) and f->menubar_changed is definitely '1' even when a save-excursion is in effect. I'll have to try and work up a test case. -Bill P.

1 participants
0 comments

Re: lwlib expertise anyone? Menubar construction... 25 years, 1 month

Jan Vroonhof

wmperry(a)aventail.com (William M. Perry) writes: > The X specific code just creates the widget_value list... does lwlib do > something smart like delay the creation of the menu until the next > redisplay? Doesn't the general menubar code do that?. I though the menubar updating was in redisplay-frame and the menu code sets a flag whenever the menus (might) have changed. Jan

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 May 2000