May 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Another dialog box bug 23 years, 12 months

Martin Buchholz

If I eval (yes-or-no-p-dialog-box "???") And then use the window manager to kill the dialog box (for example, via Alt-F4), XEmacs crashes like this: (gdb) where #0 0x402cd111 in __kill () #1 0x402ccd66 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x402ce447 in abort () at ../sysdeps/generic/abort.c:88 #3 0x823f37f in wm_delete_window (shell=0x89a9c10, closure=0xbfffdb20, call_data=0x0) at /xemacs/ws/dialog-box/lwlib/lwlib-Xaw.c:605 #4 0x40123e8d in HandleActions () #5 0x40124342 in HandleSimpleState () #6 0x40124851 in _XtTranslateEvent () #7 0x401019f7 in XtDispatchEventToWidget () #8 0x40102444 in _XtDefaultDispatcher () #9 0x40102873 in XtDispatchEvent () #10 0x4010db8f in XtAppProcessEvent () #11 0x820f3f1 in emacs_Xt_next_event (emacs_event=0x8999550) at /xemacs/ws/dialog-box/src/event-Xt.c:2567 #12 0x812130d in event_stream_next_event (event=0x8999550) at /xemacs/ws/dialog-box/src/event-stream.c:508 #13 0x8123b50 in next_event_internal (target_event={...}, allow_queued=1) at /xemacs/ws/dialog-box/src/event-stream.c:1967 #14 0x81240fa in Fnext_event (event={...}, prompt={...}) at /xemacs/ws/dialog-box/src/event-stream.c:2181 #15 0x8124624 in Fnext_command_event (event={...}, prompt={...}) at /xemacs/ws/dialog-box/src/event-stream.c:2336 #16 0x80ccf5b in Ffuncall (nargs=2, args=0xbfffdd94) at /xemacs/ws/dialog-box/src/eval.c:3218 #17 0x809695c in execute_optimized_program (program=0xbfffded0 "À\t!\021Â\t!«2ÃÄÅ\t!\"\210Å\t!\211\036\006Ça«\bÈÉÊ\"\210ª\031\016\006Ëa«\bÈÉÌ\"\210ª\f\016\006Ís«\006ÎÏÌ\"\210)Ð\t!¬ÂÑ \210ÃÒ!\210ª¹\200\224e\b\214", stack_depth=5, constants_data=0x851df98) at /xemacs/ws/dialog-box/src/bytecode.c:747 #18 0x809b9c3 in Fbyte_code (instructions={...}, constants={...}, stack_depth={...}) at /xemacs/ws/dialog-box/src/bytecode.c:2404 #19 0x80cc5c0 in Feval (form={...}) at /xemacs/ws/dialog-box/src/eval.c:3018 #20 0x80c8fa3 in internal_catch (tag={...}, func=0x80cbe88 <Feval>, arg={...}, threw=0x0) at /xemacs/ws/dialog-box/src/eval.c:1310 #21 0x8097f69 in execute_rare_opcode (stack_ptr=0xbfffe2e4, program_ptr=0x89b3f45 "+\207\b", opcode=Bcatch) at /xemacs/ws/dialog-box/src/bytecode.c:1253 #22 0x8096684 in execute_optimized_program (program=0x89b3f30 "À \031Â\216Ã\fÅÆÇÈ¯\005!\210Ç\036\tÊË\215+\207\b", stack_depth=6, constants_data=0x851dff8) at /xemacs/ws/dialog-box/src/bytecode.c:657 #23 0x80963e2 in funcall_compiled_function (fun={...}, nargs=1, args=0xbfffe490) at /xemacs/ws/dialog-box/src/bytecode.c:516 next-command-event(nil) byte-code("..." [next-command-event event misc-user-event-p message "%s" event-object G25516 yes throw ynp-done t no nil (cancel menu-no-selection-hook) signal quit button-release-event-p beep "please answer the dialog box"] 5) # (catch ynp-done ...) # bind (event) # (unwind-protect ...) # bind (ssf25515 prompt) yes-or-no-p-dialog-box("??") eval((yes-or-no-p-dialog-box "??")) # bind (expr) eval-interactive((yes-or-no-p-dialog-box "??")) # bind (standard-output opoint ignore-quotes eval-last-sexp-arg-internal) eval-last-sexp(t) # bind (standard-output) #<compiled-function nil "...(13)" [standard-output terpri eval-last-sexp t] 2 939997 nil>() call-interactively(eval-print-last-sexp) # (condition-case ... . error) # (catch top-level ...)

