December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Xemacs 21.2.8 core dumps on FreeBSD 2.2.6 25 years, 11 months

Norbert Koch

Richard Coleman <coleman(a)math.gatech.edu> writes: > I just pulled down 21.2.8 and built it on FreeBSD 2.2.6. It > immediately core dumps for me. I was running it from the > build directory. It seems to work for me, at least it doesn't dump core on the spot :-) XEmacs 21.2 "Artemis" [Lucid] (i686-pc-linux, Mule) of Tue Dec 29 1998 on apollonius.delta-ii.de Cheers, norbert. -- Somebody should have told him that being a physicist, on a planet where the smartest animals hate being alive so much, means never having to say you're sorry.

1 participants
0 comments

Xemacs 21.2.8 core dumps on FreeBSD 2.2.6 25 years, 11 months

Richard Coleman

I just pulled down 21.2.8 and built it on FreeBSD 2.2.6. It immediately core dumps for me. I was running it from the build directory. I haven't built any betas recently, so I don't know if I'm doing something wrong. I just pulled down the main tarball, and didn't pull down any packages. I've attached the Installation file, and a backtrace from gdb. Let me know if you need something else. -- Richard Coleman coleman(a)math.gatech.edu uname -a: FreeBSD phaedrus.cmb.net 2.2.6-RELEASE FreeBSD 2.2.6-RELEASE #0: Wed Mar 25 02:28:49 GMT 1998 jkh＠time.cdrom.com:/usr/src/sys/compile/GENERIC i386 ./configure '--prefix=/home/rcoleman/beta' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' XEmacs 21.2-b8 "Artemis" configured for `i386-unknown-freebsd2.2.6'. Where should the build process find the source code? /home/rcoleman/xemacs/xemacs-21.2.8 What installation prefix should install use? /home/rcoleman/beta What operating system and machine description files should XEmacs use? `s/freebsd.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes 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 Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. -------------------------------------------------------------------- WARNING: Compiling without PNG image support. Reason: PNG library version too old (pre 1.0.2)! WARNING: You should strongly consider installing the PNG libraries. WARNING: Otherwise certain images and glyphs may not display. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) -------------------------------------------------------------------- Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "flock" for locking mail spool files. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. 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: --------------------------------------------------------- (gdb) bt #0 0x203e5b61 in ?? () #1 0x48817 in fatal_error_signal (sig=11) at emacs.c:264 #2 0xefbfdfdc in ?? () #3 0x51612 in Ffuncall (nargs=1, args=0xefbfcc40) at eval.c:3189 #4 0x1adc8 in execute_optimized_program ( program=0x22eaf4 "\bAk?-%B\013\e\034E\bF\"\210\016\a?-\026H\016\t!Ja+\fK\b\016\fM\016\t!#*\003N *\207", stack_depth=5, constants_data=0x22ea78) at bytecode.c:750 #5 0x1a688 in funcall_compiled_function (fun=2288184, nargs=3, args=0xefbfcd50) at bytecode.c:530 #6 0x51791 in Ffuncall (nargs=4, args=0xefbfcd4c) at eval.c:3221 #7 0x1adc8 in execute_optimized_program ( program=0x22ea10 "\b,\004A \020\n＠\e\f\013＠a+\n\013\211A\rP!\210*\a\f\rB\nB\022)F\r\b\016\a#\207", stack_depth=4, constants_data=0x22e9dc) at bytecode.c:750 #8 0x1a688 in funcall_compiled_function (fun=2288020, nargs=4, args=0xefbfce58) at bytecode.c:530 #9 0x51791 in Ffuncall (nargs=5, args=0xefbfce54) at eval.c:3221 #10 0x1adc8 in execute_optimized_program ( program=0x22eb98 "＠\t\n\013D$\210E\t\016\006\n\013$\207", stack_depth=5, constants_data=0x22eb68) at bytecode.c:750 #11 0x1a688 in funcall_compiled_function (fun=2288416, nargs=2, args=0xefbfcf64) at bytecode.c:530 #12 0x51791 in Ffuncall (nargs=3, args=0xefbfcf60) at eval.c:3221 #13 0x1adc8 in execute_optimized_program ( program=0x22ecdc "\b,\n\t,\aBCB!\210\207DE\b\t#\036\006GH\016\006\"\210\016\006)\207", stack_depth=4, constants_data=0x22eca4) at bytecode.c:750 #14 0x1a688 in funcall_compiled_function (fun=2288748, nargs=2, args=0xefbfd06c) at bytecode.c:530 #15 0x51791 in Ffuncall (nargs=3, args=0xefbfd068) at eval.c:3221 #16 0x1adc8 in execute_optimized_program ( program=0xefbfd0c8 "＠AB\013!\"\210DEFG\016\bB\013!#C#\210I\026\n＠\207q#", stack_depth=7, constants_data=0x23f1bc) at bytecode.c:750 #17 0x1e737 in Fbyte_code (instructions=1612968328, constants=-2145128008, stack_depth=536870919) at bytecode.c:2400 #18 0x50c4e in Feval (form=1076097400) at eval.c:2986 #19 0x4e4d7 in run_condition_case_handlers (val=1078148388, var=-1607671708) at eval.c:761 #20 0x4e810 in condition_case_3 (bodyform=1076097300, var=-1607671708, handlers=1076097376) at eval.c:1623 #21 0x1ba3b in execute_rare_opcode (stack_ptr=0xefbfd2e8, program_ptr=0x23f35a "\210\016\f\016\ta,\bD\026\n\016\f\026\013)\016\n+\005\016\013\026\f+D\026\022\016\023+\rT U\016\026.\003W Q\026\030＠Y!\210E\207\021", opcode=Bcondition_case) at bytecode.c:1275 #22 0x1aba4 in execute_optimized_program ( program=0x23f324 "＠A!\210\n+\aC\nD\211#\210E\026\006E\211\016\aDa+\004H*\003 \016\a\036\t\036\n\036\013\016\t\036\f\016\a+\bM\016\016!\210*\006OPQ\217\210\016\f\016\ta,\bD\026\n\016\f\026\013)\016\n+\005\016\013\026\f+D\026\022\016\023+\rT U\016\026.\003W Q\026\030＠Y!\210E\207\021", stack_depth=4, constants_data=0x23f0ac) at bytecode.c:660 #23 0x1a688 in funcall_compiled_function (fun=2355340, nargs=0, args=0xefbfd3ec) at bytecode.c:530 #24 0x51791 in Ffuncall (nargs=1, args=0xefbfd3e8) at eval.c:3221 #25 0x1adc8 in execute_optimized_program ( program=0x23ed28 "\bA\031BC\034\035F\t!\021GH!+\004I \210\016\n+\020\016\013,\fLMN\016\n!OQ! \210P \210*Q \210rRS!q\210T \210UV!\210\016\027Xa+\005\016\031 \210)Z [a+\bK ,\004\ \210] \210V\026\036K -\004_C!)\207", stack_depth=4, constants_data=0x23ec54) at bytecode.c:750 #26 0x1a688 in funcall_compiled_function (fun=2354228, nargs=0, args=0xefbfd4f4) at bytecode.c:530 #27 0x51791 in Ffuncall (nargs=1, args=0xefbfd4f0) at eval.c:3221 #28 0x1adc8 in execute_optimized_program ( program=0x23e6a0 "\b+\005AB!\207C\020D \211\035+\030\rG\016\006GW+\020G\016\006!G\r!k+\006H\r!\026\006)I\016\006!\026\006J \210K \210\016\f.\aMN!-\002C\036\fO\016\020\016\021\"\026\022\016\f+\nSTU\016\022\"V\"\210\016\022,\006W \210*\fX\016\022\016\031\016\032\016\f$\210[ \210)\016\034,\022\016\035+\016^_`\016!!\016\035\"bC#\210\016\034,\024\016\031,\006c\016$!\210c\016%!\210c\016&!\210g\216h )\207", stack_depth=6, constants_data=0x23e4d4) at bytecode.c:750 #29 0x1a688 in funcall_compiled_function (fun=2352308, nargs=0, args=0xefbfd594) at bytecode.c:530 #30 0x50ee1 in Feval (form=1077344212) at eval.c:3045 #31 0x4e2a0 in condition_case_1 (handlers=-1607671708, bfun=0x50550 <Feval>, barg=1077344212, hfun=0x2771c <cmd_error>, harg=-1607671804) at eval.c:1640 #32 0x288a5 in top_level_1 (dummy=-1607671804) at cmdloop.c:205 #33 0x4e0cc in internal_catch (tag=-1607589740, func=0x2887c <top_level_1>, arg=-1607671804, threw=0x0) at eval.c:1315 #34 0x278c1 in initial_command_loop (load_me=-1607671804) at cmdloop.c:284 #35 0x49a49 in xemacs_21_2_b8_i386_unknown_freebsd2_2_6 (argc=1, argv=0xefbfd80c, envp=0xefbfd814, restart=0) at emacs.c:1718 #36 0x4a45a in main (argc=1, argv=0xefbfd80c, envp=0xefbfd814) at emacs.c:2147

