March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Fix documentation regarding dumping XEmacs/Mule 25 years, 3 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > + mule-base - Needed if you want to run XEmacs with MULE with a > + non-English language environment. Ok... Jan

1 participants
0 comments

Re: BUG REPORT: inadequately documented changes 25 years, 3 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > Unfortunately this requires that a few packages are already in place. > You will have to install them by hand as above or use a SUMO tarball. > This requirement will hopefully go away in the future. The packages > you need are: > ... > and optionally: > > mailcrypt - If you have PGP installed and want to verify the > signature of the index file. > mule-base - Needed if you want to compile XEmacs with MULE. > > The last line should be removed. No!. All the rest of the text can go, but you should still install mule-base by hand. The difference is that you now can do that after compiling. The reason is that the package placement code takes the location of 'mule-base' as the hint where to put Mule related packages. So the last line should be replaced by mule-base - Needed if you compiled XEmacs with MULE. Jan P.S. If you don't care about Mule packages going into xemacs-packages, it is not needed.

1 participants
0 comments

Re: extent-data in bbdb-xemacs.el 25 years, 3 months

Didier Verna

Les Schaffer writes: Les> Symbol's function definition is void: extent-data ----- Les> can someone post the fix? i gather from the previous poster its small and Les> painless. You've got to change (extent-data e) to (extent-property e 'data) at two places IIRC. The current CVS version of bbdb (from the XEmacs cvs server) needs to be resynchronized with the current bbdb version. Steve will do this when he comes back from Japan. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

BUG REPORT: redisplay assertion failure 25 years, 3 months

Martin Buchholz

When I start up my heavily customized[1] xemacs, it starts up a shell buffer automatically. If I do this simple operation: C-x 2 I get two windows (as expected). The top one is still displaying the first shell prompt. The lower window is completely empty (this definitely seems wrong). Now Button-1 click in the lower (empty) window. Kaboom!! Fatal error: assertion failed, file /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c, line 6799, cur_elt >= 0 This has been reproduced in debug and optimized, mule and latin-1 xemacs. I cannot (yet) reproduce it in a -vanilla xemacs. I might work on fixing this, but I'm afraid I won't return from an excursion into redisplay.c for a year or so. Footnotes: [1] That's customized, not `custom'-ized. P.S. Here's the C stack: #0 0xee9f4340 in _kill () #1 0xabea0 in fatal_error_signal (sig=6) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/emacs.c:269 #2 <signal handler called> #3 0xee9f4340 in _kill () #4 0xee9ba59c in abort () #5 0xafcf4 in assert_failed (file=0x3457f8 "/net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c", line=6799, expr=0x345c60 "cur_elt >= 0") at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/emacs.c:2646 #6 0x1f0ac4 in start_with_line_at_pixpos (w=0x83c600, point=52, pixpos=323) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:6799 #7 0x1ea6e0 in regenerate_window_point_center (w=0x83c600, point=52, type=1) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:4797 #8 0x1ebb10 in redisplay_window (window={...}, skip_selected=0) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:5166 #9 0x1ec918 in redisplay_frame (f=0x5f0400, preemption_check=0) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:5451 #10 0x1ecea8 in redisplay_device (d=0x650600) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:5536 #11 0x1ed818 in redisplay_without_hooks () at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:5653 #12 0x1edad8 in redisplay () at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/redisplay.c:5722 #13 0x10e4b8 in Fsit_for (seconds={...}, nodisplay={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/event-stream.c:2814 #14 0xbc244 in Ffuncall (nargs=3, args=0xefffd384) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:3189 #15 0x6a8bc in execute_optimized_program (program=0xefffd560 "À\tÂ\"\003Ã \207\013Z\004ïÿÕ\200ïÿÕ ", stack_depth=3, constants_data=0x7b83d0) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/bytecode.c:754 #16 0x72d48 in Fbyte_code (instructions={...}, constants={...}, stack_depth={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/bytecode.c:2402 #17 0xbb1dc in Feval (form={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:2986 #18 0xb5988 in condition_case_1 (handlers={...}, bfun=0xba59c <Feval>, barg={...}, hfun=0xb5a04 <run_condition_case_handlers>, harg={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:1640 #19 0xb61fc in condition_case_3 (bodyform={...}, var={...}, handlers={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:1718 #20 0x6d31c in execute_rare_opcode (stack_ptr=0xefffdabc, program_ptr=0x835ae2 "\207ïÞ¾ïÞ¾ïÞ¾ïÞ¾ïÞ¾ïÞ¾ïÞ¾ï(", opcode=Bcondition_case) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/bytecode.c:1279 #21 0x6a32c in execute_optimized_program (program=0x835ad8 "\b\b\t\005ÂÃÄ\217\207ïÞ¾ïÞ¾ïÞ¾ïÞ¾ïÞ¾ïÞ¾ïÞ¾ï(", stack_depth=3, constants_data=0x7ab650) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/bytecode.c:664 #22 0x69c64 in funcall_compiled_function (fun={...}, nargs=0, args=0xefffe044) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/bytecode.c:527 #23 0xbc7e4 in Ffuncall (nargs=1, args=0xefffe040) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:3221 #24 0xbe454 in run_hook_with_args_in_buffer (buf=0x709e00, nargs=1, args=0xefffe040, cond=RUN_HOOKS_TO_COMPLETION) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:3671 #25 0xbe4dc in run_hook_with_args (nargs=1, args=0xefffe040, cond=RUN_HOOKS_TO_COMPLETION) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:3684 #26 0xbddc0 in Frun_hooks (nargs=1, args=0xefffe040) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:3539 #27 0xbe824 in run_hook (hook={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:3785 #28 0xc0030 in catch_them_squirmers_run_hook (hook_symbol={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:4229 #29 0xb5988 in condition_case_1 (handlers={...}, bfun=0xc0004 <catch_them_squirmers_run_hook>, barg={...}, hfun=0xbfb54 <allow_quit_safe_run_hook_caught_a_squirmer>, harg={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:1640 #30 0xc04a8 in safe_run_hook_trapping_errors (warning_string=0x327190 "Error in `post-command-hook' (setting hook to nil)", hook_symbol={...}, allow_quit=1) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:4290 #31 0x11313c in post_command_hook () at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/event-stream.c:4429 #32 0x112e4c in execute_command_event (command_builder=0x696000, event={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/event-stream.c:4348 #33 0x113ad0 in Fdispatch_event (event={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/event-stream.c:4636 #34 0x7f7f8 in Fcommand_loop_1 () at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/cmdloop.c:578 #35 0x7f378 in command_loop_1 (dummy={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/cmdloop.c:493 #36 0xb5988 in condition_case_1 (handlers={...}, bfun=0x7f334 <command_loop_1>, barg={...}, hfun=0x7e568 <cmd_error>, harg={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:1640 #37 0x7e7a4 in command_loop_3 () at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/cmdloop.c:255 #38 0x7e7e8 in command_loop_2 (dummy={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/cmdloop.c:266 #39 0xb526c in internal_catch (tag={...}, func=0x7e7d4 <command_loop_2>, arg={...}, threw=0x0) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/eval.c:1315 #40 0x7ec08 in initial_command_loop (load_me={...}) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/cmdloop.c:304 #41 0xadb30 in xemacs_21_2_b12_sparc_sun_solaris2_5_1 (argc=1, argv=0xefffea34, envp=0xefffea3c, restart=0) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/emacs.c:1728 #42 0xaecb0 in main (argc=1, argv=0xefffea34, envp=0xefffea3c) at /net/wanchai/export1/xemacs/home/martin/x/ws/dev/src/emacs.c:2162

1 participants
0 comments

Re: BUG REPORT: inadequately documented changes 25 years, 3 months

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > The following from README.packages seems to no longer be correct. Steve? This section can be removed. > Note to MULE users > ------------------ > Unlike all other packages the mule-base package is used at build/dump > time. This means that you need this available before compiling XEmacs > with MULE. Also wrong is the first question in the Real Real Quickstart FAQ: Q. Do I need to have the packages to compile XEmacs? A. If you want to compile with MULE, you need the mule-base package installed. Otherwise, no package is required before compilation. The correct answer is no. and in this block of text: Unfortunately this requires that a few packages are already in place. You will have to install them by hand as above or use a SUMO tarball. This requirement will hopefully go away in the future. The packages you need are: ... and optionally: mailcrypt - If you have PGP installed and want to verify the signature of the index file. mule-base - Needed if you want to compile XEmacs with MULE. The last line should be removed. I'll send off a patch to xemacs-patches.

1 participants
0 comments

BUG REPORT: Font menu font selection 25 years, 3 months

Martin Buchholz

If I start up xemacs, the font used is Lucidatypewriter 14. The Options Menu the agrees with this, as indicated by the green diamonds. The font was set using the following X resource: Emacs.default.attributeFont: -*-Lucidatypewriter-Medium-R-*-*-*-120-*-*-*-*-*-* If I then change the font SIZE from 14 to 18 using Options->Size->18, the font size does indeed change, but the typeface changes from Lucidatypewriter to Courier. I have to use Options->Font->Lucidatypewriter to get back to my preferred typeface. This seems like a clear user interface bug. Although `custom' is involved here, this is not obvious to the untrained observer. Martin

1 participants
0 comments

BUG REPORT: inadequately documented changes 25 years, 3 months

Martin Buchholz

The following from README.packages seems to no longer be correct. Steve? Note to MULE users ------------------ Unlike all other packages the mule-base package is used at build/dump time. This means that you need this available before compiling XEmacs with MULE.

1 participants
0 comments

BUG REPORT: mule-packages sometimes incorrectly used by latin-1 xemacs 25 years, 3 months

Martin Buchholz

If I have a directory structure like this: /foo/pkgs/xemacs-packages /foo/pkgs/mule-packages and I configure --package-path=~/.xemacs:/foo/pkgs/ --without-mule ... Then the resulting xemacs, when run in place, has a load-path that includes subdirectories of /foo/pkgs/mule-packages. And this warning appears: (1) (warning/warning) Autoload error in: /usr/users/martin/x/pkgs/mule-packages/lisp/skk/auto-autoloads: Cannot open load file: mule I think I'm using the package system the way it was designed, and the mule-packages subdirectories should not appear on the load-path. Although I can't actually find documentation to that effect. If you (Michael or Steve) cannot reproduce this, then I'll try to fix it. But I'm having trouble understanding all the package elisp files. Clue: (packages-split-package-path) doesn't seem to know anything about package-locations. Martin

1 participants
0 comments

Re: XEmacs GIF bug? 25 years, 3 months

SL Baur

P E Jareth Hein <jareth(a)camelot.co.jp> writes in xemacs-beta(a)xemacs.org: >>>>>> "SL" == SL Baur <steve(a)xemacs.org> writes: SL> I get a ton of GIF errors referencing the URL: SL> http://www.sinica.edu.tw/ftms-bin/ftmsw3 SL> (7) (error/warning) Error in process sentinel: SL> (image-conversion-error First image in GIF file is not full SL> size [gif :data GIF87a... > This is an artifact of the way we deal with animated (or multiple > image) files. I agree that putting up an error is rather lame, so > what would you have me do? Just display the first frame floating in > the full frame size, or just clip to the first frame size? How about clipping to the first frame size?

1 participants
0 comments

Re: Customize bug? 25 years, 3 months

Hrvoje Niksic

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > The unbundled code doen't *touch* specifiers, as they are unnecessary > for what it tries to do. It uses the pre-specifier API's together > with `make-frame-hook', which is sufficient. The pre-specifier API internally uses specifiers, only in what one could call a more primitive way. And the bundled code does it the same way. > I suspect most of the current problems is caused by a port of the > code to specifiers, that only got halfway finished. No, the port of the code to specifiers never even got started. I used to have an alpha working version, but I gave up because `background-mode' is unimplementable in the current framework. I agree that most (but not all!) of the current problems were caused by my never-quite-finished merge with XEmacs' faces.el. The unbundled code had, however, other problems; for instance, I recall that you couldn't dump XEmacs with code that used `defface'. > > In FSF Emacs this is trivial since customize exactly matches the > > FSF font model. Adapting customize to more powerful font models > > (whether for XEmacs or for FSF 20.5+) without overly complicating > > the interface will be a challenge. > > There is no XEmacs font model, which is the only hard thing about > it. True. font.el provides some of the needed functionality, but it's way too naive to be taken seriously (no offense Bill!) Not to mention that the redisplay doesn't support merging of font properties. > > I think I know how to fix the MULE problems. (By doing a partial > > port to specifiers. This fixes the > > throw-away-what-I-don't-understand attitude the Customize takes on > > XEmacs). > > On both emacsen. But you can overwrite the customize setting with X > ressources, which only leaves explicit Lisp settings. It depends. I think the *default* customize settings (such as in `defface' forms) should be overridden with X resources. On the other hand, hand-changed customize settings (such as with `M-x customize-face') should override X resources.

3 participants
2 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 March 1999