1 participants
0 comments

Re: something for the architecting xemacs 'futures' site... 23 years, 12 months

Raymond Toy

>>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: William> Raymond Toy <toy(a)rtp.ericsson.se> writes: >> >>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: >> William> Why the hell does XEmacs still draw multiple 'windows' on William> top of a single X or MS window? Wouldn't life be much William> simpler if each emacs window was a real window in the William> window system? Then you could use sane geometry >> >> I rather like that xemacs draws multiple 'windows' on a single X >> window. If every emacs window were a real window, I'd have to move >> the mouse or hack C-x o or something to get xemacs to move to the >> window I want. William> That could be done easily in the XEmacs C code... you wouldn't notice any William> difference. >> Besides, doesn't C-x 5 2 do what you want? William> Create a new frame? That's not what I meant. The William> multiple X windows would still be 'inside' the XEmacs William> frame, just the internals would not be such a pain in the William> ass. But right now a XEmacs only has one X window that William> it draws on - the modelines, scrollbars, etc, are just William> drawn or placed within this window and raised on top of William> the real window. I get it. It sounds like the right thing to do to me, but I know zilch about X programming. Ray

1 participants
0 comments

Re: something for the architecting xemacs 'futures' site... 23 years, 12 months

William M. Perry

Raymond Toy <toy(a)rtp.ericsson.se> writes: > >>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: > > William> Why the hell does XEmacs still draw multiple 'windows' on > William> top of a single X or MS window? Wouldn't life be much > William> simpler if each emacs window was a real window in the > William> window system? Then you could use sane geometry > > I rather like that xemacs draws multiple 'windows' on a single X > window. If every emacs window were a real window, I'd have to move > the mouse or hack C-x o or something to get xemacs to move to the > window I want. That could be done easily in the XEmacs C code... you wouldn't notice any difference. > Besides, doesn't C-x 5 2 do what you want? Create a new frame? That's not what I meant. The multiple X windows would still be 'inside' the XEmacs frame, just the internals would not be such a pain in the ass. But right now a XEmacs only has one X window that it draws on - the modelines, scrollbars, etc, are just drawn or placed within this window and raised on top of the real window. If you used real windows to correspond to emacs' idea of a window, then you could use a geometry manager to handle the placement for you, instead of having to do it manually inside of redisplay-*.c or scrollbar-*.c. And you wouldn't have to screw around with weird keybindings in the modeline to get window resizing to work - you could have a real 'paned' widget do all of that automatically. -Bill P.

1 participants
0 comments

Re: something for the architecting xemacs 'futures' site... 23 years, 12 months

Raymond Toy

>>>>> "William" == William M Perry <wmperry(a)aventail.com> writes: William> Why the hell does XEmacs still draw multiple 'windows' on William> top of a single X or MS window? Wouldn't life be much William> simpler if each emacs window was a real window in the William> window system? Then you could use sane geometry I rather like that xemacs draws multiple 'windows' on a single X window. If every emacs window were a real window, I'd have to move the mouse or hack C-x o or something to get xemacs to move to the window I want. Besides, doesn't C-x 5 2 do what you want? Ray

1 participants
0 comments

false alarm on the redisplay weirdness with gtk... 24 years

William M. Perry

It had nothing to do with handle_focus_change_preliminary... it appears there is something screwy with my gc cache, combined with not having a background color defined for my text-cursor face. It is reusing the last GC it found, and was basically redrawing the text in 'text-cursor' face instead of 'default'. So it was white-on-white, which doesn't have very good contrast. Well, at least now I know where to go look for the problem... wheee! -Bill P.

1 participants
0 comments

gtk redisplay weirdness - partially solved... 24 years

William M. Perry

Ok, thru the miracle of 'just commenting #%!＠ out until it works', I've narrowed down why the redisplay was acting so oddly. it seems that when handle_focus_event_1() is called, it calls emacs_handle_focus_change_preliminary (in event-stream.c). This is what is causing the problems. The call to emacs_handle_focus_change_final doesn't make a bit of difference though. Curiouser and curiouser. But with that commented out I now have a gtk-xemacs that I'd be comfortable developing the rest of it in. That's something at least. :) -bp

1 participants
0 comments

--with-dialogs=none is broken 24 years

Andreas Jaeger