1 participants
0 comments

PGP signatures for files on ftp.xemacs.org 25 years, 11 months

Martin Buchholz

I suspect that most people who download our releases ignore the PGP signature files that are included in our releases. I myself learned about PGP merely to make releases. So how about placing the PGP signature files in a separate pgp-signature subdirectory instead of littering the directory containing the beta releases? Personally, I am inclined to nuke the .sig files altogether. How many of you actually verify the PGP signatures? Martin

1 participants
0 comments

Re: `The Bazaar' conference in new york? 25 years, 11 months

SL Baur

Colin Rafferty <craffert(a)ms.com> writes in xemacs-beta(a)xemacs.org: > SL Baur writes: >> New York (IMO) is definitely someplace to visit. I wouldn't want to >> live there, but it is a wonderful place to visit. > Well, we wouldn't want anyone who didn't know better to be living > here, either. I see. As we say in California, "New York is East, dude." :-)

1 participants
0 comments

Setting the modeline-* face attributes 25 years, 11 months

Sean MacLennan

I want to set the foreground colour for the `modeline-mousable' and `modeline-buffer-id' faces from the .Xdefaults file to keep all the colour specifications in one place. However, this does not seem to work in 21.0-b60 or 21.2-b7. A glance at the code in modeline.el seems to be: 1. make-face 2. set-face-parent to `modeline' 3. set defaults (e.g. firebrick for modeline-mousable) If you do not specify a foreground, step 3 sets it to the default. If you do specify a foreground, step 1 gets the foreground, and step 2 reverts it to the default foreground for the modeline. (I tested this by commenting out the set-face-parent call.) I was able to fix the problem by putting the following lines in my .emacs file: (when (featurep 'x) (x-init-face-from-resources 'modeline-mousable nil t) (x-init-face-from-resources 'modeline-buffer-id nil t)) It would be nice though, if set-face-parent could know not to override the settings from the .Xdefaults file. Sean -- Sean MacLennan Just crank that volume to the point of pain. Ottawa, Canada Why waste good music on a brain? http://www.storm.ca/~seanm (Spinal Tap)

1 participants
0 comments

Ediff bug? 25 years, 11 months

Enrico Brunetta

Hello there. I just found a possible bug in ediff. ediff-version "2.71" ediff-date "July 24, 1998" when trying to use ediff with the latest Xemacs (b60) and with the following options set: (setq ediff-use-toolbar-p t) (setq ediff-window-setup-function 'ediff-setup-windows-plain) (setq ediff-use-faces t) (setq ediff-highlight-all-diffs t) When I click on the "next difference" toolbar icon I get the following error: Signaling: (error "ediff-toolbar-next-difference: This command runs in Ediff Control Buffer only!") signal(error ("ediff-toolbar-next-difference: This command runs in Ediff Control Buffer only!")) cerror("%S: This command runs in Ediff Control Buffer only!" ediff-toolbar-next-difference) apply(cerror ("%S: This command runs in Ediff Control Buffer only!" ediff-toolbar-next-difference)) error("%S: This command runs in Ediff Control Buffer only!" ediff-toolbar-next-difference) ediff-next-difference(1) #<compiled-function nil "...(7)" [nil ediff-grab-mouse ediff-next-difference 1] 2 nil nil>() call-interactively(ediff-toolbar-next-difference) Does anybody know how to fix this ? Enrico. P.S. please reply to me via email. I'm not subscribed to xemacs-beta. Thanks.

3 participants
3 comments

21.2.6 death under mule and mswindows 25 years, 11 months

Andy Piper

I'm not sure whether someone has reported this. Anyway 21.2.6 dies in redisplay when built with mule under mswindows and trying to print out the border glyphs. I thought it was my mega patch but it exists in 21.2.6 also. This is easy to reproduce - just do xemacs -q. andy Breakpoint 1, 0x6a4b38 in abort () (gdb) where #0 0x6a4b38 in abort () #1 0x4536a5 in assert_failed (file=0x4bfd84 "objects.h", line=144, expr=0x4c00b5 "RECORD_TYPEP (obj, lrecord_font_instance) || MARKED_RECORD_P (obj)") at emacs.c:2630 #2 0x4c0150 in error_check_font_instance (obj={gu = {type = Lisp_Type_Record, val = 2472074}, s = {bits = 0, val = 4944148}, u = {bits = 0, val = 4944148}, ui = 9888296, i = 9888296, v = 0x96e228, cv = 0x96e228}) at objects.h:144 #3 0x48097c in mswindows_output_string (w=0x100d3400, dl=0x101d13f0, buf=0x101ae260, xpos=632, xoffset=0, clip_start=632, width=8, findex=12) at redisplay-msw.c:540 #4 0x48250e in mswindows_output_display_block (w=0x100d3400, dl=0x101d13f0, block=0, start=0, end=80, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-msw.c:1243 #5 0x57d3a9 in output_display_line (w=0x100d3400, cdla=0x101617c0, ddla=0x101617a0, line=14, force_start=-1, force_end=-1) at redisplay-output.c:686 #6 0x57ecbf in redisplay_output_window (w=0x100d3400) at redisplay-output.c:1315 #7 0x56dad6 in redisplay_window (window={gu = {type = Lisp_Type_Record, val = 67325184}, s = {bits = 0, val = 134650368}, u = {bits = 0, val = 134650368}, ui = 269300736, i = 269300736, v = 0x100d3400, cv = 0x100d3400}, skip_selected=0) at redisplay.c:5242 #8 0x56dfd4 in redisplay_frame (f=0x100d3000, preemption_check=0) at redisplay.c:5418 #9 0x56e37d in redisplay_device (d=0x1013bf00) at redisplay.c:5502 #10 0x56e93d in redisplay_without_hooks () at redisplay.c:5618 #11 0x56eb6c in redisplay () at redisplay.c:5686 #12 0x4d6f87 in Fsit_for (seconds={gu = {type = Lisp_Type_Int_Even, val = 0}, s = {bits = 1, val = 0}, u = {bits = 1, val = 0}, ui = 1, i = 1, v = 0x1, cv = 0x1}, nodisplay={gu = {type = Lisp_Type_Record, val = 1983489}, s = {bits = 0, val = 3966978}, u = {bits = 0, val = 3966978}, ui = 7933956, i = 7933956, v = 0x791004, cv = 0x791004}) at event-stream.c:2814 #13 0x45aff2 in Ffuncall (nargs=2, args=0x2cff268) at eval.c:3189 #14 0x4195ca in execute_optimized_program (program=0x2cff324 "À\tÂÃ#\024Å \210eb\210ÆÇ!\210È \026\tÃ\207", stack_depth=4, constants_data=0x709de4) at bytecode.c:750 #15 0x41f8ed in Fbyte_code (instructions={gu = {type = Lisp_Type_Record, val = 1845093}, s = {bits = 0, val = 3690186}, u = {bits = 0, val = 3690186}, ui = 7380372, i = 7380372, v = 0x709d94, cv = 0x709d94}, constants={gu = {type = Lisp_Type_Record, val = 1845109}, s = {bits = 0, val = 3690218}, u = {bits = 0, val = 3690218}, ui = 7380436, i = 7380436, v = 0x709dd4, cv = 0x709dd4}, stack_depth={gu = {type = Lisp_Type_Int_Even, val = 2}, s = {bits = 1, val = 4}, u = {bits = 1, val = 4}, ui = 9, i = 9, v = 0x9, cv = 0x9}) at bytecode.c:2398 #16 0x45a62b in Feval (form={gu = {type = Lisp_Type_Record, val = 1845087}, s = {bits = 0, val = 3690174}, u = {bits = 0, val = 3690174}, ui = 7380348, i = 7380348, v = 0x709d7c, cv = 0x709d7c}) at eval.c:2986 #17 0x4570b6 in internal_catch (tag={gu = {type = Lisp_Type_Record, val = 2009944}, s = {bits = 0, val = 4019888}, u = {bits = 0, val = 4019888}, ui = 8039776, i = 8039776, v = 0x7aad60, cv = 0x7aad60}, func=0x459efc <Feval>, arg={gu = {type = Lisp_Type_Record, val = 1845087}, s = {bits = 0, val = 3690174}, u = {bits = 0, val = 3690174}, ui = 7380348, i = 7380348, v = 0x709d7c, cv = 0x709d7c}, threw=0x0) at eval.c:1315 #18 0x41b97c in execute_rare_opcode (stack_ptr=0x2cff618, program_ptr=0x709e84 "\210*rÌÆ!q\210Í \210\016\016;«\005\016\016c\210ÏÄ!)\207\016\020ÑÄ\211\211\211\211\211\036\02 2\036\023\036\024\036\025\036\026\036\027\036\030\036\031\b\205\237", opcode=Bcatch) at bytecode.c:1256 #19 0x419051 in execute_optimized_program (program=0x709e60 "\b¬;\t?\205ó", stack_depth=8, constants_data=0x709c4c) at bytecode.c:660 #20 0x41897c in funcall_compiled_function (fun={gu = {type = Lisp_Type_Record, val = 1845000}, s = {bits = 0, val = 3690000}, u = {bits = 0, val = 3690000}, ui = 7380000, i = 7380000, v = 0x709c20, cv = 0x709c20}, nargs=0, args=0x2cff7bc) at bytecode.c:527 #21 0x45b267 in Ffuncall (nargs=1, args=0x2cff7b8) at eval.c:3221 #22 0x4195ca in execute_optimized_program (program=0x7092f4 "\bA\031ÂÃ\034\035Æ\t!\021ÇÈ!«\004É \210\016\n«\020\016\013¬\fÌÍÎ\016\n!ÏQ! \210Ð \210*Ñ \210rÒÓ!q\210Ô \210ÕÖ!\210\016\027Øa«\005\016\031 \210)Ú Ûa«\bË ¬\004Ü \210Ý \210Ö\026\036Ë \004ßÃ!)\207", stack_depth=4, constants_data=0x709214) at bytecode.c:750 #23 0x41897c in funcall_compiled_function (fun={gu = {type = Lisp_Type_Record, val = 1844346}, s = {bits = 0, val = 3688692}, u = {bits = 0, val = 3688692}, ui = 7377384, i = 7377384, v = 0x7091e8, cv = 0x7091e8}, nargs=0, args=0x2cff94c) at bytecode.c:527 #24 0x45b267 in Ffuncall (nargs=1, args=0x2cff948) at eval.c:3221 #25 0x4195ca in execute_optimized_program (program=0x708bd0 "\b«\005ÁÂ!\207Ã\020Ä \211\035«\030\rG\016\006GW«\020Ç\016\006!Ç\r!k«\006È\r!\026\006)É\016\006!\0 26\006Ê \210Ë \210\016\f®\aÍÎ!\002Ã\036\fÏ\016\020\016\021\"\026\022\016\f«\nÓÔÕ\016\022\ "Ö\"\210\016\022¬\006× \210ª\fØ\016\022\016\031\016\032\016\f$\210Û \210)\016\034¬\022\016\035«\016Þßà\016!!\016\035\"âÃ#\210\016\034¬\024\016\0 31¬\006ã\016$!\210ã\016%!\210ã\016&!\210ç\216è )\207", stack_depth=6, constants_data=0x7089b4) at bytecode.c:750 #26 0x41897c in funcall_compiled_function (fun={gu = {type = Lisp_Type_Record, val = 1843810}, s = {bits = 0, val = 3687620}, u = {bits = 0, val = 3687620}, ui = 7375240, i = 7375240, v = 0x708988, cv = 0x708988}, nargs=0, args=0x2cffa64) at bytecode.c:527 #27 0x45aa7b in Feval (form={gu = {type = Lisp_Type_Record, val = 2226998}, s = {bits = 0, val = 4453996}, u = {bits = 0, val = 4453996}, ui = 8907992, i = 8907992, v = 0x87ecd8, cv = 0x87ecd8}) at eval.c:3045 #28 0x45757b in condition_case_1 (handlers={gu = {type = Lisp_Type_Record, val = 1983517}, s = {bits = 0, val = 3967034}, u = {bits = 0, val = 3967034}, ui = 7934068, i = 7934068, v = 0x791074, cv = 0x791074}, bfun=0x459efc <Feval>, barg={gu = {type = Lisp_Type_Record, val = 2226998}, s = {bits = 0, val = 4453996}, u = {bits = 0, val = 4453996}, ui = 8907992, i = 8907992, v = 0x87ecd8, cv = 0x87ecd8}, hfun=0x42c888 <cmd_error>, harg={gu = {type = Lisp_Type_Record, val = 1983489}, s = {bits = 0, val = 3966978}, u = {bits = 0, val = 3966978}, ui = 7933956, i = 7933956, v = 0x791004, cv = 0x791004}) at eval.c:1640 #29 0x42c95c in top_level_1 (dummy={gu = {type = Lisp_Type_Record, val = 1983489}, s = {bits = 0, val = 3966978}, u = {bits = 0, val = 3966978}, ui = 7933956, i = 7933956, v = 0x791004, cv = 0x791004}) at cmdloop.c:205 #30 0x4570b6 in internal_catch (tag={gu = {type = Lisp_Type_Record, val = 2003232}, s = {bits = 0, val = 4006464}, u = {bits = 0, val = 4006464}, ui = 8012928, i = 8012928, v = 0x7a4480, cv = 0x7a4480}, func=0x42c91c <top_level_1>, arg={gu = {type = Lisp_Type_Record, val = 1983489}, s = {bits = 0, val = 3966978}, u = {bits = 0, val = 3966978}, ui = 7933956, i = 7933956, v = 0x791004, cv = 0x791004}, threw=0x0) at eval.c:1315 #31 0x42caa5 in initial_command_loop (load_me={gu = {type = Lisp_Type_Record, val = 1983489}, s = {bits = 0, val = 3966978}, u = {bits = 0, val = 3966978}, ui = 7933956, i = 7933956, v = 0x791004, cv = 0x791004}) at cmdloop.c:284 #32 0x45173d in xemacs_21_2_b6_i586_pc_cygwin32 (argc=2, argv=0x2cfff5c, envp=0x10086d00, restart=0) at emacs.c:1715 #33 0x45278e in main (argc=2, argv=0x2cfff5c, envp=0x10086d00) at emacs.c:2144 #34 0x100040b4 in dll_crt0_1 () #35 0x100040ea in dll_crt0 () #36 0x6a4841 in cygwin_crt0 () (gdb) --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

2 participants
1 comments

more subwindow/widget fiddling 25 years, 11 months

Andy Piper

This patch allows for the normal use of gui_item keywords in widget definitions i.e. [button :descriptor "ok" :active t] rather than [button :descriptor ["ok" :active t]]. It also provides support for glyphs in buttons (support for others would be possible but I don't know how much meaning it has). see glyph-tests.el for details. The patch also nukes all remaining warnings from the cygwin build. I ought to try porting some of the wid-edit.el stuff to native widgets but the size of the task defeats me at the moment. andy 1998-12-28 Andy Piper <andy(a)xemacs.org> * glyphs-msw.c (mswindows_button_instantiate): cope with buttons that have an image provided. * glyphs.h: add Q_image decl. * glyphs-widget.c new functionality allowing images in widgets. (check_valid_glyph_or_image): new function to validate glyphs passed in through :image. (widget_normalize): new function. convert :image parameters into real glyphs if not already so. (widget_instantiate_1): mess with size parameters to be similar to :image if provided. (syms_of_glyphs_widget): new keyword :image. (image_instantiator_format_create_glyphs_widget): normalize buttons and allow :image. 1998-12-27 Andy Piper <andy(a)xemacs.org> * frame-msw.c (mswindows_init_frame_1): warning elimination. * glyphs-widget.c (check_valid_anything): no-op function. (check_valid_callback): check callbacks in gui_items. (check_valid_symbol): as it sounds. (check_valid_string_or_vector): ditto. (widget_validate): modified for descriptors that are vectors or sequences of keyword/val pairs. (widget_instantiate_1): ditto. (image_instantiator_format_create_glyphs_widget): allow gui_item keywords in the instantiator. * gui.c (gui_parse_item_keywords_internal): renamed from gui_parse_item_keywords but taking error behaviour. (gui_parse_item_keywords): use it. (gui_parse_item_keywords_no_errors): ditto. (gui_item_add_keyval_pair): add Error_behavior flag and only signal invalid keywords if required. * gui.h: new gui signatures. * menubar.c (menu_parse_submenu_keywords): use new gui_item_add_keyval_pair signature. * s/cygwin32.h: modify PTY_ITERATION to eliminate warnings. --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Re: why has mule gone all verbose? 25 years, 11 months

SL Baur

Norbert Koch <n.koch(a)delta-ii.de> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> Norbert Koch <n.koch(a)delta-ii.de> writes in xemacs-beta(a)xemacs.org: >> >> > SL Baur <steve(a)xemacs.org> writes: >> ... >> >> Do you know how your X11 was compiled? > [...] >> #define X_LOCALE 1 > Ok, this one's missing here. Right. It's not necessarily set by default and you have to make sure libX11.so was compiled with this flag if you wish to use xfs for localized menubars. IIRC the XFree86 default is to define X_LOCALE if building against Linux libc5, and to not define it when building against GNU libc 2. GNU libc 2.0 does not support Asian locales, but GNU libc 2.1 reportedly does, though I haven't tested it yet.

3 participants
2 comments

Re: `The Bazaar' conference in new york? 25 years, 11 months

Hrvoje Niksic

Colin Rafferty <craffert(a)ms.com> writes: > > William M Perry <wmperry(a)aventail.com> writes in xemacs-beta(a)xemacs.org: > > >> Wondered if anyone was going to be going to the bazaar conference > >> (http://thebazarr.org/) in new york in march. > > I will definitely be going, if I can actually find any information > about it (are you sure that's the correct URL?). Bill misspelled ``bazaar''. Try <URL:http://www.thebazaar.org/>.

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 December 1998