January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [patch] XEmacs 21.2.20 executable-find sync-up with Emacs 24 years, 10 months

Hrvoje Niksic

posting-list(a)mailandnews.com (Jari Aalto+mail.emacs) writes: > Hope I patched the right version. (How do I know that I have the > latest xemacs-packages?) Note that patches you wish added to XEmacs and its packages should be sent to <xemacs-patches(a)xemacs.org>.

1 participants
0 comments

Re: Info disaster? 24 years, 10 months

Hrvoje Niksic

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. 1) I meant: cache between two invocations of XEmacs. 2) What you describe is unfortunately not what I see. For me, dir file in some cases gets regenerated every now and then. > > This does not sound promising. I haven't changed the default, and > > I suffer this highly problematic behaviour. How can we adapt to > > the situation? > > I don't feel this as problematic. On my Pentium 300 MHz at home it > causes a delay of only 4 seconds when doing `M-x info' the first > time. 4 seconds is a lot. If you're running on an old 486, multiply it with ten. It's not really acceptable IMHO.

1 participants
0 comments

core dump xemacs-21.2.26 sparc-sun-solaris2.6 24 years, 10 months

Nathan Inada

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta26) "Millenium" [Lucid] (sparc-sun-solaris2.6) of Sun Jan 2 2000 on maui configured using `configure --prefix=/opt/gnu --site-libraries=/opt/gnu/lib:/opt/lib --site-runtime-libraries=/opt/gnu/lib:/opt/lib '--package-path=~/.xemacs:/opt/gnu/share/xemacs/packages:/opt/gnu/share/xemacs/packages:' --site-includes=/opt/gnu/include:/opt/include --with-workshop --error-checking=none' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Dont recall. I think i was in vm (package 1.22) Lisp backtrace: resize-subwindow(#<image-instance (widget) on #<x-device on "maui:1.0" 0x132e8> (#<face default "default face">)Buffers 509x19 on #<x-frame > 0x1252000 0x159e1> 509 nil) # bind (inst buffers) remove-buffer-from-gutter-tab() # (unwind-protect ...) kill-buffer(#<buffer " sendmail temp">) byte-code("..." [kill-buffer tembuf bufferp errbuf] 2) # bind (errbuf tembuf case-fold-search resend-to-addresses delimline mailbuf) sendmail-send-it() mail-send() # (unwind-protect ...) # bind (this-command composition-buffer vm-reply-list vm-forward-list vm-redistribute-list) vm-mail-send() # bind (b arg) vm-mail-send-and-exit(nil) # bind (command-debug-status) call-interactively(vm-mail-send-and-exit) # (condition-case ... . error) # (catch top-level ...) M-x describe-installation gives: uname -a: SunOS maui 5.6 Generic_105181-03 sun4u sparc SUNW,Ultra-2 /home/nathan/Tmp/Gnu/xemacs-21.2.26/configure '--prefix=/opt/gnu' '--site-libraries=/opt/gnu/lib:/opt/lib' '--site-runtime-libraries=/opt/gnu/lib:/opt/lib' '--package-path=~/.xemacs:/opt/gnu/share/xemacs/packages:/opt/gnu/share/xemacs/packages:' '--site-includes=/opt/gnu/include:/opt/include' '--with-workshop' '--error-checking=none' XEmacs 21.2-b26 "Millenium" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /home/nathan/Tmp/Gnu/xemacs-21.2.26 What installation prefix should install use? /opt/gnu What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.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/dt/include /usr/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Additional header files: /opt/gnu/include /opt/include Additional libraries: /opt/gnu/lib /opt/lib Runtime library search path: /opt/gnu/lib:/opt/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 support for Berkeley DB. Compiling in support for DBM. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for Sun WorkShop. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif 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. Here is the C backtrace: (gdb) where #0 0xef08828c in _libc_kill () from /usr/lib/libc.so.1 #1 0x4b3e4 in fatal_error_signal (sig=11) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/emacs.c:276 #2 <signal handler called> #3 0xef345774 in SetValues () from /usr/lib/libXt.so.4 #4 0xef345cdc in XtSetValues () from /usr/lib/libXt.so.4 #5 0x13a024 in x_resize_subwindow (ii=0x103a880, w=509, h=19) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/glyphs-x.c:2295 #6 0xb1a30 in Fresize_subwindow (subwindow=17016960, width=1019, height=19) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/glyphs.c:4231 #7 0x50980 in Ffuncall (nargs=727304, args=0xefffccec) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3175 #8 0x27e44 in execute_optimized_program (program=0x609148 "*\207", stack_depth=3, constants_data=0x3fa210) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:743 #9 0x27a48 in funcall_compiled_function (fun=4198064, nargs=0, args=0xefffd168) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:516 #10 0x50b4c in Ffuncall (nargs=0, args=0xefffd164) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3210 #11 0x51744 in run_hook_with_args_in_buffer (buf=0x232804, nargs=1, args=0xefffd164, cond=RUN_HOOKS_TO_COMPLETION) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3661 #12 0x53c40 in run_hook_with_args (nargs=1, args=0xefffd164, cond=RUN_HOOKS_TO_COMPLETION) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3674 #13 0x53c68 in run_hook (hook=4248468) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3528 #14 0x23384 in Fkill_buffer (buffer=2304004) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/buffer.c:1218 #15 0x50954 in Ffuncall (nargs=143540, args=0xefffd374) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3175 #16 0x27e44 in execute_optimized_program ( program=0xefffd433 "\210Â\013!«\005À\013!\210À\207", stack_depth=1, constants_data=0xa4fdb0) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:743 #17 0x2a4e4 in Fbyte_code (instructions=-268446672, constants=10812832, stack_depth=5) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:2398 #18 0x50268 in Feval (form=10802920) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:2975 #19 0x54764 in Fprogn (args=10802956) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:766 #20 0x529ec in unbind_to_hairy (count=10) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:4615 #21 0x27f20 in execute_optimized_program (program=0xa26621 "\207", stack_depth=46, constants_data=0xa39210) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:756 #22 0x27a48 in funcall_compiled_function (fun=10754724, nargs=0, args=0xefffdbd0) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:516 #23 0x50b4c in Ffuncall (nargs=0, args=0xefffdbcc) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3210 #24 0x27e44 in execute_optimized_program ( program=0xb357af "\210\016\013«\016ÌÍÎ\217\210\016\013A\211\026\013¬ôÈÏ!\210\b«\005Ã ¬\tÐÌ!\210ÑÒ!\207\016\023¬\tÁÔÕ\b\"!\003Ö \207", stack_depth=0, constants_data=0xa01210) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:743 #25 0x27a48 in funcall_compiled_function (fun=10754696, nargs=0, args=0xefffde48) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:516 #26 0x50b4c in Ffuncall (nargs=0, args=0xefffde44) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3210 #27 0x27e44 in execute_optimized_program ( program=0x860b8a "\210*p\016\023=«'\016\034Ý=«\006Þ \210ª\025\016\034ß=«\006à \210ª\n\016\034á=«\004â \210ã \210äp!\210åÖ\211æç$,\207", stack_depth=0, constants_data=0xa3ef10) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:743 #28 0x27a48 in funcall_compiled_function (fun=10241488, nargs=0, args=0xefffe0c8) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:516 #29 0x50b4c in Ffuncall (nargs=0, args=0xefffe0c4) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3210 #30 0x27e44 in execute_optimized_program ( program=0xb359aa "\210É\016\a!¬\017ÊË !q\210ÌÍ\211ÎÏ$ª\rÌ\016\aÍÐÑ$\210Ò\016\a!)\2076b\024", stack_depth=0, constants_data=0xa01810) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:743 #31 0x27a48 in funcall_compiled_function (fun=10241264, nargs=1, args=0xefffe33c) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/bytecode.c:516 #32 0x50b4c in Ffuncall (nargs=1, args=0xefffe338) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:3210 #33 0x2c978 in Fcall_interactively (function=5702404, record_flag=2304004, keys=2304004) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/callint.c:946 #34 0x4f618 in Fcommand_execute (cmd=5702404, record=2304004, keys=2304004) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:2613 #35 0x7a834 in execute_command_event (command_builder=0xc20080, event=9218980) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/event-stream.c:4332 #36 0x7aef4 in Fdispatch_event (event=9218980) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/event-stream.c:4643 #37 0x3121c in Fcommand_loop_1 () at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/cmdloop.c:575 #38 0x31484 in command_loop_1 (dummy=2304004) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/cmdloop.c:490 #39 0x4cfc0 in condition_case_1 (handlers=2304100, bfun=0x31468 <command_loop_1>, barg=2304004, hfun=0x314e4 <cmd_error>, harg=2304004) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:1629 #40 0x315f4 in command_loop_2 (dummy=2304004) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/cmdloop.c:252 #41 0x544c0 in internal_catch (tag=2385996, func=0x315a8 <command_loop_2>, arg=2304004, threw=0x0) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/eval.c:1304 #42 0x30d50 in initial_command_loop (load_me=2304004) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/cmdloop.c:301 #43 0x49a4c in sort_args (argc=1783808, argv=0xeffff32c) at /home/nathan/Tmp/Gnu/xemacs-21.2.26/src/emacs.c:1898 (gdb)

