March 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Adrian Aichner

The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. >>>>> "Torgny" == Torgny Nyblom <torgny(a)linux.nu> writes: Torgny> Hi, Torgny> I've got some problems with Xemacs-21.1-b46's (I don't That would have to be 21.2-b46, a beta version. For support on beta versions you should ask for help on xemacs-beta, which you may subscribe to at http://lists.sourceforge.net/lists/listinfo/xemacs-beta A mailing list archive is also available at http://list-archive.xemacs.org/xemacs-beta See http://www.xemacs.org/Lists/index.html for all XEmacs mailing lists. FWIW, I have seen this problem also in 21.2-b46 build on native Windows 2000. Best regards, Adrian Torgny> know if the problem exists in others) pop3.el. The problem Torgny> is that when I try to use 'pop3-leave-mail-on-server t' I Torgny> get this error message: >> Retrieving message list... >> Retrieving message list...0 unread >> Wrote c:\.emacs-mail-crash-box >> Mail source error ((file-error I/O error No such file or directory c:\.uidls.old)). Coninue? (yes or no) >> nnml: Reading incoming mail from pop... >> Processing mail from ~/.emacs-mail-crash-box... >> Retrieving message list... >> Retrieving message list...0 unread Torgny> It seems to me like XEmacs can't read the '.uidls.old' file even thou Torgny> it exists right where it's supposed to. If I try and eval the Torgny> expression that crashes before gnus is loaded everything works fine but Torgny> when gnus is loaded it crashes. Any sugestions as to I might do to get Torgny> this to work? Torgny> -- Torgny> Torgny Nyblom | torgny(a)linux.nu Torgny> =============================== Torgny> My keyboard has an F1 key. Where is the NASCAR key? Torgny> =============================== -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

1 participants
0 comments

Re: CRASH: problem in event code; automating adding bugs and such to web site 24 years

Kirill 'Big K' Katsnelson

Some time ago, Andy Piper wrote... >At 01:47 AM 3/26/01 -0700, Ben Wing wrote: >>was already invoked and processed is getting seen again, but clearly >>something is amiss in this code. since this twisty windy code was >>reworked a lot for windows and i don't yet understand it, could some >>windows expert help? > >I am still suspicious that the fact that the event loop runs in a >different thread [is this true?] can cause all sorts of nasty race >conditions in XEmacs. This is not true in XEmacs. In NTEmacs, it does run in a separate thread. Destroying this "feature" was the first think I did when I joined the XEmacs team. You are right Andy, syntchronization could be extremely tricky. I'll look into this bug. -kkm

1 participants
0 comments

Seen in configure.usage 24 years

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

OK, so I decided to investigate whether my --with options were causing a problem, and I find this in configure.help: > --with-menubars=TYPE Use TYPE menubars (lucid, motif, or no). The Lucid > widgets emulate Motif (mostly) but are faster. > *WARNING* The Motif menubar is currently broken. OK so far... > --with-scrollbars=TYPE Use TYPE scrollbars > (lucid, motif, athena, or no). OK.. > --with-dialogs=TYPE Use TYPE dialog boxes (motif, athena, or no). > Lucid menubars and scrollbars are the default. > Motif dialog boxes will be used if Motif can be found. Lucid is the default, but isn't listed in the choices (motif, athena, or no). configure.in lists 'lucid, motif, athena, yes/no, gtk, msw'. as options. > --with-widgets=TYPE Use TYPE widgets (motif, athena, or no). > Motif widgets will be used if Motif can be found. > Other widget types are currently unsupported. configure will accept --with-widgets=lucid Not sure if that's a bug or a feature. Anybody want to get configure.in and configure.help into sync? /Valdis

2 participants
1 comments

Re: Changing the Edit->Find menu entry 24 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)arsdigita.com> writes: > The Edit->Find menu entry pops up a search dialog box, as seen in many > other GUI application. This is an excellent idea, and maybe the > dialog works perfectly under some OS/window system combinations, but > for me it is almost completely broken. (See below for a detailed > description.) I agree with the sentiment. It seems to work much better on windows because it has a real dialog there. Is there a generic way we can disable stuff like this on X where it doesn't quite work, without 1. Disabling the feature on platforms (Windows? Gtk?) where it works just fine just because plain X is lagging. 2. Loosing the code, so that when somebody willing and able comes along to fix it he can. Jan

2 participants
1 comments

Re: XEmacs 21.1.14 failing to convert to VirtualBinding 24 years

Jari Aalto

