Re: minibuf.texi question
24 years, 4 months
Jan Vroonhof
Jan Vroonhof
Hrvoje Niksic <hniksic(a)iskon.hr> writes:
> > I think it is a very weird feature for a first time user, however it
> > also very practical, and it doesn't get in the way. Now that we
> > start passing in the default value anyway for the history stuff, it
> > seems to be "cheap" to implement.
>
> Do you think the two features could coexist? I don't see the point of
> our DEFAULT parameter if FSF-style DEFAULT is one M-n away.
Our style default parameter is about putting the default answer in the
history when you just hit RET. That is totally independent of the
cursor-down feature. Otherwise you would have to say "To get your
prompt in the history type M-n before RET". IMHO that requires too
much foresight on the part of the user.
Jan
- 1 participants
- 0 comments
Re: Modules (was: Re: How about a feature freeze)
24 years, 4 months
Didier Verna
Didier Verna
wmperry(a)aventail.com (William M. Perry) wrote:
> And I don't think it does anything cool like use shaped windows, but
> actually queries the root window for information every time you move the
> xterm, etc.
They /have/ to use uncool hacks to achieve the transparency, actually.
X is not designed to allow this easily (it doesn't have alpha layers). For
instance, to make an XTerm really transparent, one would have to reshape the
window around the text each time it is modified. A very reliable way of making
your X server consumne 150% of your CPU ;-)
Anyway, I don't think that people wanting their applications to
explode violently at their eyes are the people we want to attract. At least
not in priority...
--
/ / _ _ 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: Modules (was: Re: How about a feature freeze)
24 years, 4 months
William M. Perry
William M. Perry
Didier Verna <didier(a)epita.fr> writes:
> wmperry(a)aventail.com (William M. Perry) wrote:
>
> > And I don't think it does anything cool like use shaped windows, but
> > actually queries the root window for information every time you move the
> > xterm, etc.
>
> They /have/ to use uncool hacks to achieve the transparency, actually. X
> is not designed to allow this easily (it doesn't have alpha layers). For
> instance, to make an XTerm really transparent, one would have to reshape
> the window around the text each time it is modified. A very reliable way
> of making your X server consumne 150% of your CPU ;-)
Maybe it is just a clever ploy to justify more expensive machines to bosses
(and wives if that isn't redundant :). Hmmm... maybe I should start
running a bunch of transparent xterms telneting to 'chargen' and randomly
moving around the screen. Then I can justify that Quad Xeon machine. :)
> Anyway, I don't think that people wanting their applications to explode
> violently at their eyes are the people we want to attract. At least not
> in priority...
Ye gods no! XEmacs explodes too much in non-visual ways right now. That's
plenty for me. :)
-Bill P.
- 1 participants
- 0 comments
Re: Modules (was: Re: How about a feature freeze)
24 years, 4 months
William M. Perry
William M. Perry
Ben Wing <ben(a)666.com> writes:
> Jan Vroonhof wrote:
>
> > <fatalist>
> > If the purpose is to attract more users, high priority should given to
> > implement transpart background support
>
> explain?
I believe Jan is referring to the growing number of people who want to have
their window manager and applications explode violently at their eyes.
This includes oh-so-useful things like a 'transparent' xterm... the text is
drawn over what would be the desktop background at that position. And I
don't think it does anything cool like use shaped windows, but actually
queries the root window for information every time you move the xterm, etc.
And of course no application is complete until it can do such things. Sort
of like jamies (? or was he just quoting someone else?) assertion that all
programs eventually evolve the ability to read and send email.
-Bill P.
- 1 participants
- 0 comments
Re: minibuf.texi question
24 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
> > If we had DEFAULT implemented, I would also recommend it over
> > INITIAL-CONTENTS. I'm not sure whether we want it implemented.
> > The M-n feature looks very weird to me.
>
> I think it is a very weird feature for a first time user, however it
> also very practical, and it doesn't get in the way. Now that we
> start passing in the default value anyway for the history stuff, it
> seems to be "cheap" to implement.
Do you think the two features could coexist? I don't see the point of
our DEFAULT parameter if FSF-style DEFAULT is one M-n away.
> I haven't read the FSF manual, but I think that INITIAL-CONTENTS vs
> DEFAULT depends on the context. i.e. if you expect that the value
> the user wants is "close" to the 'default', you should use
> INITIAL-CONTENTS.
Yes. I.e. you use INITIAL-CONTENTS when you expect the user to edit
the contents. For instance, M-x w3-fetch provides a good example of
INITIAL-CONTENTS. M-x c-set-style provides a very bad example of
INITIAL-CONTENTS.
- 1 participants
- 0 comments
21.2.24 crash rendering html email in vm
24 years, 4 months
Cotton Seed
Cotton Seed
I start up xemacs on my x86/redhat6.1 box.
M-x vm
There is a new message. It has html content. I hit SPC to display
the message, and after some frenetic elisp loading, xemacs crashes.
gdb and lisp backtraces appended.
The email is not appropriate to be included in the bug report, but I
can probably generate a suitable test case from it if that would help.
- Cotton
bagua$ gdb /usr/xemacs-21.2.24/bin/xemacs
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) r
Starting program: /usr/xemacs-21.2.24/bin/xemacs
Warning: Representation size 4 must match superclass's to override value
Program received signal SIGSEGV, Segmentation fault.
0x40189692 in XTextWidth ()
(gdb) set height 0
(gdb) bt
#0 0x40189692 in XTextWidth ()
#1 0x81a37a3 in MaxLabel (gw=0x8806f70, wid=0xbfffca78, hgt=0xbfffca7a,
w0=0xbfffca7c, w1=0xbfffca7e) at xlwgauge.c:967
#2 0x81a25be in GaugeResize (w=0x8806f70) at xlwgauge.c:327
#3 0x40028487 in Initialize ()
#4 0x40115405 in CallInitialize ()
#5 0x401153cd in CallInitialize ()
#6 0x40115913 in xtCreate ()
#7 0x40115dd1 in _XtCreateWidget ()
#8 0x40115ed1 in XtCreateManagedWidget ()
#9 0x819cf41 in xaw_create_progress (instance=0x8819568) at lwlib-Xaw.c:808
#10 0x819b4e8 in instantiate_widget_instance (instance=0x8819568)
at lwlib.c:879
#11 0x819b5c4 in lw_make_widget (id=65546, parent=0x8834360, pop_up_p=0 '\000')
at lwlib.c:358
#12 0x819be6e in lw_create_widget (type=0x81fb099 "progress",
name=0x84e2ed0 "Progress", id=65546, val=0x84e5290, parent=0x8834360,
pop_up_p=0 '\000', pre_activate_cb=0,
selection_cb=0x80a40a0 <popup_selection_callback>, post_activate_cb=0)
at lwlib.c:931
#13 0x817df5c in x_widget_instantiate (image_instance=142819960,
instantiator=138317408, pointer_fg=136641908, pointer_bg=136641908,
dest_mask=239, domain=139330640, type=0x81fb099 "progress", wv=0x84e5290)
at glyphs-x.c:2447
#14 0x817fe57 in x_progress_gauge_instantiate (image_instance=142819960,
instantiator=138317408, pointer_fg=136641908, pointer_bg=136641908,
dest_mask=239, domain=139330640) at glyphs-x.c:2588
#15 0x80edfbe in instantiate_image_instantiator (device=138714616,
domain=139330640, instantiator=138317408, pointer_fg=136641908,
pointer_bg=136641908, dest_mask=239) at glyphs.c:605
#16 0x80f20f5 in image_instantiate (specifier=138317128, matchspec=136384940,
domain=139330640, instantiator=138317408, depth=3) at glyphs.c:2566
#17 0x8087d62 in call_with_suspended_errors (
fun=0x80f1bd8 <image_instantiate>, retval=136384940, class=136762956,
errb={
really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, nargs=5) at eval.c:2126
#18 0x815a880 in specifier_instance_from_inst_list (specifier=138317128,
matchspec=136384940, domain=139330640, inst_list=138231488, errb={
really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, no_quit=0, depth=3) at specifier.c:2444
#19 0x815ac2f in specifier_instance (specifier=138317128, matchspec=136384940,
domain=139330640, errb={
really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666}, no_quit=0, no_fallback=0, depth=1) at specifier.c:2559
#20 0x815c2a5 in Fspecifier_instance (specifier=138317128, domain=136641908,
default_=136641908, no_fallback=136641908) at specifier.c:2649
#21 0x8089cce in Ffuncall (nargs=5, args=0xbfffd5ec) at eval.c:3178
#22 0x8060a09 in execute_optimized_program (
program=0x850f238 "À\t!¬\006ÂÀ\t\"\021\t\013N\034Å\f!«\013Æ\f\016\a\016\b\016\t$\024\f)\207", stack_depth=5, constants_data=0x82f4e80) at bytecode.c:743
#23 0x80605ee in funcall_compiled_function (fun=137306320, nargs=5,
args=0xbfffd6fc) at bytecode.c:519
#24 0x8089e04 in Ffuncall (nargs=6, args=0xbfffd6f8) at eval.c:3210
#25 0x8060a09 in execute_optimized_program (
program=0x850f218 "À\tÂ\013\f\r%\207\234\2335\b9", stack_depth=6,
constants_data=0x82fed40) at bytecode.c:743
#26 0x80605ee in funcall_compiled_function (fun=137306488, nargs=1,
args=0xbfffd810) at bytecode.c:519
#27 0x8089e04 in Ffuncall (nargs=2, args=0xbfffd80c) at eval.c:3210
#28 0x8060a09 in execute_optimized_program (program=0x8833e58 "\bÁk?\205¡",
stack_depth=6, constants_data=0x83e9a68) at bytecode.c:743
#29 0x80605ee in funcall_compiled_function (fun=138202824, nargs=3,
args=0xbfffd91c) at bytecode.c:519
#30 0x8089e04 in Ffuncall (nargs=4, args=0xbfffd918) at eval.c:3210
#31 0x8060a09 in execute_optimized_program (
program=0x8833de0 "\b¬\004Á \020\n＠\211\eA\034\r\013＠a«.\013\016\006¡\210\f\016\006a«\rÇÈ\016\t!Ê\016\013#\210ª\tÌ\016\006\016\013\b#\210Í \210Î «\027ÏÐ !\210ª\020\r\016\006B\nB\022Ì\016\006\016\013\b#\210\016\013Ña\tÒÓÔ\"\210Õ\r!*\207iiiiiiÁ", stack_depth=5, constants_data=0x83e9938) at bytecode.c:743
#32 0x80605ee in funcall_compiled_function (fun=138202768, nargs=4,
args=0xbfffda28) at bytecode.c:519
#33 0x8089e04 in Ffuncall (nargs=5, args=0xbfffda24) at eval.c:3210
#34 0x8060a09 in execute_optimized_program (
program=0x87c56a8 "À\t\nÃ#\210\fÅa«\bÆ\t\016\a\n#\207È\t\016\a\f\n$\207",
stack_depth=5, constants_data=0x83e9b38) at bytecode.c:743
#35 0x80605ee in funcall_compiled_function (fun=138202852, nargs=3,
args=0xbfffdb34) at bytecode.c:519
#36 0x8089e04 in Ffuncall (nargs=4, args=0xbfffdb30) at eval.c:3210
#37 0x8060a09 in execute_optimized_program (
program=0x883b048 "\b¬\n\t¬\aÂÃÂ!\210\207ÄÅ\b\t#\036\006ÇÈ\016\006\016\t#\210\016\006)\207", stack_depth=4, constants_data=0x83e9b70) at bytecode.c:743
#38 0x80605ee in funcall_compiled_function (fun=138202936, nargs=1,
args=0xbfffdc3c) at bytecode.c:519
#39 0x8089e04 in Ffuncall (nargs=4, args=0xbfffdc38) at eval.c:3210
#40 0x8060a09 in execute_optimized_program (
program=0x8839380 "\b¬\004Á \210\n®\002\013q\210p\022Ä \035Æ\016\a!\210Èp!\210~\210db\210Éc\210eb\210Ê\026\013ÌÍ!\210eb\210\016\016ÏV«\b\016\016\016\020_ª\003\016\020\036\020e\036\021Ï\036\022\016\023\aÔÕdeZ\"\036\026×Ø!«\004ت\002ÙÚ!\036\ep\036\034e\036\035Þ\036\037Þ\036 Þ\036!Þ\036\"Þ\036#Þ\036$Þ\036%æçèN®\réêç\036+ì\016+!\226)\"!\036-æîèN®\réêî\036+ì\016+!\226)\"!C\036/Þ\0360Ê\0361Þ\0362Þ\0363Þ\0364Þ\0365Þ\0366Þ\0367Þ\0368Þ\0369Þ\036:Þ\036"..., stack_depth=17,
constants_data=0x854d0c0) at bytecode.c:743
#41 0x80605ee in funcall_compiled_function (fun=142093484, nargs=1,
args=0xbfffdd78) at bytecode.c:519
#42 0x8089e04 in Ffuncall (nargs=2, args=0xbfffdd74) at eval.c:3210
#43 0x8060a09 in execute_optimized_program (
program=0xbfffddc8 "\212ÀÁ!q\210 \210\013c\210Äp!\025)\016\006\016\a}\210ed|\210È\r!\210É\211\211\036\n\036\013\036\f\016\r«\"\016\r＠\026\n\016\rA\026\rÎ\016\nÏ\"\026\fÐ\016\f\016\021\"£\026\013ÉÒÓ\217\210ªÜ+\016\024«\025\016\024ÕH«\017Ö`×\"\210Ø\016\024ÕH!\210ª\004eb\210\016\031¬\nÚ Ûa¬\004Ü \210ÝÞ!\210~\207\230® \b,L&\b\200Þÿ¿\017\t\026\b,L&\b\230® \btý$\b,L&\bÌ\001k\b2", stack_depth=3,
constants_data=0x874fb08) at bytecode.c:743
#44 0x806364a in Fbyte_code (instructions=141930644, constants=141884152,
stack_depth=7) at bytecode.c:2400
#45 0x808923b in Feval (form=141787520) at eval.c:2975
#46 0x808e61b in Fprogn (args=141787796) at eval.c:767
#47 0x80614c3 in execute_rare_opcode (stack_ptr=0xbfffe03c,
program_ptr=0x87200c2 "+\207i", opcode=Bsave_window_excursion)
at bytecode.c:1236
#48 0x80607cb in execute_optimized_program (
program=0x87200b0 "\b¬\004Á \210\n\013{\034Å\036\006Ç\036\bÉ\213+\207i",
stack_depth=2, constants_data=0x874fb98) at bytecode.c:653
#49 0x80605ee in funcall_compiled_function (fun=141803092, nargs=2,
args=0xbfffe140) at bytecode.c:519
#50 0x8089e04 in Ffuncall (nargs=3, args=0xbfffe13c) at eval.c:3210
#51 0x8060a09 in execute_optimized_program (
program=0xbfffe194 "À`À\211\031\032\e\034ÅÆ!\210\016\a«B\016\b\036\tÊ\216ËÀ!\210Ì\016\r!\210`\022Á \021Î\016\r\013\n#\210\nÁ \tZ\\\022Á \021Ï\013\n\"\210\nÁ \tZ\\\022Ð\036\021Ò\013\nÓ#\210)\nb\210*ª5Ì\016\r!\210`\022Á \021Î\016\r\013\n#\210\nÁ \tZ\\\022Á \021Ï\013\n\"\210\nÁ \tZ\\\022Ð\036\021Ò\013\nÓ#\210)\nb\210ÅÔ!\210,Ð\207,", stack_depth=4, constants_data=0x84de050) at bytecode.c:743
#52 0x806364a in Fbyte_code (instructions=140892852, constants=139321408,
stack_depth=9) at bytecode.c:2400
#53 0x808923b in Feval (form=139838912) at eval.c:2975
#54 0x80871cd in condition_case_3 (bodyform=139838912, var=137762212,
handlers=140197588) at eval.c:1630
#55 0x8061553 in execute_rare_opcode (stack_ptr=0xbfffe518,
program_ptr=0x8509559 "\207Å\016\006Ç\"\210È\207", opcode=Bcondition_case)
at bytecode.c:1268
#56 0x80607cb in execute_optimized_program (
program=0x8509550 "ÀÁ!«\006ÂÃÄ\217\207Å\016\006Ç\"\210È\207",
stack_depth=3, constants_data=0x84de0e8) at bytecode.c:653
#57 0x80605ee in funcall_compiled_function (fun=139746280, nargs=1,
args=0xbfffe618) at bytecode.c:519
#58 0x8089e04 in Ffuncall (nargs=2, args=0xbfffe614) at eval.c:3210
#59 0x8060a09 in execute_optimized_program (
program=0xbfffe668 "ÀÁ\nP!\013!\207Œ", stack_depth=3,
constants_data=0x84ddea0) at bytecode.c:743
#60 0x806364a in Fbyte_code (instructions=140898340, constants=139320976,
stack_depth=7) at bytecode.c:2400
#61 0x808923b in Feval (form=140233652) at eval.c:2975
#62 0x80871cd in condition_case_3 (bodyform=140233652, var=136641908,
handlers=140222372) at eval.c:1630
#63 0x8061553 in execute_rare_opcode (stack_ptr=0xbfffe8e4,
program_ptr=0x86ee3a1 "¬TÁåæ\217¬NÒç\r\"«\016Áèé\217¬Bê\016\n!\210ª;ë\r!«\022ì\016\n!«\f\n«-í\nîÁ#\210ª%ï\r!«\nðñ\016\n!!\210ª\027\n«\fò\nó\016\n!®\002ô\"\210õ\n®\003\016\n!\210\n«\005ö\n!\210.\a÷\207", opcode=Bcondition_case)
at bytecode.c:1268
#64 0x80607cb in execute_optimized_program (
program=0x86ee308 "À Á\211\211\211\211\032\e\034\035\036\006\036\aÈ\216É\016\n!¬\017\016\n\022Ë\nÌ\"\026\nÍ\n!b\210Î\016\n!＠\227\025Ï\rÐ\"＠\023\016\021«DÒÓ\r\"«>Ô\016\nÕ\"®\006Ö\016\n×\"\211\026\006«-Ø\016\006!\211\024«%Ò\r\f\"¬\037Ù\016\n\fC\"\210Ú\016\nÛ\fÛQC\"\210Î\016\n!＠\227\025Ï\rÐ\"＠\023Ü\016\n\016\035\"«\rÁÞß\217¬hÁàá\217¬bâ\016\n\016\035\"«\rÁãä\217¬TÁåæ\217¬NÒç\r\"«\016Áèé\217¬Bê\016\n!\210ª;ë\r!«\022ì\016\n!«\f\n«-í\nîÁ#\210"..., stack_depth=6,
constants_data=0x84ddf18) at bytecode.c:653
#65 0x80605ee in funcall_compiled_function (fun=139746196, nargs=1,
args=0xbfffe9f0) at bytecode.c:519
#66 0x8089e04 in Ffuncall (nargs=2, args=0xbfffe9ec) at eval.c:3210
#67 0x8060a09 in execute_optimized_program (
program=0x86ee4a0 "À\031\nÃ=«FÀ\211\211\211\034\035\e\036\006Ç\016\b!\025É\r!\237\025\r«$\016\006¬ Ê\r＠!＠\024Ë\r＠!¬\006Ì\f!«\t\r＠\023Í\026\006ªá\rA\211\025¬Þ\013®\006Ç\016\b!＠\021,ª_\nÎ=«ZÀ\211\211\211\211\034\035\036\017\e\036\006Ç\016\b!\025É\r!\237\211\025«3\016\006¬/Ê\r＠!＠\024Ë\r＠!«\020Ð\r＠À\"«\t\r＠\023Í\026\006ª\016\016\017¬\nÌ\f!«\005\r＠\026\017\rA\211\025¬Ï\013®\n\016\017®\006Ç\016\b!＠\021-Ñ\t!)\207", stack_depth=6, constants_data=0x84de518) at bytecode.c:743
#68 0x80605ee in funcall_compiled_function (fun=139746644, nargs=1,
args=0xbfffeb00) at bytecode.c:519
#69 0x8089e04 in Ffuncall (nargs=2, args=0xbfffeafc) at eval.c:3210
#70 0x8060a09 in execute_optimized_program (
program=0xbfffeb50 "ÀÁ\nP!\013!\207\036<1＠Ža:＠\200E:＠\004ìÿ¿ì4\006\btý$\b", stack_depth=3, constants_data=0x84ddea0) at bytecode.c:743
#71 0x806364a in Fbyte_code (instructions=140898340, constants=139320976,
stack_depth=7) at bytecode.c:2400
#72 0x808923b in Feval (form=140233652) at eval.c:2975
#73 0x80871cd in condition_case_3 (bodyform=140233652, var=136641908,
handlers=140222372) at eval.c:1630
#74 0x8061553 in execute_rare_opcode (stack_ptr=0xbfffedcc,
program_ptr=0x86ee3a1 "¬TÁåæ\217¬NÒç\r\"«\016Áèé\217¬Bê\016\n!\210ª;ë\r!«\022ì\016\n!«\f\n«-í\nîÁ#\210ª%ï\r!«\nðñ\016\n!!\210ª\027\n«\fò\nó\016\n!®\002ô\"\210õ\n®\003\016\n!\210\n«\005ö\n!\210.\a÷\207", opcode=Bcondition_case)
at bytecode.c:1268
#75 0x80607cb in execute_optimized_program (
program=0x86ee308 "À Á\211\211\211\211\032\e\034\035\036\006\036\aÈ\216É\016\n!¬\017\016\n\022Ë\nÌ\"\026\nÍ\n!b\210Î\016\n!＠\227\025Ï\rÐ\"＠\023\016\021«DÒÓ\r\"«>Ô\016\nÕ\"®\006Ö\016\n×\"\211\026\006«-Ø\016\006!\211\024«%Ò\r\f\"¬\037Ù\016\n\fC\"\210Ú\016\nÛ\fÛQC\"\210Î\016\n!＠\227\025Ï\rÐ\"＠\023Ü\016\n\016\035\"«\rÁÞß\217¬hÁàá\217¬bâ\016\n\016\035\"«\rÁãä\217¬TÁåæ\217¬NÒç\r\"«\016Áèé\217¬Bê\016\n!\210ª;ë\r!«\022ì\016\n!«\f\n«-í\nîÁ#\210"..., stack_depth=6,
constants_data=0x84ddf18) at bytecode.c:653
#76 0x80605ee in funcall_compiled_function (fun=139746196, nargs=1,
args=0xbfffeed8) at bytecode.c:519
#77 0x8089e04 in Ffuncall (nargs=2, args=0xbfffeed4) at eval.c:3210
#78 0x8060a09 in execute_optimized_program (
program=0x86ee1b0 "À \210\t«\016Â\t!¬\006ÃÄ!«\004\tq\210Å \210Æ \210Ç \210\016\b¬\t\016\t¬\005ÃÊ!\210\016\t«\022Ë\016\f＠!\210\016\rq\210\016\t \210\202",
stack_depth=6, constants_data=0x84ddd38) at bytecode.c:743
#79 0x80605ee in funcall_compiled_function (fun=139746168, nargs=0,
args=0xbfffef78) at bytecode.c:519
#80 0x8089560 in Feval (form=140492232) at eval.c:3034
#81 0x80871cd in condition_case_3 (bodyform=140492232, var=136759516,
handlers=140889420) at eval.c:1630
#82 0x8061553 in execute_rare_opcode (stack_ptr=0xbffff1ac,
program_ptr=0x86ee0df "\210Ê\016\013!«:Å\016\006＠!«3\016\006＠ÌHÍHÎ\016\006＠!ZÏV\211\036\020«\005ÑÒ!\210Ë\016\013Î\016\006＠!\016\006＠ÌHÍH#\210\016\020«\005ÑÓ!\210)p\036\024Õ\216\212\212eb\210~\210`\016\006＠ÌHÍH}\210)\016\026«\016×\016\030!«\005ÙÚ!\210Û \210)Üp!«F\212Ý\026\036\n«\aß\nÞÝ#\210\n«\016à\n!¬\006áâ!«\004\nq\210\016\006＠ãHÌH«\bä\016\006＠å\"\210\016\006＠ãHÚH«\bæ\016\006＠å\"\210)ç \210è ª\003ç *\207", opcode=Bcondition_case) at bytecode.c:1268
#83 0x80607cb in execute_optimized_program (
program=0x86ee0c0 "\b«\036\t«\e\n«\bÃ\nÄ\"?ª\003\f?«\rÅ\016\006＠!¬\006ÇÈÉ\217\210Ê\016\013!«:Å\016\006＠!«3\016\006＠ÌHÍHÎ\016\006＠!ZÏV\211\036\020«\005ÑÒ!\210Ë\016\013Î\016\006＠!\016\006＠ÌHÍH#\210\016\020«\005ÑÓ!\210)p\036\024Õ\216\212\212eb\210~\210`\016\006＠ÌHÍH}\210)\016\026«\016×\016\030!«\005ÙÚ!\210Û \210)Üp!«F\212Ý\026\036\n«\aß\nÞÝ#\210\n«\016à\n!¬\006áâ!«\004\nq\210\016\006＠ãHÌH«\bä\016\006＠å\"\210\016\006＠ãHÚH«\bæ\016\006＠å"..., stack_depth=6,
constants_data=0x86a2b28) at bytecode.c:653
#84 0x80605ee in funcall_compiled_function (fun=141162236, nargs=0,
args=0xbffff2b8) at bytecode.c:519
#85 0x8089e04 in Ffuncall (nargs=1, args=0xbffff2b4) at eval.c:3210
#86 0x8060a09 in execute_optimized_program (
program=0x8509650 "À Á\211\032\e\034\r«\016Æ\r!¬\006ÇÈ!«\004\rq\210É \210Ê \210Ë \210\016\f\026\016\r?\021Î\016\017＠!?\t\016\020\005\016\021Ò=\023\016\023«\005\016\023q\210`Ôp!\036\025\036\026\016\025«\t×Ø\016\025!!¬ ÙpÚÛ\016\034ÝD$\210Ôp!\026\025Þ\016\025!dU«\aß\016\025e\"\210Ú\022*\f¬\025\n¬\022\013¬\017\016\021Ò=«SàdÔp!\"«K\n¬9Ôp!Á\036!\036\025Þ\016\025!\026!\212âã\016\025!!\210)äã\016\025!!\210ÙÁ\211å\016\034ÝD$\210Ôp!\211\026\025«\bß\016\025\016!\"\210*"...,
stack_depth=9, constants_data=0x869f1a0) at bytecode.c:743
#87 0x80605ee in funcall_compiled_function (fun=139729436, nargs=1,
args=0xbffff3d8) at bytecode.c:519
#88 0x8089e04 in Ffuncall (nargs=2, args=0xbffff3d4) at eval.c:3210
#89 0x8065e3c in Fcall_interactively (function=139855708,
record_flag=136641908, keys=136641908) at callint.c:946
#90 0x80884e2 in Fcommand_execute (cmd=139855708, record=136641908,
keys=136641908) at eval.c:2613
#91 0x80ba542 in execute_command_event (command_builder=0x84748a8,
event=139317360) at event-stream.c:4333
#92 0x80bb19b in Fdispatch_event (event=139317360) at event-stream.c:4692
#93 0x806ad3b in Fcommand_loop_1 () at cmdloop.c:575
#94 0x806af6d in command_loop_1 (dummy=136641908) at cmdloop.c:490
#95 0x808e33c in condition_case_1 (handlers=136642004,
bfun=0x806af28 <command_loop_1>, barg=136641908,
hfun=0x806a130 <cmd_error>, harg=136641908) at eval.c:1630
#96 0x806b04c in command_loop_2 (dummy=136641908) at cmdloop.c:252
#97 0x808e21f in internal_catch (tag=136715860,
func=0x806b014 <command_loop_2>, arg=136641908, threw=0x0) at eval.c:1305
#98 0x806a564 in initial_command_loop (load_me=136641908) at cmdloop.c:301
#99 0x8083062 in xemacs_21_2_b24_i686_pc_linux () at emacs.c:1898
#100 0x8084bdf in main () at emacs.c:2323
#101 0x402d3cb3 in __libc_start_main (main=0x8084ae0 <main>, argc=1,
argv=0xbffff914, init=0x804dba8 <_init>, fini=0x81abf94 <_fini>,
rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff90c)
at ../sysdeps/generic/libc-start.c:78
(gdb) c
Continuing.
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
If you have access to the PROBLEMS file that came with your
version of XEmacs, please check to see if your crash is described
there, as there may be a workaround available.
Otherwise, please report this bug by running the send-pr
script included with XEmacs, or selecting `Send Bug Report'
from the help menu.
As a last resort send ordinary email to `crashes(a)xemacs.org'.
*MAKE SURE* to include the information in the command
M-x describe-installation.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started the editor, or maybe in your home
directory), and type
gdb /usr/xemacs-21.2.24/bin/xemacs core
then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB. A similar procedure should work for all of
these. Ask your system administrator if you need more help.)
Lisp backtrace follows:
# (unwind-protect ...)
specifier-instance(#<image-specifier global=((... . ...) (... . ...) (... . ...)) fallback=((nil . ...)) 0x168e> nil nil nil)
# bind (value no-fallback default domain property glyph)
glyph-property-instance(#<glyph (buffer) #<image-specifier global=(... ... ...) fallback=(...) 0x168e>0x168d> image nil nil nil)
# bind (no-fallback default domain glyph)
glyph-image-instance(#<glyph (buffer) #<image-specifier global=(... ... ...) fallback=(...) 0x168e>0x168d>)
# bind (inhibit-read-only zmacs-region-stays val frame value message)
raw-append-progress("Parsing 1k" 59 #<x-frame "emacs" 0x1eb3>)
# bind (tmsg top frame value message label)
append-progress(progress "Parsing 1k" 59 nil)
# bind (frame value message label)
display-progress(progress "Parsing 1k" 59)
# bind (str args value fmt)
progress("Parsing %s" 59 "1k")
# bind (w3-p-s-btdt w3-p-s-baseobject w3-p-s-except w3-p-s-content-model w3-p-s-tran-list w3-p-s-transition w3-p-s-state-transitions w3-p-s-includep w3-p-s-end-tag w3-p-s-content w3-p-s-var w3-p-s-undo-list w3-p-s-overrides w3-p-s-num w3-p-s-pos w3-p-s-entity open-list content content-model attr-value attr-name ref w3-p-d-exceptions w3-p-d-shortref-chars w3-p-d-shortrefs w3-p-d-in-parsed-marked-section w3-p-d-null-end-tag-enabled w3-p-d-non-markup-chars w3-p-d-debug-url marked-section-undo-stack w3-p-d-open-element-stack w3-p-d-current-element tag-end attribute-value-end tag-attributes net-tag-p w3-p-d-end-tag-p w3-p-d-tag-name between-tags-end between-tags-start parse-buffer one-hundred status-message-format loop-count last-loop-start gc-cons-threshold old-syntax-table buff)
w3-parse-buffer(#<buffer " *w3-region*">)
# (unwind-protect ...)
byte-code("..." [get-buffer-create " *w3-region*" erase-buffer source w3-parse-buffer parse st nd w3-draw-tree nil widget glyph url w3-image-widgets-waiting widget-get :src assoc w3-graphics-list (widget-value-set widget glyph) ((error)) url-current-object 6 push-mark t w3-find-specific-link w3-running-xemacs device-type tty w3-fixup-eol-faces message "Drawing... done"] 3)
# (unwind-protect ...)
# bind (parse w3-display-same-buffer source nd st)
w3-region(2442 3970)
# bind (buffer-read-only start end buffer-size)
byte-code("..." [nil buffer-size end start buffer-read-only message "Inlining text/html, be patient..." vm-fsfemacs-mule-p enable-multibyte-characters xzx ((set-buffer-multibyte xzx)) set-buffer-multibyte vm-mime-insert-mime-body layout vm-mime-transfer-decode-region w3-region t inhibit-read-only remove-text-properties (read-only nil) "Inlining text/html... done"] 4)
!\"\"Æ" ... 6))))e ... . ((error (byte-code "À ÂÃÄ
# bind (layout)
vm-mime-display-internal-text/html([("text/html" "charset=Windows-1252") ("text/html" "charset=\"Windows-1252\"") "quoted-printable" nil nil nil nil #<marker at 970225 in inbox 0x86a8ccc> #<marker at 970319 in inbox 0x86a8ce4> #<marker at 971915 in inbox 0x86a8cfc> nil nil <<m>> nil])
byte-code("..." [intern "vm-mime-display-internal-" type layout] 3)
# (condition-case ... . ((void-function)))
# (unwind-protect ...)
# bind (modified file type type2 type-no-subtype extent dont-honor-c-d layout)
vm-decode-mime-layout([("text/html" "charset=Windows-1252") ("text/html" "charset=\"Windows-1252\"") "quoted-printable" nil nil nil nil #<marker at 970225 in inbox 0x86a8ccc> #<marker at 970319 in inbox 0x86a8ce4> #<marker at 971915 in inbox 0x86a8cfc> nil nil <<m>> nil])
# bind (best-layout layout)
vm-mime-display-internal-multipart/alternative([("multipart/alternative" "boundary=----=_NextPart_000_1F00_01BF4AF6.AB945AE0") ("multipart/alternative" "boundary=\"----=_NextPart_000_1F00_01BF4AF6.AB945AE0\"") "7bit" nil nil nil nil #<marker at 966768 in inbox 0x86a8d14> #<marker at 969154 in inbox 0x86a8d2c> #<marker at 971963 in inbox 0x86a8d44> ([... ... "quoted-printable" nil nil nil nil #<marker at 969244 in inbox 0x86a775c> #<marker at 969339 in inbox 0x86a7774> #<marker at 970180 in inbox 0x86a778c> nil nil <<m>> nil] [... ... "quoted-printable" nil nil nil nil #<marker at 970225 in inbox 0x86a8ccc> #<marker at 970319 in inbox 0x86a8ce4> #<marker at 971915 in inbox 0x86a8cfc> nil nil <<m>> nil]) nil <<m>> nil])
byte-code("..." [intern "vm-mime-display-internal-" type layout] 3)
# (condition-case ... . ((void-function)))
# (unwind-protect ...)
# bind (modified file type type2 type-no-subtype extent dont-honor-c-d layout)
vm-decode-mime-layout([("multipart/alternative" "boundary=----=_NextPart_000_1F00_01BF4AF6.AB945AE0") ("multipart/alternative" "boundary=\"----=_NextPart_000_1F00_01BF4AF6.AB945AE0\"") "7bit" nil nil nil nil #<marker at 966768 in inbox 0x86a8d14> #<marker at 969154 in inbox 0x86a8d2c> #<marker at 971963 in inbox 0x86a8d44> ([... ... "quoted-printable" nil nil nil nil #<marker at 969244 in inbox 0x86a775c> #<marker at 969339 in inbox 0x86a7774> #<marker at 970180 in inbox 0x86a778c> nil nil <<m>> nil] [... ... "quoted-printable" nil nil nil nil #<marker at 970225 in inbox 0x86a8ccc> #<marker at 970319 in inbox 0x86a8ce4> #<marker at 971915 in inbox 0x86a8cfc> nil nil <<m>> nil]) nil <<m>> nil])
# (unwind-protect ...)
# (unwind-protect ...)
# bind (buffer-read-only modified)
# (unwind-protect ...)
# bind (vm-sr-clip vm-sr-min vm-sr-max layout m)
vm-decode-mime-message()
# (condition-case ... . ((vm-mime-error (byte-code ＠ÁHÂ
A＠IÄÅ
A＠\"" ... 3))))
vm-show-current-message()
# bind (mp-changed needs-decoding was-invisible arg)
vm-scroll-forward(nil)
# bind (command-debug-status)
call-interactively(vm-scroll-forward)
# (condition-case ... . error)
# (catch top-level ...)
Program received signal SIGSEGV, Segmentation fault.
0x402da111 in __kill ()
- 3 participants
- 2 comments
Re: minibuf.texi question
24 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes:
> 1. At read-from-minibuffer documentation, FSF manual says:
> *Usage note:* The INITIAL-CONTENTS argument and the DEFAULT
> argument are two alternative features for more or less the same
> job. It does not make sense to use both features in a single call
> to `read-from-minibuffer'. In general, we recommend using
> DEFAULT, since this permits the user to insert the default value
> when it is wanted, but does not burden the user with deleting it
> from the minibuffer on other occasions.
>
> FSF recommends DEFAULT over INITIAL-CONTENTS. Is that so in XEmacs
> too?
XEmacs does not support DEFAULT. FSF's DEFAULT causes M-n to insert
the default contents, making it look like it's a first item in the
"future" of the history list. It does not affect what happens when
you just press RET.
The DEFAULT argument you added does something different -- it affects
what happens when you just press RET, and it stores the correct thing
to history. It works nicely with the traditional "Insert something
(default foo): " Emacs prompts. FSF's DEFAULT has the advantage that
you can edit the default, and change it.
If we had DEFAULT implemented, I would also recommend it over
INITIAL-CONTENTS. I'm not sure whether we want it implemented. The
M-n feature looks very weird to me.
What do /you/ think?
As a side note, maybe we should call our DEFAULT argument differently,
to avoid horrible confusion with FSF's DEFAULT.
> 2. FSF minibuf.texi includes doc about read-passwd.
> However, that file is in xemacs-base package. Where should
> I document them?
Feel free to document it in minibuf.texi. read-passwd is in
xemacs-base. XEmacs is not really meant to be used without
xemacs-base.
> 3. read-string, read-command and read-variable doesn't have
> DEFAULT argument while FSF version has. Is that intentional or just
> because no one has requested? I'd prefer having DEFAULT argument to
> have better history support.
I don't think it's intentional. But please beware adding DEFAULT
arguments because of the different user interface from the FSF. Be
very careful of what you're doing here. If we make a wrong step, we
could regret it later.
- 1 participants
- 0 comments
Re: check process state before accessing coding_stream (fix PR#1061)
24 years, 4 months
Jan Vroonhof
Jan Vroonhof
Ben Wing <ben(a)666.com> writes:
> Your arguments do not prove that it's *hard* to do correctly, but just that it's time
> consuming.
No. I'm saying that you can never assume you will get a complete
translation of something like XEmacs and thus you will have to design
in something to cope with that. And that is a hard problem. I'm not
even sure a practical solution is known.
I'm not making these problems up, I see them all around here.
Luckily our Unix systems are not localized.
> Also, it's certainly not a reason not to do it at all.
It might be a reason to give it more thought before going out to do
it. Of course it might be that for some languages it worth having a
partial solution now (worse is better and all that). Presumably you
would be able to reuse most of the strings in any real solution.
Jan
- 1 participants
- 0 comments
Re: Modules (was: Re: How about a feature freeze)
24 years, 4 months
Jan Vroonhof
Jan Vroonhof
Ben Wing <ben(a)666.com> writes:
> But how *useful* are these things?
Potentially very useful, however if there isn't some use made of them
now that the basics work they will stay in this half useful half not
limbo like for instance the external widget support.
You want to get them into to a state where everybody and his dog can
use them and IMHO the best phase to do that is when the feature is
still new.
> In particular, are they more important
> than badly-needed fixes to the installation/documentation/UI?
No, but I think they are more or less orthogonal. I am all for
make concentrated push on the essentials, but you cannot simply trade
projects for another when the only time available is volunteer time.
Even though I know one of the most useful contributions right now
XEmacs would be to work a complete weekend with the FSF and XEmacs
User manuals in an Ediff session, I still want to worry why using
an XEmacs's external window in an XEmacs subwindow doesn't work.
<fatalist>
If the purpose is to attract more users, high priority should given to
implement transpart background support
</fatalist>
Jan
- 2 participants
- 1 comments
Re: check process state before accessing coding_stream (fix PR#1061)
24 years, 4 months
Jan Vroonhof
Jan Vroonhof
Ben Wing <ben(a)666.com> writes:
<preeve type="pet">
> Implementing message translation is not that hard.
No, it is in fact very hard to do correctly. The problem is what do
when a software (system) is only partially localized.
(y-or-n-p "Möchten Sie alle Daten nicht Löschen?")
Möchten Sie alle Daten nicht Löschen?(y or n) j
Please answer y or n. Möchten Sie alle Daten nicht Löschen?(y or n)
So we localize y-or-n-p. However then the user installs some software
that is in English only.
(yes-or-no-p "Are you sure you are sure?")
Are you sure you are sure? (ja oder nein) yes
Bitte antworten Sie mit "ja" oder "nein". Are you sure you are sure? (ja oder nein)
And if you think that these confusions are just harmless then please
aware that in Greek "ne" means yes! (In Dutch "nee" means no and is
pronounced the about same as the Greek word, so this kind of confusion
also exists in the real word).
I thought the main lesson we have learned from the past is that it
easy to think i18n, l10m, m17m, w13n is easy[1], but it isn't.
</peeve>
Jan
Footnotes:
[1] Why is y2k a problem, but c2y and p3e are not?
- 2 participants
- 1 comments