2 participants
1 comments

Dynamic layouts part #1 24 years, 10 months

Andy Piper

This patch changes geometry calculation of widgets to be dynamic, this has a number of desirable side-effects including making widget updates more asynchronous. part #2 will be actually fixing the layout widget to lay out its children dynamically and intelligently. I will apply this tomorrow. andy 2000-01-08 Andy Piper <andy(a)xemacs.org> * event-msw.c (mswindows_wnd_proc): don't need to check for widget face anymore. * frame.c (change_frame_size_1): use new glyph_* signatures. (frame_conversion_internal): ditto. * toolbar-x.c (x_get_button_size): Use modified glyph_* signatures. * redisplay.c (add_glyph_rune): Use modified glyph_* signatures. (add_glyph_rune): dittto. (add_margin_runes): ditto. (create_left_glyph_block): ditto. (create_right_glyph_block): ditto. (redisplay_window): ditto. * redisplay-output.c (redisplay_output_layout): Use modified glyph_* signatures. * glyphs.h: (struct image_instantiator_methods): change signature of query_geometry and layout. (struct Lisp_Image_Instance): Clean up fields for dynamic geometry calculations. (struct expose_ignore): change field types. (struct subwindow_cachel): ditto. declare new functions and accessor macros. * glyphs.c: (instantiate_image_instantiator): assign glyph when creating the image instance. (image_instance_hash): fixup for new and deleted fields. (image_instance_equal): ditto. (mark_image_instance): ditto. (print_image_instance): ditto. (allocate_image_instance): zero width and height. assign attached glyph. mark as dirty for future layout. (make_image_instance_1): pass Qnil as the glyph its attached to. (Fimage_instance_height): simply return the height. (Fimage_instance_width): simply return the width. (image_instance_query_geometry): new function. query the image instance's geometry by wiring through to format and device specific methods. fallback on the existing geometry. (image_instance_layout): new function. layout the image instance by querying its geometry and then wiring through to format and device specific methods. (query_string_geometry): new function to decide the bounding box of a string. text glyph geometry calculations moved here. (query_string_font): new function. find out the font for a given string in a given face. (text_query_geometry): return geometry based on quert_string_geometry. (formatted_string_instantiate): call string_instantiate. (image_instantiate): put strings in the per-window cache. Feed the glyph to the instantiated image instance. (glyph_height_internal): deleted. (glyph_width): simply return the required dimension. re-layout if the instance is dirty. Remove references to face_index and frame_face which were only used for strings. (glyph_ascent): ditto. (glyph_descent): ditto. (glyph_height): ditto. (Fglyph_width): use new glyph_width function. (Fglyph_ascent): use new glyph_ascent function. (Fglyph_descent): use new glyph_descent function. (Fglyph_height): use new glyph_height function. (glyph_property_was_changed): (glyph_image_instance_maybe): new function to possible create an image instance from a glyph if we don't have one already. (glyph_dirty_p): use it. (glyph_layout): new function for laying out a glyph. (glyph_query_geometry): new function for finding out the desired geometry of a glyph. (update_glyph_cachel_data): use new glyph_* signatures. (update_subwindow): call resize_subwindow. (map_subwindow): call update_subwindow if the image is dirty. (subwindow_instantiate): add comment. (Fresize_subwindow): don't actually resize the window, just record the values and let update_subwindow handle it. (Fglyph_animated_timeout_handler): use MARK_IMAGE_INSTANCE_CHANGED. (image_instantiator_format_create): declare things with query_geometry and layout functions. * glyphs-x.c: (x_update_subwindow): remove widget sizing. (update_widget_face): use query_string_font. (x_widget_set_property): don't return Qt when setting is succesful. (x_combo_box_instantiate): call widget_instantiate rather than widget_instantiate_1. * glyphs-widget.c: (widget_face_font_info): deleted. (widget_text_to_pixel_conversion): deleted. (widget_set_property): make sure the new text gets propagated to the image instance. (widget_layout): new function. wire through to device and format specific methods. (widget_query_geometry): new function. wire through to device and format specific methods. fallback on geometry of widget text. (initialize_widget_image_instance): fixup new fields. (widget_instantiate_1): deleted. (tree_view_instantiate): deleted. (tree_view_query_geometry): new function. returns desired sizing of tree view. (tab_control_instantiate): deleted. (tab_control_query_geometry): new function. returns desired sizing of tab. (widget_instantiate): subsume widget_instantiate_1. Fixup geometry things in the light of dynamic layout. (static_instantiate): deleted. (layout_instantiate): use new glyph_* signatures. (image_instantiator_format_create_glyphs_widget): fixup query_geometry and layout declarations for various widgets. * glyphs-msw.c: (mswindows_widget_instantiate): add comment. (mswindows_button_instantiate): use query_string_font for geometry calculations. (mswindows_update_subwindow): ditto. (mswindows_combo_box_instantiate): fixup for new geometry management. (mswindows_widget_set_property): Don't return Qt so that other methods can be called. * gutter-items.el (update-tab-in-gutter): remove resize-subwindow calls. (remove-buffer-from-gutter-tab): ditto. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