* Mon 2001-03-26 Pradip Maitra <pradip(a)coronanetworks.com> mail.emacs | I am fighting a losing battle of configuring XEMACS but | before I give up and switch to Visual Slickedit or VIM, | I would appreciate some feedback. I get | Warning: Can't convert string "<Key>Escape,_Key_Cancel" to type | VirtualBindings | | on every 'xemacs &' from tcshell started by rlogin, TCP/IP using EXCEED | under | NT-4.0, SvcPack:6. | | Actually, there are seven such lines with various keys like Home, F1, F10, | etc. | failing to convert to VirtualBinding. | | Except that and some minor irritations about erasing highlighted texts, | rest of it seems just fine. | | The xemacs was downloaded from xemacs.org a few days back. I didn't | compile anything separately. The version is 21.1.14 running on | Sun Sparc SunOS 5.7. I'm afraid I do not know the internals of XEmacs, but I've CC'd your message to XEmacs beta list in case this is a know issue and correcte din 21.2 or later versions. Jari

1 participants
0 comments

'about xemacs' 24 years

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

Clicking on 'Help'/'About XEmacs', and going to 'About Maintainers'.. >From Vladimir Ivanovic to Andreas Jaeger the names show up in a bold face, but from Eduardo Pelegri-Llopart onward they show up in an italic face instead. Took me a while to realize that the bold meant 'Link' - guess who's been thinking "links are underlined" for *way* too long? Should links like that use an underlined face, for greater visual compatability with web browsers? (And yes, I know I can set a face that does it - the question is for newbies who haven't figured that out yet - if they're looking at 'About XEmacs' they're probably new. I only poked there because it was a handy place to test my 'page up in scrollbar' stuff... /Valdis (who is going to shut up and leave for the gym now ;)

1 participants
0 comments

Another nit... 24 years

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

