December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Is this the progress gauge ? 24 years, 12 months

Didier Verna

Now that Athena3d doesn't crash my XEmacs anymore, I can see the progress gauge stuff, I think. Here's what I get under the modeline: Huh, it's *big* and there's text drawn in black on my dark background (my default face has a white foreground). Is there a way to make it smaller, somewhere else, or even to turn it off ? Is this looking normal ? Also, I have a problem with the Gnus picons network retreival: the progress gauge appears but never goes away. The picons are retreived and displayed normally. Thanks. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

lwlib normalization 25 years

Andy Piper

I'm hoping this fixes the memory leaks Martin is seeing. But I don't have purify .... andy 1999-12-28 Andy Piper <andy(a)xemacs.org> * menubar-x.c (menu_item_descriptor_to_widget_value_1): strdup string_chars. (menu_item_descriptor_to_widget_value_1): strdup name. (pre_activate_callback): strdup name. * scrollbar-x.c (scrollbar_instance_to_widget_value): strdup name. (x_update_scrollbar_instance_status): use free_widget_value_tree. * dialog-x.c (maybe_run_dbox_text_callback): strdup name. use free_widget_value_tree. (dbox_descriptor_to_widget_value): ditto. * gui-x.c (widget_value_unwind): use free_widget_value_tree. (gui_items_to_widget_values_1): ditto. (gui_items_to_widget_values): ditto. (free_popup_widget_value_tree): free name. * redisplay-output.c (redisplay_display_boxes_in_window_p): mild Martin-style fiddling. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: check process state before accessing coding_stream (fix PR#1061) 25 years

Didier Verna

Martin R Buchholz wrote: > Do *you* run with menubars translated into your language? I don't. > Why not? I don't use an fr_FR locale _at all_. It's not because of XEmacs' state with respect to translations, it's just that I prefer to use the C locale. Perhaps if _all_ my work environment was correctly localized, I would switch. However, this does not prevent me from working on translations when I have time. I've written the french tutorial and also translated the splash screen, although I almost never see it. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

Gutter redisplay too agressive. 25 years

Jan Vroonhof

I finally tracked down why the gutter is flashing all the time when using Gnus. The problem is that the Gnus mime code is full of (save-current-window (select-window w) ...)) and (save-window-excursion (select-window w) ..)) and these select-window's call record-buffer-hook which does the update tab stuff. This a. is unnecessary work (but that is probably a gnus problem). b. The gutter is redisplaying too soon. If it just waited until the save-window-excursiom is finished (like the rest of the redisplay does) there would not be any visible effect. Jan P.S. I don't know why the mime code is doing this.

3 participants
3 comments

More widget flashing 25 years

Jan Vroonhof