New packages uploaded 24 years, 10 months

Andreas Jaeger

I've uploaded a few packages to ftp.xemacs.org/xemacs/beta/incoming. Please give the packages a good testing before I release them. Andreas P.S. Here're the changes: Major updates: - texinfo synch with Emacs 20.5 - calendar synch with Emacs 20.5. - reftex version 4.10 Minor updates: - bugfix for egg-its when inputing from the modeline. - small mule-base problem fixed (mule-debug isn't included but leaked into autoloads) - TUTORIAL.ja has been removed from mule-base, the core contains the version already. - moved mailheader from package gnus to package mail-lib for usage of Gnus 5.8.x. The gnus package still contains Gnus 5.6.45 - but it's now possible to use Gnus 5.8.x. An update to 5.8.x will come after it's more stable. - Added kfm support to browse-url (package mail-lib) - fixed a Y2K bug in vc - Fix bookmark-completing-read (package edit-utils) - documentation update for read-passwd (package xemacs-base) - timezone now handles year 69 as 1969 (package xemacs-base) Here is how you use them with List & Install: (setq package-get-remote '(("ftp.xemacs.org" "xemacs/beta/incoming"))) -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: Info disaster? 24 years, 10 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > were traditional. The problem is that Info used to start up just fine > only several months ago. Depends on your definition of "just fine". In the pre-autobuilding case it just didn't find all the info files. See below.. > Or, just look at what the standalone info does, and copy that. That just uses "pick the first dir file we see and assume it is correct". The problem with that is that this assumption is typically incorrect. Dirfiles are rarely well maintained. Modern Linux distributions are improving this a lot (thanks to install-info). In fact Debian was one of the first to do so. You just are caught in the middle of their /usr/share/info transition. The autobuilding is a solution to a real problem (I love finally seeing all the info files in info browser), so just switching it off is a non-option in my view. Important note: If your dirfiles are up to date, their will be no scanning[1]. For me the scanning takes a few seconds and surely is worth it. You have three more or less independent issues 1. Scannings gives some meaningless errors in the minibuffer. 2. In pathological cases, i.e. grossly out of date dirfiles and compresses info files it can take a long time. 3. There needs to be a way to save the results for those without write access. Ad 1. Must be fixable by improving the elisp. Ad 2. I would say this falls under the "Don't do that then" category. Just make sure your dirfiles are complete. maybe it could be helped some by not uncompressing and inserting the complete file but just the header to search for the direntry. Ad 3. Seems like a good idea. Something for under ~/.xemacs? Footnotes: [1] Note that this will never completely be the case because of the package system.