This one's been bugging me for ages, I finally tracked down what caused it... lwlib/xlwscrollbar.c has a nice little hint about setting the X resources to allow Athena-like scrolling (left mouse down, right mouse up). Unfortunately, it doesn't provide a 'release()' binding by default for Btn3Up. End result is you click right-mouse, and it grabs the keyboard and never releases it until you mouse-click on something else (up/down arrows, or left-mouse the trough) that *does* do a 'release()' binding on mouse-up. Lame documentation patch attached, but we probably need to do something more thorough.. /Valdis (who's being quite the complainer today ;) *** lwlib/xlwscrollbar.c.dist Mon Mar 26 15:46:53 2001 --- lwlib/xlwscrollbar.c Mon Mar 26 15:47:23 2001 *************** *** 30,36 **** * * Emacs*XlwScrollBar.translations: #override \n\ * <Btn1Down>: PageDownOrRight() \n\ ! * <Btn3Down>: PageUpOrLeft() * */ --- 30,37 ---- * * Emacs*XlwScrollBar.translations: #override \n\ * <Btn1Down>: PageDownOrRight() \n\ ! * <Btn3Down>: PageUpOrLeft() \n\ ! * <Btn3Up>: Release() * */

1 participants
0 comments

Re: CRASH: problem in event code; automating adding bugs and such to web site 24 years

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > [crash] Do you think your crash is NT specific, or would it help to hunt for it on an X XEmacs? > In general, is there an established procedure for adding entries to the list? > Perhaps you have to add them, but maybe there could be something on the xemacs > web site where you can submit a bug, feature request, etc. into the queue that > awaits being processed? There should also be a way of displaying all the > "unsorted" items -- i.e. submitted, not yet manually processed. i also gather > there's some sort of XEmacs bug list already that's rotting out there, and > some automatic scheme for adding to it? it's maybe on some weird server > somewhere, once maintained by kyle? could the web maintainers maybe combine http://cvs.xemacs.org/XEmacs-bugs (has a link on the new Website, thanks Adrian!). Any mail to xemacsbugs(a)xemacs.org or crashes(a)xemacs.org ends up there. Gunnar has done a lot work in the past categorizing & solliciting more info, but it is unrewarding work and he is busy with other things now. It doesn't help that jitterbug, although the best we got, isn't really that good for our purposes. Jan

1 participants
0 comments

more configure.help wonkyness 24 years

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

It *says*: --with-xim=xlib Compile with support for X input methods, --with-xim=motif (*) Used in conjunction with Mule support. Use either raw Xlib to provide XIM support, or the Motif XmIm* routines (when available). NOTE: On some systems bugs in X11's XIM support will cause XEmacs to crash, so by default, no XIM support is compiled in, unless running on Solaris and the XmIm* routines are detected. In fact, the test is "unless using Motif and the XmIm* are detected", as it quite cheerfully auto-detected xim=motif on a RedHat box using OpenMotif. /Valdis

1 participants
0 comments

CRASH: problem in event code; automating adding bugs and such to web site 24 years

Ben Wing

I'd been experimenting with making commands to grep through all files in a directory, minus annoying ones such as backups and auto-saves and CVS merge files [those than begin with .#...] etc. These files generate a long grep command using find ........... | xargs grep -n ... or something like this. [yes, i just realized that igrep does something similar, and i'm going to look into it.] but ... this creates very long entries in the Tools->Grep submenu, which lists the ten most recent grep commands. Too long, in fact -- you get errors reported when you try to invoke an entry on the Grep submenu. Recently, I tried this by accident, and got a crash! The call stack looks like Fdiscard_input() line 2464 + 20 bytes Ffuncall(int 1, long * 0x0082f9cc) line 3528 + 49 bytes execute_optimized_program(const unsigned char * 0x01f69910, int 6, long * 0x01bf6110) line 746 + 16 bytes funcall_compiled_function(long 29571328, int 1, long * 0x0082fcbc) line 518 + 53 bytes Ffuncall(int 2, long * 0x0082fcb8) line 3563 + 17 bytes call1(long 28448940, long 35644440) line 4183 + 11 bytes cmd_error(long 35644440, long 28368900) line 195 + 15 bytes condition_case_1(long 28368996, long (long)* 0x010506a6 command_loop_1(long), long 28368900, long (long, long)* 0x010500c0 cmd_error(long, long), long 28368900) line 1634 + 11 bytes command_loop_3() line 256 + 35 bytes command_loop_2(long 28368900) line 269 internal_catch(long 28448988, long (long)* 0x01050210 command_loop_2(long), long 28368900, int * volatile 0x00000000) line 1317 + 7 bytes initial_command_loop(long 28368900) line 305 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x01b46fd8, char * * 0x01b50900, int 0) line 2348 main(int 1, char * * 0x01b46fd8, char * * 0x01b50900) line 2781 XEMACS! mainCRTStartup + 180 bytes _start() line 169 KERNEL32! 77e992a6() and if you look at Fdiscard_input(), where the crash is, the code looks like while (!NILP (command_event_queue) || event_stream_event_pending_p (1)) { /* This will take stuff off the command_event_queue, or read it from the event_stream, but it will not block. */ next_event_internal (event, 1); Vquit_flag = Qnil; /* Treat C-g as a user event (ignore it). It is vitally important that we reset Vquit_flag here. Otherwise, if we're reading from a TTY console, maybe_read_quit_event() will notice that C-g has been set and send us another C-g. That will cause us to get right back here, and read another C-g, ad infinitum ... */ /* If the event is a user event, ignore it. */ if (!command_event_p (event)) { /* Otherwise, chain the event onto our list of events not to ignore, and keep reading until the queue is empty. This does not mean that if a subprocess is generating an infinite amount of output, we will never terminate (*provided* that the behavior of next_event_cb() is correct -- see the comment in events.h), because this loop ends as soon as there are no more user events on the command_event_queue or event_stream. */ enqueue_event (Fcopy_event (event, Qnil), &head, &tail); } } if (!NILP (command_event_queue) || !NILP (command_event_queue_tail)) abort (); the abort in the last line is where the crash happens. command_event_queue is not nil; rather, it is #<misc-user-event (eval (progn (require (quote compile)) (let ((grep-command (co ns (concat grep-command " *.[chCH]") (length grep-command)))) (call-interactivel y (quote grep)))))> which is exactly the command i invoked that caused the crashing. [I invoked it quickly, using `M-t g c'.] Now looking at the code, and given that it got to where it got, only one thing could have happened: in the while() condition, the command_event_queue was indeed empty, but then the call to event_stream_event_pending_p (1) puts an event onto the command_event_queue. Now I don't understand how the misc-user event that was already invoked and processed is getting seen again, but clearly something is amiss in this code. since this twisty windy code was reworked a lot for windows and i don't yet understand it, could some windows expert help? Stephen, could you file this away on your bug list somewhere? In general, is there an established procedure for adding entries to the list? Perhaps you have to add them, but maybe there could be something on the xemacs web site where you can submit a bug, feature request, etc. into the queue that awaits being processed? There should also be a way of displaying all the "unsorted" items -- i.e. submitted, not yet manually processed. i also gather there's some sort of XEmacs bug list already that's rotting out there, and some automatic scheme for adding to it? it's maybe on some weird server somewhere, once maintained by kyle? could the web maintainers maybe combine the two together into one service on www.xemacs.org? if so, i'll volunteer some time going through the bugs and assigning them priority and difficulty values and figuring out who most likely should be responsible for fixing the problem. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

5 participants
5 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 March 2001