Just to keep Andy occupied (setq widget-editable-list-gui t) (defcustom dummy-var '(a b c) "doc" :type '(repeat symbol)) (customize-variable 'dummy-var) And the "INS" "DEL" buttons start flashing around like mad latest CVS+athena3D Jan

2 participants
3 comments

Patch for event-msw.c crash (cygwin version) 25 years

Dmitry Yaitskov

Hi, I can easily get assert (!badly_p); to fail in cygwin version on my machine (e.g. by running gnus and partly opening/closing the XEmacs window by some other window). From the code and my understanding of the select function it seems to me that that assert should never happen if the select works according to specs. Hence it looks like a bug in the cygwin's select implementation. The attached patch avoids the bug. It is ugly, but saves from crashes and should do no harm even if the bug gets fixed. The patch is against 21.2.b25 source. Thanks. -- Cheers, -Dima.

2 participants
1 comments

Re: check process state before accessing coding_stream (fix PR#1061) 25 years

Didier Verna

Martin R Buchholz wrote: > We already have menubar translations via X resources, albeit poorly > documented and incomplete. But there is certainly work left to do > there for interested translators that involves no programming. I'm very sceptical about working on X resources for anything, even for translations of the menubar. We have already too much control over too many features with the X resources. X resources are a not very good mechanism which, what's more, works only under X. The gettext'ization of the Lisp strings should be something generic, not depending on the platform your XEmacs frame is on. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

4 participants
4 comments

Re: New Release of XEmacs-Packages 25 years

Raymond Toy

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: >>>>> "Andreas" == Andreas Jaeger <aj(a)suse.de> writes: Andreas> What is _not_ in there (yet) Andreas> - latest ilisp (server unavailable/volunteer need) Raymond> Just a note: I tried the latest version. I couldn't get it to do Raymond> anything useful. There was some error about processes or something, Raymond> and the inferior lisp never got started. I didn't want to spend Raymond> anymore time on it so I reverted back the existing version. Raymond> Perhaps others have had better luck than I, Found the problem I was having. I extracted the new ilisp package into ~/.xemacs/xemacs-packages/lisp/ilisp. However, when I run it, ilisp goes looking for where it came from via load-path, and my load-path doesn't include ~/.xemacs/xemacs-packages/lisp/ilisp. Thus, I was getting a mix of old and new ilisp files. Once I added that path to my load-path, my problems went away. I think ilisp 5.9.2 is OK. It works just fine for me. The question is how should ilisp go looking for where it was loaded from. It currently tries to find itself by looking at all the entries in load-path. Should it look in the package path first, and then fall back to load-path? Ray

3 participants
2 comments

Re: unexelf on irix (kinda digest) 25 years

Gunnar Evermann

[ I've removed all those people from CC: who I know to be on xemacs-beta ] Max Matveev <makc(a)sgi.com> writes: > Olivier Galibert writes: > :> On Mon, Dec 06, 1999 at 09:04:15AM -0200, Alexandre Oliva wrote: > :> > I have found out the `.got' section didn't need special handling on > :> > IRIX either, at least when the compiler was gcc. If this is confirmed > :> > with other compilers too, the special handling might also be removed > :> > from unexelfsgi.c, or we might remain with unexelf.c, even on IRIX6. > :> > :> Beware of sgi's compiler. Really. > SGI compiler is ok, SGI's rld is a bit more involved, thou, especially > if rqs or cord were around. So, to be on the safe side, I'd say - keep > the stuff as it is, don't move it. After all, we don't need nothing in > the sections which are not in .bss or .sbss, so just leave them as > they are. I have done test builds of XEmacs21.1.8cvs+Max's patch on two systems: IRIX64 ruby 6.2 06101031 IP28 mips with gcc 2.7.2.3 IRIX truth 6.5 01221553 IP32 mips with MIPSpro 7.2.1 executive summary: everything works with the MIPSpro compiler but not with gcc. gory details: - the binary built on truth(6.5) works on ruby(6.2) - the gcc build has the old, well-known problem that temacs has an sbss section that is apparently not handled correctly by unexelfsgi.c (despite ChangeLog entries implying this) - I can get rid of the sbss section by adding '-G0' to the LDFLAGS and then get a perfectly fine xemacs with gcc. Actually all my production XEmacsen (21.1.4) were built this way on IRIX5.3. I have put the Installation files and the output of 'objdump --section-headers' at http://svr-www.eng.cam.ac.uk/~ge204/XEmacs/ Let me know if you want me to do more tests, whether all this is considered normal behaviour, where to start debugging, etc. I can also test on IRIX5.3 if necessary... Gunnar

2 participants
2 comments

Re: New Release of XEmacs-Packages 25 years

Raymond Toy

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "Ray" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Stephen> AFAIK packages in ~/.xemacs should be found automagically, but I Stephen> haven't looked at the code recently to see where it thinks "packages Stephen> in ~/.xemacs" actually are located (it used to be Stephen> ~/.xemacs/lisp/<package> but I thought that got changed to make Stephen> ~/.xemacs a package hierarchy root, searching in ~/.xemacs/*-packages, Stephen> rather than a package directory). I guess I was not quite clear. The package was found in ~/.xemacs automagically. The problem was that ilisp wanted to find out where it was loaded from, so it grovels over load-path to find some ilisp file. Unfortunately, my load-path didn't include anything from my ~/.xemacs packages, so ilisp couldn't really find out where it was loaded from. Instead, it got it from my load-path which pointed to the "global" xemacs packages directory. (Hmm, why does my load-path have that?) Ray

2 participants
1 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 December 1999