1 participants
0 comments

Re: W3 kills emacs 24 years, 10 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Norbert Koch <norbert(a)s.netic.de> writes: > > > Hi! > > > > 21.2 (beta26) "Millenium" XEmacs Lucid (built on FreeBSD-3.2); > > > #3 0x80843e7 in assert_failed (file=0x81dd1c2 "insdel.c", line=1117, > > expr=0x81dd1e0 "( retval) >= BI_BUF_BEG (buf) && retval <= BI_BUF_Z (buf)") > > at emacs.c:2828 > > #4 0x810bd34 in bufpos_to_bytind (buf=0x8b73400, x=355) at insdel.c:1117 > > #5 0x80c9406 in report_extent_modification (buffer=146224128, start=1, > > end=355, inside=0x82196b8, afterp=1) at extents.c:2272 > > #6 0x8109201 in signal_after_change (buf=0x8b73400, start=1, orig_end=1, > > new_end=355) at insdel.c:2298 > > Huh? It thought this one was fixed. By whom? When? Not yet, comrade. Not yet.

1 participants
0 comments

Re: Info disaster? 24 years, 10 months

Hrvoje Niksic

Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes: > You can test these settings until Debian provides correct > /usr/share/info/dir. > > (setq Info-additional-search-directory-list '("/usr/share/info")) > (delete "/usr/share/info" Info-directory-list) This works nicely -- you've made me a new man. :-) Now I wonder what we can do to make it behave sensibly by default. Or, are Debian systems just too broken for us to bother?

