January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> Mike Fabian <mike.fabian(a)gmx.de> writes: >> > Or, couldn't XEmacs do the charade *once*, and then cache the >> > results. >> >> I think it does. When I first use info-mode in an XEmacs session, I >> have to wait a few seconds while XEmacs creates the info Top-node, but >> it does that only once. Hrvoje> 1) I meant: cache between two invocations of XEmacs. But if you want to do this, the dir files are, by design, *exactly* the place for such a cache. If you introduce another cache level, you now have 2 possible levels of inconsistency. Bad juju. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Minor before/after-change cleanup 24 years, 4 months

Norbert Koch

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > This patch cleans up some code in insdel.c and extents.c related to > reporting before and after change functions. It does not fix the > infamous modified-buffer-in-change-functions bug mentioned before. > The fix for that should come in later, if things are right. I've > separated this patch because it should be independent of the other, > and to make review easier. Hi Hrvoje! If this (too) is meant to fix the bug reported by me (wrt w3) then sorry not yet. I've seen the page, but only while the core has been dumped to the disk ;-( Do we have sort of a "off by one error"? norbert. The backtracre reads: (gdb) bt #0 0x28467c78 in kill () from /usr/lib/libc.so.3 #1 0x8084519 in fatal_error_signal (sig=6) at emacs.c:278 #2 0xbfbfdfdc in ?? () #3 0x808447b in assert_failed (file=0x81dd9a2 "insdel.c", line=1117, expr=0x81dd45d "BUFFER_LIVE_P (buf)") at emacs.c:2828 Here, the ASSERT fails, because the Bufpos are set to zero, therefore - im running without Mule - IIRC also Bytind. The test against buffer start, which expands to (Byteind) 1, thus fails. #4 0x810c6af in bufpos_to_bytind (buf=0x82f8400, x=0) at insdel.c:1117 #5 0x80c9433 in report_extent_modification (buffer=137331712, start=0, end=0, afterp=1) at extents.c:2272 signal_after_change changes start and end to 0, since all buffer variables have this value (haven't been changed, yet?). #6 0x8109b83 in signal_after_change (buf=0x82f8400, start=0, orig_end=2909, new_end=0) at insdel.c:2320 #7 0x810a9f9 in buffer_insert_string_1 (buf=0x82f8400, pos=2909, nonreloc=0xbfbfd0f4 ">\n", reloc=136603652, offset=0, length=2, flags=0) at insdel.c:2594 What strikes me odd is, that the variable pos changed its value from -1 to 2909 between these two calls (an optimisation issue?). #8 0x810cee3 in buffer_insert_raw_string_1 (buf=0x82f8400, pos=-1, nonreloc=0xbfbfd0f4 ">\n", length=2, flags=0) at insdel.c:2614 #9 0x812a951 in read_process_output (proc=145660416) at process.c:915

1 participants
0 comments

Re: 21.2 Out of sync: window-minibuffer-p arg is optional in Emacs 24 years, 4 months

Jari Aalto+mail.emacs

* 2000-01-08 Hrvoje Niksic <hniksic(a)iskon.hr> list.xemacs * Message-Id: <9t966x4uqrj.fsf(a)mraz.iskon.hr> | posting-list(a)mailandnews.com (Jari Aalto+mail.emacs) writes: | | [+] | > Emacs 20.4 reports: | > | > window-minibuffer-p is a built-in function. | > Returns non-nil if WINDOW is a minibuffer window. | > (window-minibuffer-p &optional WINDOW) | > | > | > (emacs-version) "XEmacs 21.2 (beta20) \"Yoko\" [Lucid] (i586-pc-win32) of Fri Nov 12 1999 on NEVERYON" | > | > `window-minibuffer-p' is a built-in function | > (window-minibuffer-p WINDOW) | > Documentation: | > Return non-nil if WINDOW is a minibuffer window. | > | > Please sync this... | It's easy to make the argument optional, but note that XEmacs has a | whole bunch of functions starting with `window-'. Do you think all | should be changed that way? This is just my opinion, but if function starts with argument BUFFER ot WINDOW or FRAME, they all should be optional and by default refer to current (active) unit. (function BUFFER) --> (function &optional BUFFER) (function WINDOW) --> (function &optional WINDOW) (function FRAME) --> (function &optional FRAME) jari

1 participants
0 comments

XEmacs 21.2 CVS again usable 24 years, 4 months

Martin Buchholz

My most recent emergency commit to the CVS tree has resulted in an XEmacs that doesn't crash anymore. I am writing this message in such an XEmacs. Nevertheless, caution is advised. Martin

1 participants
0 comments

Latest XEmacs doesn't start 24 years, 4 months

Norbert Koch

Hi! XEmacs doesn't start anymore ... Lisp backtrace follows: # bind (frame-being-created) make-frame(nil #<x-device on ":0.0" 0x1b87>) frame-initialize() # bind (debugger debug-on-error command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) Abort trap (core dumped) (gdb) bt #0 0x28442c78 in kill () from /usr/lib/libc.so.3 #1 0x807fe53 in fatal_error_signal (sig=6) at emacs.c:278 #2 0xbfbfdfdc in ?? () #3 0x8081ecf in assert_failed (file=0x81bd58b "glyphs.h", line=379, expr=0x81bd594 "RECORD_TYPEP (obj, &lrecord_image_instance)") at emacs.c:2828 #4 0x80ebc10 in glyph_dirty_p (glyph_or_image=136724480, window=139030016) at glyphs.c:3518 #5 0x80ec13b in update_glyph_cachel_data (w=0x8496e00, glyph=136724480, cachel=0xbfbfd13c) at glyphs.c:3792 #6 0x80ec216 in get_glyph_cachel_index (w=0x8496e00, glyph=136724480) at glyphs.c:3809 #7 0x80ec294 in reset_glyph_cachels (w=0x8496e00) at glyphs.c:3842 #8 0x80dcca2 in Fmake_frame (props=136452100, device=138948864) at frame.c:468 #9 0x8087f7f in Ffuncall (nargs=3, args=0xbfbfd224) at eval.c:3175 #10 0x805fee0 in execute_optimized_program ( program=0x8402090 "À \210Á ?.Â\013Ä \"¬\037Å\016\006\016\a\"\026\bÉ\016\006 Â\016\nË \"＠\"\211\026\f\026\rÎ\016\006!\026\006Ï\016\020!\210Ñ\211\023\207", stack_depth=5, constants_data=0x8320d90) at bytecode.c:743 #11 0x805f829 in funcall_compiled_function (fun=137476436, nargs=0, args=0xbfbfd330) at bytecode.c:519 #12 0x80880d9 in Ffuncall (nargs=1, args=0xbfbfd32c) at eval.c:3210 #13 0x805fee0 in execute_optimized_program ( program=0x8424010 "\bA\031ÂÃ\034\035Æ\t!\021ÇÈ!«\004É \210\016\n«\020\016\01 3¬\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ßÃ!)\207comm/zenirc/src", stack_depth=4, constants_data=0x836a310) at bytecode.c:743 #14 0x805f829 in funcall_compiled_function (fun=137751932, nargs=0, args=0xbfbfd434) at bytecode.c:519 #15 0x80880d9 in Ffuncall (nargs=1, args=0xbfbfd430) at eval.c:3210 #16 0x805fee0 in execute_optimized_program ( program=0x83e0210 "\b«\005ÁÂ!\207Ã\020Ä \211\035«\030\rG\016\006GW«\020Ç\016 \006!Ç\r!k«\006È\r!\026\006)É\016\006!\026\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ª\0 16Ø\016\022\016\031\016\032\016\e\016\f%\210Ü \210)\016\035¬\022\016\036«\016ßàá \016\"!\016\036\"ãÃ#\210\016\035¬\024\016\032¬\006ä\016%!\210ä\016&!\210ä\016'!\ 210è\216é )\207", stack_depth=7, constants_data=0x836a610) at bytecode.c:743 #17 0x805f829 in funcall_compiled_function (fun=137751876, nargs=0, args=0xbfbfd4d8) at bytecode.c:519 #18 0x80878c3 in Feval (form=136895644) at eval.c:3034 #19 0x8084ce0 in condition_case_1 (handlers=136452196, bfun=0x8086e24 <Feval>, barg=136895644, hfun=0x8069214 <cmd_error>, harg=136452100) at eval.c:1629 #20 0x8069fb5 in top_level_1 (dummy=136452100) at cmdloop.c:202 #21 0x8084a30 in internal_catch (tag=136534092, func=0x8069f8c <top_level_1>, arg=136452100, threw=0x0) at eval.c:1304 #22 0x806935d in initial_command_loop (load_me=136452100) at cmdloop.c:281 #23 0x8081073 in xemacs_21_2_b26_i386_unknown_freebsdelf3_2 (argc=2, argv=0xbfbfd748, envp=0xbfbfd754, restart=0) at emacs.c:1901 #24 0x8081785 in main (argc=2, argv=0xbfbfd748, envp=0xbfbfd754)