I don't manage to compile a working XEmacs for myself :-(. Since the Athena dialog boxes are broken (see a previous email), I tried --with-dialogs=none. Editing a file and leaving XEmacs via the Menu-Option "Exit XEmacs" I get (debug-on-error is set): Signaling: (wrong-type-argument "unable to bind this type of event" #<misc-user-event (eval (let (this-command last-command) (update-widget-instances #<x-frame "emacs" 0x2613>)))>) lookup-key(#<keymap size 1 0x4271> [#<misc-user-event (eval (let ... ...))>]) map-y-or-n-p(#<compiled-function (buffer) "...(84)" [buffer-modified-p buffer buffer-base-buffer symbol-value-in-buffer save-buffers-skip buffer-file-name exiting buffer-offer-save buffer-size 0 arg t switch-buffer one-window-p delete-other-windows switched switch-to-buffer format "Save file %s? " "Save buffer %s? " buffer-name] 4> #<compiled-function (buffer) "...(8)" [buffer nil (save-buffer) (...)] 3> (#<buffer "*Help: lossage*"> #<buffer "adfadfa"> #<buffer "*scratch*"> #<buffer " *Minibuf-0*"> #<buffer " *Echo Area*"> #<buffer " *pixmap conversion*"> #<buffer " *load*"> #<buffer " *Message-Log*">) ("buffer" "buffers" "save") ((?\^R #<compiled-function ... "...(11)" ... 2> "%_Display Buffer"))) save-some-buffers-1(nil t t) save-some-buffers(nil t) save-buffers-kill-emacs(nil) call-interactively(save-buffers-kill-emacs) Could somebody please fix the broken dialogboxes asap? For now this means that I'm staying with 21.1 :-(. Or does anybody have some magic options --with-dialogs option that works on Linux? Andreas P.S. Here's the Installation file: uname -a: Linux gromit 2.3.48 #22 Son Feb 27 16:43:56 CET 2000 i686 unknown /usr/src/cvs/release-21-2/configure '--prefix=/opt/xemacs' '--extra-verbose=no' '--with-site-lisp' '--with-database=no' '--error-checking=none' '--debug=no' '--mail-locking=flock' '--with-gpm=no' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=none' '--with-mule' '--with-widgets=no' 'i686-linux-gnu' XEmacs 21.2-b32 "Kastor & Polydeukes" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /usr/src/cvs/release-21-2 Installation prefix: /opt/xemacs Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11/include - X Windows libraries location: /usr/X11/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Mail: Compiling in support for "flock" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Clash detection will use "${statedir}/${inststaticdir}/lock" for locking files. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Dialog boxes don't work 24 years

Andreas Jaeger

With the current XEmacs version the Yes/No Dialog box seems to work but not this kind of dialog box: After clicking on e.g. "Yes", I get: "No catch for tag: result, skip" I also don't like the appearence of the dialog box - "%_Yes" looks broken to me. Andreas P.S. My system (ignore the data, I've run cvs update && make 2 hours ago): uname -a: Linux gromit 2.3.99-pre6 #30 Don Apr 27 18:36:17 CEST 2000 i686 unknown /usr/src/cvs/release-21-2/configure '--prefix=/opt/xemacs' '--extra-verbose=no' '--with-site-lisp' '--with-database=no' '--error-checking=none' '--debug=no' '--mail-locking=flock' '--with-gpm=no' '--with-offix=no' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=athena' '--with-mule' '--with-widgets=no' 'i686-linux-gnu' XEmacs 21.2-b32 "Kastor & Polydeukes" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /usr/src/cvs/release-21-2 Installation prefix: /opt/xemacs Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11/include - X Windows libraries location: /usr/X11/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Mail: Compiling in support for "flock" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Clash detection will use "${statedir}/${inststaticdir}/lock" for locking files. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

[EMilet@tkusa.com: Problem with xemacs] 24 years

Olivier Galibert

Anyone has an idea? It's definitively not my field of competence :/ OG.

1 participants
0 comments

Athena "search" dialog hosed 24 years

Hrvoje Niksic

Given the history of Athena-related problems, the subject line is probably no news for Andy. Still, I'd like to report the problems. When I click on the "Edit->Search..." menu entry, I get a nice little dialog. However, although the dialog gets WM focus, I can't type anything because the characters end up inserted into the XEmacs frame. I managed to trick XEmacs by selecting some characters with the mouse and button2-pasting them into the dialog box. At that point, when I press RET nothing happens. When I click on the "Find next" button a few times, XEmacs crashes. This is on Linux, a freshly built debugging XEmacs from the latest CVS + Yoshiki's "Fix crash by make-search-dialog" patch.

5 participants
4 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 May 2000