1 participants
0 comments

Re: Info disaster? 24 years, 10 months

Hrvoje Niksic

Daniel Pittman <daniel(a)danann.net> writes: > >> Info mode is looking in the files to build a usable `dir' file. > > > > This would be a bad idea (read: slow) even if the files were not > > gzipped. Shouldn't we just list the info files without opening > > them? > > I didn't find the performance bad enough to be a problem on my old > P-166/80MB machine; it's certainly not on my current system. I can't really explain that. For me, it takes several seconds for Info to start up on a "slower" Linux machine. It wouldn't be that bad if it were traditional. The problem is that Info used to start up just fine only several months ago. > > Or, couldn't XEmacs do the charade *once*, and then cache the > > results. (Yes, I know XEmacs can write out the created `dir' > > file, but that's out of the question because I don't have write > > permissions on /usr/share/info.) > > Ditto. Caching the results would be the best plan, I think, if there > is not write access to the real `dir' file. Or, just look at what the standalone info does, and copy that. > Change the default to 'never? Not very friendly though; this will > fail to display the info files when `dir' really isn't there. > > Erm, maybe info mode can be made smarter about this or something. I > don't think it's that big a problem though. As always, it depends on point of view. Given that Info is our canonical documentation system, it might not be acceptble to have it behave so badly at startup by default. (I wonder how much memory opening all those info files in succession takes up.)

1 participants
0 comments

Re: Info disaster? 24 years, 10 months

Hrvoje Niksic

Daniel Pittman <daniel(a)danann.net> writes: > On 07 Jan 2000, Hrvoje Niksic <hniksic(a)iskon.hr> wrote: > > > I've been seeing this for quite a while, but I haven't had time to do > > anything about it, so I kinda hoped it'd go away. The thing is, when > > I first start info, I see these messages (in chronological order): > > [...] > > > What the <beep> is it? > > Info mode is looking in the files to build a usable `dir' file. This would be a bad idea (read: slow) even if the files were not gzipped. Shouldn't we just list the info files without opening them? Or, couldn't XEmacs do the charade *once*, and then cache the results. (Yes, I know XEmacs can write out the created `dir' file, but that's out of the question because I don't have write permissions on /usr/share/info.) > Debian, bless their little soul, have `dir.gz' in the directory with > nothing listed. You're quite right. I wonder how the standalone info reader gets away with it. A little straceing reveals that it never bothers with /usr/share/info/dir.gz -- it simply reads /usr/info/dir/. Which is weird, because /usr/share/info/ is supposed to be the canonical Info location on Debian. It seems, however, that /usr/info/dir happily indexes the contents of *both* /usr/info and /usr/share/info. Bless their little soul, indeed. > > Even on my all-cool 500MHz pentium at work, unzipping all that junk > > takes some time. Before I hack into the code, does anyone know what's > > supposed to be happening? > > I don't get this until the first time I invoke Info mode, That's when I get it too. Since I use Info quite often, that's sort of unsatisfactory. > The variable that controls it is: > > (defcustom Info-auto-generate-directory 'if-missing > "*When to auto generate an info directory listing. > Possible values are: > nil or `never' never auto-generate a directory listing, > use any existing `dir' or `localdir' file and ignore info > directories containing none > `always' auto-generate a directory listing ignoring existing > `dir' and `localdir' files > `if-missing', the default, auto-generates a directory listing > if no `dir' or `localdir' file is present. Otherwise the > contents of any of these files is used instead. > `if-outdated' auto-generates a directory listing if the `dir' > and `localdir' are either inexistent or outdated (touched > less recently than an info file in the same directory)." This does not sound promising. I haven't changed the default, and I suffer this highly problematic behaviour. How can we adapt to the situation?

2 participants
1 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