[Doesn't this discussion belong in debian-doc? I am going to CC it
there, and move there with the discussion. :-) <--winning smile.]
>>>>> "Fernando" == Fernando <[EMAIL PROTECTED]> writes:
KMH> `gv' and alladin ghostscript rules! (And DEC SRC's Virtual
KMH> Paper, if you own a Zip drive or have plenty of hard disk.)
Fernando> I am glad your eyes are so healthy!!!
They are in focus now! Alladin is great! Have you seen the latest
version of `gv'? He added a tracking line, so when you press the
arrow to see the other half of a page, a line appears across the page
where it used be cut off, for just long enough for you to move your
eyes there. It's a great feature. (Just like SRC's `Lectern' does
it.)
Now if we only had display ghostscript in a GGI X server...
KMH> You don't know what you're talking about, IMO. I suggest you
KMH> read the help and tutorial for using `info'. The interface
KMH> is *not* "crappy". It is very powerful. Sometimes the keys
KMH> seem a little odd;
Fernando> I do know what I am talking about. I don't like
Fernando> info. You like it. Fine. But if the default format is
Fernando> HTML then I should "win", because no info file should be
Fernando> installed by default in my system. But HTML should be
Fernando> installed by default in yours.
Win... yes. :-) The timing stats you posted tell me a story I hadn't
known. I've gotten spoiled by this (relativly) fast computer.
People _should_have_a_choice_of_which_documentation_format_to_install_,
and be advised as to the disk space requirements, as well as the
processing resource requirements of each format. They should be
presented with a brief advantage/disadvantage summary of each format.
The summary should be shotgun targetted at various types of
installations:
networks where the docs are installed centrally on one server:
nfs/info/man, html/httpd, fast internet
single user small system:
html/httpd, info/man, modem to the internet.
developer workstation:
info/man, html/httpd, modem to the internet, everything you
can get ahold of, fill your drives with books, get a numb rear end
sitting all day typing email when you should be reading the
books... :-)
??? any other situation? (You tell me and we'll both know.)
KMH> For some reason, serving gzipped files from `boa' (Version:
KMH> 0.92-5) does not work, given mailcap entries that function
KMH> fine with apache served documents. Can anyone verify this?
Fernando> It works for me with boa 0.92-4 Maybe there is a bug in
Fernando> 0.92-5. I'm using the default configuration. Maybe
Fernando> there is some nasty interaction between boa and apache
Fernando> if you have both installed.
Only one is running at a time though. Port 80 is taken, so you can't
run both unless one's on an oddball port. I think what's wrong is
that `boa' is sending bad MIME headers or something. The `mailcap'
resolution isn't working right. The identical mailcap works fine when
`apache' is serving the gzipped html page. `boa' serves flat html files
with no trouble.
KMH> * `boa' /cannot/ be run from `inetd' or `xinetd' in its
KMH> present incarnation.* It needs to have a configuration option
KMH> added, like `apache' has, so that it will exit after serving
KMH> a series of requests
Fernando> True. But for a small system it is very fast. I have not
Fernando> tried apache. It might be ok too. According to boa's
Fernando> documentation, apache takes twice the time boa uses. In
Fernando> my 386 SX-25 that would mean 6 seconds instead of 3
Fernando> seconds, which is perfectly acceptable. Lynx takes 90
Fernando> seconds so I wouldn't notice the extra delay!!
Can you try apache, from inetd, and see how it works for you? It's
fairly easy to install. It can be installed concurrently with `boa',
though only one can run on the same port at the same time.
You have to set the "ServerType" to /"inetd"/ near the top of
"/etc/apache/httpd.conf", and add an entry to "/etc/inetd" like:
www stream tcp nowait www-data /usr/sbin/tcpd /usr/bin/apache
Or to "/etc/xinetd.conf" like the one I showed earlier.
... don't forget to HUP `inetd', or USR1 `xinetd'.
Fernando> And formatting man pages takes even longer...
You can make a script that will preformat (and gzip) all of your man
pages. Slackware installs them in that form. (Perhaps you could use
`alien' to convert and install their package?)
Maybe this should be an option for us too. Not everyone needs the
groff source.
Fernando> We are not talking about the best way, but a way that
Fernando> works in any system. Emacs is not it.
I guess it's just too much AI for a 386sx with low RAM... ? How does
the stand-alone info browser work for you? Can you search? Do the
arrow keys work right, or do you have to use {C-n} and {C-p}? Will it
look up a man page like it should, when you press {Alt-x man} or
{ESC x man}? Can you {C-s} and search in those with it? Will it let
you hyperlink to other man pages within it? Can you leave it running
on another VT while you work, or suspend it when you don't need it for
a while?
KMH> No! You cannot just erase that directory if Emacs or XEmacs
KMH> are...
Fernando> But you can erase the compiled info files and update the
Fernando> index. That is what I meant.
Yes, I suppose... but if Emacs or XEmacs is installed, they'll
"Depends:" on the info manuals too, won't they?
KMH> (Koalatalk someday. ;-) )
Fernando> What does that mean?
`YaHoo' for "Koalatalk" :-) I thought it sounded like a really great
thing for Linux! Maybe it will work well with Garnet... mmm. Amulet.
--
mailto:[EMAIL PROTECTED] (Karl M. Hegbloom)
http://www.inetarena.com/~karlheg
Portland, OR USA
Debian GNU 1.3 Linux 2.1.36 AMD K5 PR-133
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