2 participants
1 comments

Re: Info disaster? 24 years, 4 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > For me the scanning takes a few seconds and surely is worth it. > > "A few seconds" is a long time when it repeats all the time. But it is only once per XEmacs session, and it is very small in comparison with the time I actually spend reading the documentation. > it very annoying. (And I also wonder about the memory footprint, but > I'm repeating myself here.) We give the memory of destroyed buffers back don't we? > > 2. In pathological cases, i.e. grossly out of date dirfiles and > > > > Ad 2. I would say this falls under the "Don't do that then" category. > > Just make sure your dirfiles are complete. > > How do I do that? Don't use unstable versions of distributions (although I need to see whether the transition is complete enough, come potato release time). Alternatively, ask "your sysadmin" to run a tool to rebuild the system-wide dir files (Unfortunately the only such tools seems to be XEmacs). > > Ad 3. Seems like a good idea. Something for under ~/.xemacs? > > What's ~/.xemacs? A convenient directory for XEmacs to write stuff too, such as precomputed help tables of contents. Jan

1 participants
0 comments

Warning: building with the layout stuff 24 years, 4 months

Andy Piper

Something I should mention is that the layout code seems to (I think) tickle an optimizer bug in the version of gcc I have. I have to build glyphs.c without optimization to get around it. Simplistic reorganisation of glyphs.c does not cure it - but I'm sure someone (Martin ?:) will be able to figure it out. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

3 participants
2 comments

The most cost-effective marketing tool 24 years, 4 months

liucan

we are the World's Largest distributor of direct company news and other business communications materials. we can broadcast your web site news or your business, or a new service within your business ( you can add your logo/photo to your press release ) to every Newspaper, Magazine, Television and Cable Channel, AM/FM Radio Station and all major media outlets in the top daily and national newspapers, top industry and segment publications, TV, Radio, and top online news sources in the world. Direct e-mail service that generates new lists based on the target market for your products/services,we specialize in helping increase business contacts and sales through the use of targeted consumer and business lists. For more information welcome to:http://www.longf.com --------------------------------------------------------------------------------

1 participants
0 comments

Re: [XEmacs] signal vs. error 24 years, 4 months

Hrvoje Niksic

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Ok, I see that the debugger now can continue from signals. The > XEmcas Lisp Reference Manual section about signals and errors should > probably be updated to reflect that. Now fixed in CVS. Probably should add a more detailed description of the concept of continuable errors.

1 participants
0 comments

Re: 21.2 Out of sync: window-minibuffer-p arg is optional in Emacs 24 years, 4 months

Hrvoje Niksic

posting-list(a)mailandnews.com (Jari Aalto+mail.emacs) writes: > Emacs 20.4 reports: > > window-minibuffer-p is a built-in function. > Returns non-nil if WINDOW is a minibuffer window. > (window-minibuffer-p &optional WINDOW) > ========== > > (emacs-version) "XEmacs 21.2 (beta20) \"Yoko\" [Lucid] (i586-pc-win32) of Fri Nov 12 1999 on NEVERYON" > > `window-minibuffer-p' is a built-in function > (window-minibuffer-p WINDOW) > Documentation: > Return non-nil if WINDOW is a minibuffer window. > > Please sync this... It's easy to make the argument optional, but note that XEmacs has a whole bunch of functions starting with `window-'. Do you think all should be changed that way?

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