Re: Info disaster?

Saturday, 8 January 2000

        Daniel Pittman <daniel(a)danann.net&gt; 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.)

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