January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [Crash] segv, key_matches_specifier_p, popup menu in Gnus/Tm 24 years, 10 months

Jan Vroonhof

karlheg(a)bittersweet.inetarena.com (Karl M. Hegbloom) writes: > When I sent a SIGINT, with the top submenu open, it blonked, popped > down just the submenu, and printed an error message about wto, > character-p, the name of the menu item. (It's the same error I get > when I try to use keyboard shortcuts for menus. Did I report that > one yet? I cannot recall.) Does typing C-g help (instead of the SIGINT)? The popup menu lisp interface is fairly ugly, so it could be that the lisp code behind the menu is not catching things correctly. I fixed a few such bugs before. I am trying to distinguish that case from a real hang in the C part. Jan

1 participants
0 comments

[PATCH] fixes and stuff for the modeline 24 years, 10 months

Kyle Jones

Didier Verna writes: > > Dear reviewers, > > I'm about to apply the following patch. > > It fixes a bug in `generate_fstring_runes', adds a new modeline format (the > symbol 'unscrollable to prevent parts of the modeline from being scrolled > out), and set different X cursors according to the scrolling method. Size > mainly due to indentation. Didier, I really don't think there ought to be unscrollable parts of the modeline. I foresee trouble developing a rationale UI for such a thing, let alone the hideous uses some will find for it.

1 participants
0 comments

[Crash] segv, key_matches_specifier_p, popup menu in Gnus/Tm 24 years, 10 months

Karl M. Hegbloom

This has happened to me three times now. I finally sent a signal and got a core file. I was reading email with Gnus, in which Tm is installed via `mime-setup', and tried to middle click on a URL in the message body. I have a two button pad thing embedded on the keyboard, and have it set up so I both-click to get middle click. I fumbled, and got right-click instead, which popped up the menus. It's a three item menu with a title and three submenus. Neither clicking outside the popup menu nor on the title would lower the menu. Clicking on a submenu would pop up the submenu, but nothing in that submenu could be selected. When I sent a SIGINT, with the top submenu open, it blonked, popped down just the submenu, and printed an error message about wto, character-p, the name of the menu item. (It's the same error I get when I try to use keyboard shortcuts for menus. Did I report that one yet? I cannot recall.) I sent another SIGINT, and it dumped core. I don't have any configurations in my init.el that would affect this... I remove a few menu entries and add one, but to the global menubar. I don't have the accelerators configured, nor have I renamed the menus... due to the wto bug I just mentioned. I have noticed before, since as long as I can remember, that some popup menus pop down when I click outside of them, but others require that I click their title. They all ought to work the same; when I click outside of them, they ought to pop down. Otherwise, the WM might raise the frame above the menu, which has grabbed and can no longer take input. (One version of a Netscape Beta had that bug.) uname -a: Linux bittersweet 2.2.13 #4 Mon Jan 3 16:02:57 PST 2000 i586 unknown /usr/local/src/PKG/unstable/main/xemacs/xemacs-21.2/configure '--srcdir=/usr/local/src/PKG/unstable/main/xemacs/xemacs-21.2' '--prefix=/usr' '--without-prefix' '--cflags=-mcpu=k6 -march=k6 -ggdb -O3' '--with-database=berkdb' '--with-athena=xaw3d' '--with-widgets=athena' '--with-modules' '--package-path=/usr/local/src/XEmacs/packages' '--infopath=/usr/share/info:/usr/local/share/info:/usr/info:/usr/local/info' '--with-mule=no' '--with-file-coding' 'i686-bittersweet-linux' XEmacs 21.2-b26 "Millenium" configured for `i686-bittersweet-linux'. Where should the build process find the source code? /usr/local/src/PKG/unstable/main/xemacs/xemacs-21.2 What installation prefix should install use? /usr What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -mcpu=k6 -march=k6 -ggdb -O3 Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Enlightened Sound Daemon (ESD). Compiling in support for Berkeley DB. Compiling in support for LDAP. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in File coding support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Athena native widgets. Using Athena dialog boxes. Compiling in dynamic shared object module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Here's a screenlog showing the `gdb' "where" output.

1 participants
0 comments

[configure] question about CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM 24 years, 10 months

Marcus Thiessel

I would like to add hppa2.0{w,n} to the set of supported architectures. According to config.sub there to possible pattern to report to the user: # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM # or in some cases, the newer four-part form: # CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM What would a string of type two look like!? Would hppa2.0n and hppa2.0w be a valid string describing the architecture? Please note the {w,n} expand to wide (64bit kernel) and narrow (32bit kernel) and are closely related to the HP compiler architecture switches. See the attach patch how the changes would look like. --- config.sub Mon Jan 3 15:06:03 2000 +++ config.sub.orig Mon Jan 3 15:02:28 2000 ＠＠ -152,7 +152,6 ＠＠ tahoe | i860 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \ | arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \ | 580 | i960 | h8300 | hppa | hppa1.0 | hppa1.1 | hppa2.0 \ - | hppa2.0n | hppa2.0w \ | alpha | alphaev5 | alphaev56 | we32k | ns16k | clipper \ | i370 | sh | powerpc | powerpcle | 1750a | dsp16xx | pdp11 \ | mips64 | mipsel | mips64el | mips64orion | mips64orionel \ ＠＠ -177,7 +176,6 ＠＠ | mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \ | power-* | none-* | 580-* | cray2-* | h8300-* | i960-* \ | xmp-* | ymp-* | hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0-* \ - | hppa2.0n-* | hppa2.0w-* \ | alpha-* | alphaev5-* | alphaev56-* | we32k-* | cydra-* \ | ns16k-* | pn-* | np1-* | xps100-* | clipper-* | orion-* \ | sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \

3 participants
10 comments

Repeatable crash in 21.2.26 on Solaris 2.7 24 years, 10 months

Raymond Toy

The following recipe crashes 21.2.26 every time on my solaris 2.7 box, built with gcc 2.7.2.2. xemacs -vanilla Use the menu bar Tools->Directory Search->Query with Form. When the popup asks about configuring the search base (which is empty on my setup), click Yes. Xemacs crashes at this point. Here's the Lisp backtrace: # bind (no-save protocol server) eudc-set-server("mbb1.ericsson.se" ldap t) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("~/.eudc-options" nil nil nil undecided) # bind (path handler filename nosuffix nomessage noerror file) load("~/.eudc-options") byte-code("..." [noninteractive locate-library eudc-options-file message "" featurep load infodock eudc-install-menu] 2) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("eudc" nil nil nil binary) # bind (path handler filename nosuffix nomessage noerror file) load("eudc" nil nil nil) # (unwind-protect ...) command-execute(eudc-query-form t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) Here's the C backtrace: Program received signal SIGSEGV, Segmentation fault. 0x78d10 in execute_optimized_program (program=0xffbed080 "", stack_depth=0, constants_data=0x748110) at lisp.h:1141 1141 DECLARE_LRECORD (symbol, Lisp_Symbol); (gdb) bt #0 0x78d10 in execute_optimized_program (program=0xffbed080 "", stack_depth=0, constants_data=0x748110) at lisp.h:1141 #1 0x786bc in funcall_compiled_function (fun=7614352, nargs=3, args=0xffbed234) at bytecode.c:519 #2 0xb1984 in Feval (form=7854828) at eval.c:3034 #3 0x1810d4 in readevalloop (readcharfun=7308800, sourcename=7809524, evalfun=0xb0dec <Feval>, printflag=0) at lread.c:1448 #4 0x17f944 in Fload_internal (file=7809524, no_error=2865472, nomessage=2946048, nosuffix=3106820, codesys=3236588, used_codesys=3106820) at lread.c:736 #5 0xb1f40 in Ffuncall (nargs=-1, args=0xffbed7bc) at eval.c:3175 #6 0x78ef4 in execute_optimized_program (program=0xffbed7bc "", stack_depth=5, constants_data=0x52af10) at bytecode.c:743 #7 0x786bc in funcall_compiled_function (fun=5335548, nargs=1, args=0xffbeda34) at bytecode.c:519 #8 0xb20ac in Ffuncall (nargs=1, args=0xffbeda2c) at eval.c:3210 #9 0x78ef4 in execute_optimized_program (program=0xffbeda2c "", stack_depth=1, constants_data=0x6af090) at bytecode.c:743 #10 0x7d3f4 in Fbyte_code (instructions=-4269264, constants=7008384, stack_depth=2) at bytecode.c:2400 #11 0xb1684 in Feval (form=7808480) at eval.c:2975 #12 0x1810d4 in readevalloop (readcharfun=7428096, sourcename=5938900, evalfun=0xb0dec <Feval>, printflag=0) at lread.c:1448 #13 0x17f944 in Fload_internal (file=5938900, no_error=2865472, nomessage=2946048, nosuffix=3106820, codesys=3232420, used_codesys=3106820) at lread.c:736 #14 0xb1f40 in Ffuncall (nargs=-1, args=0xffbee1c4) at eval.c:3175 #15 0x78ef4 in execute_optimized_program (program=0xffbee1c4 "", stack_depth=5, constants_data=0x52af10) at bytecode.c:743 #16 0x786bc in funcall_compiled_function (fun=5335548, nargs=4, args=0xffbee444) at bytecode.c:519 #17 0xb20ac in Ffuncall (nargs=4, args=0xffbee430) at eval.c:3210 #18 0xb3428 in call4 (fn=3245836, arg0=5938900, arg1=3106820, arg2=3106820, arg3=3106820) at eval.c:3876 #19 0xb0c08 in do_autoload (fundef=5656188, funname=6226812) at eval.c:2789 #20 0x7dbec in Fcall_interactively (function=6226812, record_flag=3106820, keys=3106820) at callint.c:309 #21 0xb1ee0 in Ffuncall (nargs=-1, args=0xffbee7d0) at eval.c:3175 ---Type <return> to continue, or q <return> to quit--- #22 0xb3334 in call1 (fn=3181340, arg0=6226812) at eval.c:3824 #23 0x1080ac in execute_command_event (command_builder=0x640b00, event=6767408) at event-stream.c:4328 #24 0x108dd0 in Fdispatch_event (event=6767408) at event-stream.c:4691 #25 0x89988 in Fcommand_loop_1 () at cmdloop.c:575 #26 0x896d4 in command_loop_1 (dummy=3106820) at cmdloop.c:490 #27 0xadb34 in condition_case_1 (handlers=2890752, bfun=0x89670 <command_loop_1>, barg=3106820, hfun=0x89b5c <cmd_error>, harg=3106820) at eval.c:1629 #28 0x89c6c in command_loop_2 (dummy=3106820) at cmdloop.c:252 #29 0xad680 in internal_catch (tag=3189076, func=0x89c20 <command_loop_2>, arg=3106820, threw=0x0) at eval.c:1304 #30 0x88ee8 in initial_command_loop (load_me=564256) at cmdloop.c:301 #31 0xa922c in xemacs_21_2_b26_sparc_sun_solaris2_7 (argc=2, argv=0xffbeeed4, envp=0xffbeeee0, restart=0) at emacs.c:1898 #32 0xa9a64 in main (argc=2, argv=0xffbeeed4, envp=0xffbeeee0) at emacs.c:2323 (gdb) Hope this is helpful. Since it's repeatable, I can supply whatever information anyone would want. Ray

1 participants
0 comments

PATCH: remove warning in gpmevent.c 24 years, 10 months

William M. Perry

Per martin's request... -bp Index: gpmevent.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/gpmevent.c,v retrieving revision 1.5.2.3 diff -c -w -r1.5.2.3 gpmevent.c *** gpmevent.c 1999/11/28 18:15:48 1.5.2.3 --- gpmevent.c 2000/01/10 11:50:36 *************** *** 452,458 **** return; } ! return (orig_next_event_cb (event)); } static void hook_event_callbacks_once (void) --- 452,458 ---- return; } ! orig_next_event_cb (event); } static void hook_event_callbacks_once (void)

2 participants
1 comments

Re: [Q] about set-extent-*-glyph 24 years, 10 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > >Neither can I. The code looks like it's able to handle placing > >glyphs on a detached or string extent without problems. > > Isn't the argument string-or-buffer rather than just buffer? The problem is that set-extent-*-glyph functions end up doing: set_extent_glyph_1 (Lisp_Object extent_obj, Lisp_Object glyph, int endp, Lisp_Object layout_obj) { EXTENT extent = decode_extent (extent_obj, DE_MUST_HAVE_BUFFER); ^^^^^^^^^^^^^^^^^^^ I don't see why this function requires the extent to be attached to a buffer. It should be perfectly legal to attach it later.

1 participants
0 comments

Re: [Q] about set-extent-*-glyph 24 years, 10 months

Hrvoje Niksic

Didier Verna <didier(a)xemacs.org> writes: > Why do these functions require extents to be associated with a > buffer ? I can't find any reason for it. Neither can I. The code looks like it's able to handle placing glyphs on a detached or string extent without problems.

2 participants
1 comments

[Q] about set-extent-*-glyph 24 years, 10 months

Didier Verna

Why do these functions require extents to be associated with a buffer ? I can't find any reason for 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

Re: Info disaster? 24 years, 10 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > I think the problem in Hrvoje's setup is really that all the info > files are gzipped. Given today's price for disk space, I think > unpacking them would be the easiest way to fix the problem. Oh, I agree with that. But you can't do that under Debian. :-( Just like you can't ungzip man-pages, files under /usr/doc/ and /usr/share/doc/, etc. etc. What a bunch of losers. :-( > Stephen> If so, shouldn't the only cache we trust be one we make > Stephen> ourselves? > > Sure, but in that case, let's abandon dir files entirely. Maybe that's exactly what we should do. Maybe.

1 participants
0 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 January 2000