Re: man v. info
on Thu, Dec 27, 2001 at 02:14:36AM +0100, Michael Mauch ([EMAIL PROTECTED])
wrote:
Karsten M. Self wrote:
on Wed, Dec 26, 2001 at 04:31:12PM +0100, Michael Mauch ([EMAIL PROTECTED])
wrote:
Karsten M. Self wrote:
...
With gcc-2.95-doc installed, load time is ~1-2 seconds in Galeon from a
text file sitting on /tmp.
Wow, that's fast. Is that the time time until it starts displaying the
first page(s) or is it the time until the whole page is loaded (CPU
usage goes down to normal, mouse cursor is normal again)?
Whole page. Note that as Galeon allows reading and navigating (e.g.:
page-down) during page load, the primary concern is how long before the
text renders suitably for reading.
This takes more than 30 seconds here. Oh, wait a moment - Galeon 1.0
from the Debian system really is a lot faster (2 seconds for the whole
file). So maybe something went wrong with my Galeon-0.12.7 build here
(built from sources on something that once was a SuSE-6.1).
0.12.x = 1.0 made some strides.
I'm sorry, this was my own fault then.
;-)
Honest, too
...
When I want to search a directory of HTML files, I tend to grep it
first, then view the files that seem to be apropos.
One better:
$ less $( grep -l 'pattern' filelist )
And then you read the plain HTML source? Not very cool, frankly.
pedantic
$ for file in $( list ); do w3m $file; done
/pedantic
And then I type my search string into a dozen of w3m instances? Still
not convinced.
OK. Write a script:
#!/bin/bash
PATH=/bin:/usr/bin
TEMPFILE=$( tempfile )
if [ ! -f ${TEMPFILE}.html ]
then mv $TEMPFILE ${TEMPFILE}.html || ( rm -f $TEMPFILE; exit 1 )
else exit 1
fi
TEMPFILE=${TEMPFILE}.html
trap 'rm -f $TEMPFILE' 0 1 2 3 13 15
pattern=$1
shift
filelist=$@
echo htmlbodyol $(
for file in $( grep -l $pattern $filelist )
do
echo lia href='$file'$file/a
done
)/ol/body/html $TEMPFILE
w3m $TEMPFILE
rm -f $TEMPFILE
Invoke as: $ w3mgrep pattern list of files to search
A local search engine like mnogosearch, htdig or glimpse could help,
of course. Is there a Debian package with already set-up configuration
for one of these? I seem to remember that FreeBSD has something like
this (htdig-based and with man2html and info2html).
Try dwww.
Thank you, that's great! And with info2www the info books are there,
too. But then: how can I search for e.g. assembler in the gawk book?
No idea. I started using d yesterday ;-)
I think a decent search facility is a must for more in-depth
documentation. If I _know_ that I want to use newwin(3), I can easily
type man newwin. But if I just want to get started with curses, I am
really lost after man -k curses. A hierarchical book (be it in
HTML or in info format) with a Getting started topic is a lot more
user-friendly in such cases.
Most man pages have a SEE ALSO section.
Yes, but it's totally unstructured and these links tell nothing about
what I might expect on the linked pages. Just the man page names, and
then go figure it out for yourself, we don't care where you get lost in
man page land.
You can _somewhat_ work things out, if only by the man page section (man
man for info), which will tell you if the page is a command, a file,
system or library call, or other component. Could be better, but at
least it's there.
Peace.
--
Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
What part of Gestalt don't you understand? Home of the brave
http://gestalt-system.sourceforge.net/Land of the free
We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire http://kmself.home.netcom.com/resume.html
pgpBVOjHRRvwQ.pgp
Description: PGP signature
Re: man v. info
on Wed, Dec 26, 2001 at 08:10:46PM -0500, dman ([EMAIL PROTECTED]) wrote: On Wed, Dec 26, 2001 at 04:31:12PM +0100, Michael Mauch wrote: | ((X)Emacs is everywhere). Hmm, $ dpkg -l \*emacs\* | grep ^ii $ I think I just found nowhere :-). ...but are you in the _middle_ of it. That's the important part. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html pgpckGMflvjzu.pgp Description: PGP signature
Re: printcap(5) and other poorly formatted manpages (was Re: man v. info)
On Wed, Dec 26, 2001 at 01:48:55PM -0800, Karsten M. Self wrote: on Wed, Dec 26, 2001 at 02:29:19PM -0600, Colin Watson ([EMAIL PROTECTED]) wrote: Ugh, yes, that's horrible formatting. '.nf' means no-fill mode, but it has the effect you're thinking of. Make sure you add this line to the top of the file to let man know that it should be using tbl: '\ t .nf definitely shouldn't be used for lazy attempts at tables like that. OK. I've got to rewrite the page (again) using tbl. I did something somewhat different, within groff, which works, sorta, but could be better. Anyone got a q'n'd tbl ref? There's a short section in the back of KR (or is it KP?). How does one embed tbl within a manpage? I'm not sure if the tbl manual linked off this troff resources page helps; I'm at a Windows machine at my parents' at the moment and can't be bothered figuring out how to view PostScript. http://www.kohala.com/start/troff/troff.html To embed tbl in a man page, use .TS and .TE. See tbl(1), or the source for man pages that use tbl such as man(1) and kill(1). Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: man v. info
On Tue, 25 Dec 2001 17:24:26 +0100, Imre Vida [EMAIL PROTECTED] wrote: As far as info is concerned, i fully agree with Karsten. It doesn't work intuitively for me either; i just get lost in the maze of links and 3 sentence pages I hate it for this. Use pinfo. Feels like lynx. Much more intuitive. The default colors suck, though. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: man v. info
On Tue, Dec 25, 2001 at 03:02:25PM -0800, Karsten M. Self wrote:
on Tue, Dec 25, 2001 at 12:51:09PM -0600, Colin Watson
([EMAIL PROTECTED]) wrote:
Come up with examples and send patches. That'll achieve results much
faster than anything else I can think of.
Specific instructions on how to do this?
I significantly reformatted the printcap(5) man page at one point and
sent the result to the package maintainer, with no results or
response.
This is, unfortunately, just a specific case of the general problem that
a lot of non-urgent problems don't get dealt with promptly, especially
if the maintainer isn't very active.
Do use the bug tracking system. In the case of printcap(5), a bug should
be filed against the three packages that contain it (lpr, lprng,
lpr-ppd), and I can't find anything from you against any of those
packages, although I was reading quickly so I could have missed it. If
you don't use the bug tracking system, then if a new maintainer takes
over the package he/she typically won't see the mail you sent, and your
work will have been wasted. Even active maintainers are more likely to
respond to things filed in the BTS, as it provides an automatic to-do
list.
(If you send me a bug by private mail that I can't deal with Right Now,
chances are I'll file it in the BTS myself, but I might not always
remember before my inbox floods onto another screen.)
If you'll look at printcap manpage, you'll find that large portions of
it are essentially pre formatted text (or the groff equivalent), and
structured for a terminal window rather wider than 80 characters.
Probably depends on which package you're looking at. The version in lpr
uses mdoc's .Bl request to construct a list, and looks OK.
Might be useful to go through the manpages and look for similar
issues
It should be possible to do this automatically.
for x in `find /usr/share/man -type f`; do
man -l $x | grep -q '.{81,}' echo $x
done
... or something morally equivalent.
--
Colin Watson [EMAIL PROTECTED]
Re: man v. info
Karsten M. Self wrote: on Tue, Dec 25, 2001 at 06:32:31PM -0800, Craig Dickson ([EMAIL PROTECTED]) wrote: Carl Fink wrote: BTW, for HTML docs, put them all in *one* file with hyperlinks. There is no meaningful advantage to cutting it into twenty pieces, and it makes searching significantly more difficult. For locally-stored docs that's arguable. The advantage of small files comes when you have to read it across a network, especially a WAN. I'd disagree. Info nodes can be _quit_ small -- a screen or less of data. Load latency kills you more than the actual data transfer interval. I'd rather have, say, 1/10 the interrupts, of roughly 2-4 times the duration, than to be interrupted with great frequency. Yes, but that's of course not a problem of the format; there are as well HTML pages with only 5 lines. This can be further mitigated by browsers that render on partial load, or which allow background loading of pages (Galeon rocks for this). Sorry, I disagree. Try info --output=gcc.txt --subnodes gcc to put the whole gcc.info* files into one text file, then load it with Galeon. Although the file has only 3 lines and it's text only, loading and viewing is slow even with Galeon. Or look at the PHP docs (e.g. from http://www.php3.de/download-docs.php). They have several formats (no info); one of them being a single HTML file (4.7 MB). Even when loaded from the local harddisk, this takes ages to load in Galeon. Same for the gawk.html, mysql.html and similar large files. You might argue that I should use w3m or links to read those large HTML files - but then I would have to remember the keystrokes of these programs (i.e. I can't use my favourite browser) and I have to install/build these programs on other machines ((X)Emacs is everywhere). When I want to search a directory of HTML files, I tend to grep it first, then view the files that seem to be apropos. One better: $ less $( grep -l 'pattern' filelist ) And then you read the plain HTML source? Not very cool, frankly. A local search engine like mnogosearch, htdig or glimpse could help, of course. Is there a Debian package with already set-up configuration for one of these? I seem to remember that FreeBSD has something like this (htdig-based and with man2html and info2html). The german HTML tutorial SelfHTML 8.0 comes with a built-in JavaScript search engine (http://selfhtml.teamone.de/, but it seems to be down at the moment). It is very fast and works well. It looks like it's only available for SelfHTML at the moment, though. I think a decent search facility is a must for more in-depth documentation. If I _know_ that I want to use newwin(3), I can easily type man newwin. But if I just want to get started with curses, I am really lost after man -k curses. A hierarchical book (be it in HTML or in info format) with a Getting started topic is a lot more user-friendly in such cases. Regards... Michael
Re: man v. info
on Wed, Dec 26, 2001 at 04:31:12PM +0100, Michael Mauch ([EMAIL PROTECTED]) wrote: Karsten M. Self wrote: on Tue, Dec 25, 2001 at 06:32:31PM -0800, Craig Dickson ([EMAIL PROTECTED]) wrote: Carl Fink wrote: BTW, for HTML docs, put them all in *one* file with hyperlinks. There is no meaningful advantage to cutting it into twenty pieces, and it makes searching significantly more difficult. For locally-stored docs that's arguable. The advantage of small files comes when you have to read it across a network, especially a WAN. I'd disagree. Info nodes can be _quit_ small -- a screen or less of data. Load latency kills you more than the actual data transfer interval. I'd rather have, say, 1/10 the interrupts, of roughly 2-4 times the duration, than to be interrupted with great frequency. Yes, but that's of course not a problem of the format; there are as well HTML pages with only 5 lines. ...but that's the entire man page. Not the case with the default info presentation. This can be further mitigated by browsers that render on partial load, or which allow background loading of pages (Galeon rocks for this). Sorry, I disagree. Try info --output=gcc.txt --subnodes gcc to put the whole gcc.info* files into one text file, then load it with Galeon. Although the file has only 3 lines and it's text only, loading and viewing is slow even with Galeon. I have 2929 lines, and a 2 second load time. What packages do you have installed? The likely suspects appear to be: gcc-doc - Documentation for the GNU compilers (gcc, gobjc, g++). gcc-3.0-doc - Documentation for the GNU compilers (gcc, gobjc, g++). gcc-docs - Fake package used for a smooth upgrade. gcc-2.95-doc - Documentation for the GNU compilers (gcc, gobjc, g++). gcc272-docs - Documentation for the gcc compiler (gcc272). Or look at the PHP docs (e.g. from http://www.php3.de/download-docs.php). They have several formats (no info); one of them being a single HTML file (4.7 MB). Even when loaded from the local harddisk, this takes ages to load in Galeon. Same for the gawk.html, mysql.html and similar large files. I don't have the PHP document handy. My experience is that mawk.html loads in 13 seconds on first access, and in about 1.5 seconds on reload, accessed under dwww, as: http://ego/cgi-bin/dwww?type=manlocation=/usr/share/man/man1/gawk.1.gz http://ego/cgi-bin/dwww?type=manlocation=/usr/share/man/man1/mawk.1.gz What version of Galeon and/or hardware? This is on a PIII-600 laptop, 128 MiB, IDE harddrive. You might argue that I should use w3m w3m's loading is likely to be as slow or slower -- it doesn't display a page until it's fully loaded, unlike. or links ...which _does_ render a page _while_ it's loading. to read those large HTML files ...but in any case, both render the files in 1 second. I suspect caching is going on here. Trying another large page -- bash -- it loads in about 2 seconds. This is comperable to wait times for a freshly rendered manpage via groff. - but then I would have to remember the keystrokes of these programs (i.e. I can't use my favourite browser) Incidental not: I'd recommend you learn _one_ text mode browser. For times when you've got console-only access (no X11, or remote session, or other reasons), they're a godsend. Not that you have to give up your graphical browser (yes, Galeon rocks). and I have to install/build these programs on other machines ((X)Emacs is everywhere). When I want to search a directory of HTML files, I tend to grep it first, then view the files that seem to be apropos. One better: $ less $( grep -l 'pattern' filelist ) And then you read the plain HTML source? Not very cool, frankly. pedantic $ for file in $( list ); do w3m $file; done /pedantic A local search engine like mnogosearch, htdig or glimpse could help, of course. Is there a Debian package with already set-up configuration for one of these? I seem to remember that FreeBSD has something like this (htdig-based and with man2html and info2html). Try dwww. The german HTML tutorial SelfHTML 8.0 comes with a built-in JavaScript search engine (http://selfhtml.teamone.de/, but it seems to be down at the moment). It is very fast and works well. It looks like it's only available for SelfHTML at the moment, though. I don't care for Javascript. It doesn't work in my text browsers, among other issues, and generally fucks up my browsing in general use. The latest Moz build allows site-specific Java/Javascript enabling / disabling. I'm waiting for this to hit Galeon. I think a decent search facility is a must for more in-depth documentation. If I _know_ that I want to use newwin(3), I can easily type man newwin. But if I just want to get started with curses, I am really lost after man -k curses. A hierarchical book (be it in HTML or in info format) with a Getting
printcap(5) and other poorly formatted manpages (was Re: man v. info)
on Wed, Dec 26, 2001 at 03:38:20PM +, Colin Watson ([EMAIL PROTECTED])
wrote:
On Tue, Dec 25, 2001 at 03:02:25PM -0800, Karsten M. Self wrote:
on Tue, Dec 25, 2001 at 12:51:09PM -0600, Colin Watson
([EMAIL PROTECTED]) wrote:
Come up with examples and send patches. That'll achieve results much
faster than anything else I can think of.
Specific instructions on how to do this?
I significantly reformatted the printcap(5) man page at one point and
sent the result to the package maintainer, with no results or
response.
This is, unfortunately, just a specific case of the general problem that
a lot of non-urgent problems don't get dealt with promptly, especially
if the maintainer isn't very active.
Do use the bug tracking system. In the case of printcap(5), a bug
should be filed against the three packages that contain it (lpr,
lprng, lpr-ppd), and I can't find anything from you against any of
those packages, although I was reading quickly so I could have missed
it.
I checked myself last night, and don't see anything. My concern was
whether or not I should post my revised manpage to the bugtracking
system itself.
If you don't use the bug tracking system, then if a new maintainer
takes over the package he/she typically won't see the mail you sent,
and your work will have been wasted. Even active maintainers are more
likely to respond to things filed in the BTS, as it provides an
automatic to-do list.
(If you send me a bug by private mail that I can't deal with Right
Now, chances are I'll file it in the BTS myself, but I might not
always remember before my inbox floods onto another screen.)
If you'll look at printcap manpage, you'll find that large portions
of it are essentially pre formatted text (or the groff
equivalent), and structured for a terminal window rather wider than
80 characters.
Probably depends on which package you're looking at. The version in
lpr uses mdoc's .Bl request to construct a list, and looks OK.
lprng. I don't use groff or the man macros enough to know what the tag
is, I suspect it's .nf, for 'no format'. More likely the tbl macros
should be used.
Might be useful to go through the manpages and look for similar
issues
It should be possible to do this automatically.
for x in `find /usr/share/man -type f`; do
man -l $x | grep -q '.{81,}' echo $x
done
... or something morally equivalent.
Cool, thanks.
Peace.
--
Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/
What part of Gestalt don't you understand? Home of the brave
http://gestalt-system.sourceforge.net/Land of the free
We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire http://kmself.home.netcom.com/resume.html
pgpq30V82xrOY.pgp
Description: PGP signature
Re: printcap(5) and other poorly formatted manpages (was Re: man v. info)
Karsten M. Self writes: My concern was whether or not I should post my revised manpage to the bugtracking system itself. You should. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: printcap(5) and other poorly formatted manpages (was Re: man v. info)
On Wed, Dec 26, 2001 at 10:59:58AM -0800, Karsten M. Self wrote: on Wed, Dec 26, 2001 at 03:38:20PM +, Colin Watson ([EMAIL PROTECTED]) wrote: Do use the bug tracking system. In the case of printcap(5), a bug should be filed against the three packages that contain it (lpr, lprng, lpr-ppd), and I can't find anything from you against any of those packages, although I was reading quickly so I could have missed it. I checked myself last night, and don't see anything. My concern was whether or not I should post my revised manpage to the bugtracking system itself. Absolutely! Probably depends on which package you're looking at. The version in lpr uses mdoc's .Bl request to construct a list, and looks OK. lprng. I don't use groff or the man macros enough to know what the tag is, I suspect it's .nf, for 'no format'. More likely the tbl macros should be used. Ugh, yes, that's horrible formatting. '.nf' means no-fill mode, but it has the effect you're thinking of. Make sure you add this line to the top of the file to let man know that it should be using tbl: '\ t .nf definitely shouldn't be used for lazy attempts at tables like that. -- Colin Watson [EMAIL PROTECTED]
Re: man v. info
On Wed, Dec 26, 2001 at 10:52:33AM -0800, Karsten M. Self wrote: on Wed, Dec 26, 2001 at 04:31:12PM +0100, Michael Mauch ([EMAIL PROTECTED]) wrote: I think a decent search facility is a must for more in-depth documentation. If I _know_ that I want to use newwin(3), I can easily type man newwin. But if I just want to get started with curses, I am really lost after man -k curses. A hierarchical book (be it in HTML or in info format) with a Getting started topic is a lot more user-friendly in such cases. Most man pages have a SEE ALSO section. Accessing these through dwww links to the related manpages, access via 'man' is left as an exercise to the reader. I'd love to be able to get SEE ALSO links working in 'man -H'. Unfortunately it's not really feasible without well-defined man: URLs implemented in most browsers, which I don't see happening any time soon. A shame. -- Colin Watson [EMAIL PROTECTED]
Re: man v. info
on Wed, Dec 26, 2001 at 04:31:12PM +0100, Michael Mauch ([EMAIL PROTECTED]) wrote: Karsten M. Self wrote: ... This can be further mitigated by browsers that render on partial load, or which allow background loading of pages (Galeon rocks for this). Sorry, I disagree. Try info --output=gcc.txt --subnodes gcc to put the whole gcc.info* files into one text file, then load it with Galeon. Although the file has only 3 lines and it's text only, loading and viewing is slow even with Galeon. With gcc-2.95-doc installed, load time is ~1-2 seconds in Galeon from a text file sitting on /tmp. Previously described PIII-600MHz 128 MiB, IDE system. Galeon 1.0-2. What's your hardware? Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html pgpNAwkinrbRR.pgp Description: PGP signature
Re: printcap(5) and other poorly formatted manpages (was Re: man v. info)
on Wed, Dec 26, 2001 at 02:29:19PM -0600, Colin Watson ([EMAIL PROTECTED]) wrote: On Wed, Dec 26, 2001 at 10:59:58AM -0800, Karsten M. Self wrote: on Wed, Dec 26, 2001 at 03:38:20PM +, Colin Watson ([EMAIL PROTECTED]) wrote: Do use the bug tracking system. In the case of printcap(5), a bug should be filed against the three packages that contain it (lpr, lprng, lpr-ppd), and I can't find anything from you against any of those packages, although I was reading quickly so I could have missed it. I checked myself last night, and don't see anything. My concern was whether or not I should post my revised manpage to the bugtracking system itself. Absolutely! OK. Probably depends on which package you're looking at. The version in lpr uses mdoc's .Bl request to construct a list, and looks OK. lprng. I don't use groff or the man macros enough to know what the tag is, I suspect it's .nf, for 'no format'. More likely the tbl macros should be used. Ugh, yes, that's horrible formatting. '.nf' means no-fill mode, but it has the effect you're thinking of. Make sure you add this line to the top of the file to let man know that it should be using tbl: '\ t .nf definitely shouldn't be used for lazy attempts at tables like that. OK. I've got to rewrite the page (again) using tbl. I did something somewhat different, within groff, which works, sorta, but could be better. Anyone got a q'n'd tbl ref? There's a short section in the back of KR (or is it KP?). How does one embed tbl within a manpage? Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html pgpeP45EPX9qD.pgp Description: PGP signature
Re: man v. info
On Wed, Dec 26, 2001 at 04:31:12PM +0100, Michael Mauch wrote: | You might argue that I should use w3m or links to read those large HTML | files - but then I would have to remember the keystrokes of these | programs (i.e. I can't use my favourite browser) and I have to | install/build these programs on other machines Well, yeah, but sometimes console-only is required. In any case links does an awesome job with javadoc docs. Now if only I could use my scroll wheel with it :-) (maybe I can, I haven't really tried). | ((X)Emacs is everywhere). Hmm, $ dpkg -l \*emacs\* | grep ^ii $ I think I just found nowhere :-). -D -- If your company is not involved in something called ISO 9000 you probably have no idea what it is. If your company _is_ involved in ISO 9000 then you definitely have no idea what it is. (Scott Adams - The Dilbert principle)
Re: man v. info
Karsten M. Self wrote: on Wed, Dec 26, 2001 at 04:31:12PM +0100, Michael Mauch ([EMAIL PROTECTED]) wrote: Karsten M. Self wrote: This can be further mitigated by browsers that render on partial load, or which allow background loading of pages (Galeon rocks for this). Sorry, I disagree. Try info --output=gcc.txt --subnodes gcc to put the whole gcc.info* files into one text file, then load it with Galeon. Although the file has only 3 lines and it's text only, loading and viewing is slow even with Galeon. I have 2929 lines, and a 2 second load time. That seems to be the info-ized manpage. What packages do you have installed? The text from the info file that was installed by apt-get install gcc-2.95-doc has 31299 lines. Pasted from your other mail: With gcc-2.95-doc installed, load time is ~1-2 seconds in Galeon from a text file sitting on /tmp. Wow, that's fast. Is that the time time until it starts displaying the first page(s) or is it the time until the whole page is loaded (CPU usage goes down to normal, mouse cursor is normal again)? This takes more than 30 seconds here. Oh, wait a moment - Galeon 1.0 from the Debian system really is a lot faster (2 seconds for the whole file). So maybe something went wrong with my Galeon-0.12.7 build here (built from sources on something that once was a SuSE-6.1). I'm sorry, this was my own fault then. Previously described PIII-600MHz 128 MiB, IDE system. Galeon 1.0-2. What's your hardware? Athlon 700, 384 MiB. I don't have the PHP document handy. My experience is that mawk.html loads in 13 seconds on first access, and in about 1.5 seconds on reload, accessed under dwww, as: http://ego/cgi-bin/dwww?type=manlocation=/usr/share/man/man1/gawk.1.gz http://ego/cgi-bin/dwww?type=manlocation=/usr/share/man/man1/mawk.1.gz Um, the gawk info file is a whole book (it's also available on a dead tree), that's by far more exhaustive than the HTML-ized man page. The gawk.html as shipped with the gawk-3.1.0 sources has 32483 lines, 1.6 MB - and it takes more than 20 seconds to load (on the good Galeon 1.0 from Debian). But ok, once it is loaded, it's ok; even searching is fast enough. You might argue that I should use w3m w3m's loading is likely to be as slow or slower -- it doesn't display a page until it's fully loaded, unlike. or links ...which _does_ render a page _while_ it's loading. to read those large HTML files ...but in any case, both render the files in 1 second. I suspect caching is going on here. Trying another large page -- bash -- it loads in about 2 seconds. This is comperable to wait times for a freshly rendered manpage via groff. Yes, ok. Links _is_ fast. - but then I would have to remember the keystrokes of these programs (i.e. I can't use my favourite browser) Incidental not: I'd recommend you learn _one_ text mode browser. Um, yes - I already learned lynx a while ago. Alas that's very slow for large files. So I learn another text browser, no problem. But why can't you learn the (p)info keystrokes, then? ;-) But when I'm at work, I'm again stuck with Netscape 4.x, because the admins won't install anything other. I don't have an info browser there, but I do have (X)Emacs, and so I can happily read info files (as long as they are not HTML only, like it's the case with the PHP manual). For times when you've got console-only access (no X11, or remote session, or other reasons), they're a godsend. Yes, of course - and I can navigate with the keyboard. When I want to search a directory of HTML files, I tend to grep it first, then view the files that seem to be apropos. One better: $ less $( grep -l 'pattern' filelist ) And then you read the plain HTML source? Not very cool, frankly. pedantic $ for file in $( list ); do w3m $file; done /pedantic And then I type my search string into a dozen of w3m instances? Still not convinced. A local search engine like mnogosearch, htdig or glimpse could help, of course. Is there a Debian package with already set-up configuration for one of these? I seem to remember that FreeBSD has something like this (htdig-based and with man2html and info2html). Try dwww. Thank you, that's great! And with info2www the info books are there, too. But then: how can I search for e.g. assembler in the gawk book? The german HTML tutorial SelfHTML 8.0 comes with a built-in JavaScript search engine (http://selfhtml.teamone.de/, but it seems to be down at the moment). It is very fast and works well. It looks like it's only available for SelfHTML at the moment, though. I don't care for Javascript. Normally I don't, neither - but this example of a self-contained search engine made me wonder if JavaScript really is always senseless bloat. It doesn't work in my text browsers, among other issues, and generally fucks up my browsing in general use. The latest Moz build
what happened to galeon (was Re: man v. info)
On Thu, Dec 27, 2001 at 02:14:36AM +0100, Michael Mauch wrote: | Galeon 1.0 from the Debian system really is a lot faster (2 seconds | for the whole file). So maybe something went wrong with my | Galeon-0.12.7 build here (built from sources on something that once | was a SuSE-6.1). Ok, so galeon is at 1.0 (1.0-2 really) now. I just tried to install it, but it says it needs a newer mozilla-browser than is in woody but an older one than is in sid. Why is that? Why does it conflict with mozilla-browser = 0.9.7? I would like to move up from 0.12.4-0.1. -D -- Bugs come in through open windows. Keep Windows shut!
Re: man v. info
On Tue, Dec 25, 2001 at 05:24:26PM +0100, Imre Vida wrote: The lack of manpages, and outdated manpages are frustrating. And what Karsten brought up is also a nice idea: to have examples in man pages. There are some manpages with examples but most of them are without although they are really helpful. It would be nice to know how other people think about this and if there is sufficient interest to also talk about what should/could be done to change this. Come up with examples and send patches. That'll achieve results much faster than anything else I can think of. -- Colin Watson [EMAIL PROTECTED]
Re: man v. info
Imre == Imre Vida [EMAIL PROTECTED] writes: Imre As far as info is concerned, i fully agree with Karsten. It Imre doesn't work intuitively for me either; i just get lost in Imre the maze of links and 3 sentence pages I hate it for Imre this. It's not man versus info - some variety of documentation format should be tolerable. And I, personally don't dislike info ... Imre The lack of manpages, and outdated manpages are frustrating. Imre And what Karsten brought up is also a nice idea: to have Imre examples in man pages. There are some manpages with examples Imre but most of them are without although they are really Imre helpful. That's a good point. Having examples in manuals should be nearly mandatory. It speeds up understanding and usability a lot. Help out with them ... MH -- (Dr.) Michael Hummel mailto: [EMAIL PROTECTED] || [EMAIL PROTECTED] -- fprint = F24D EAC6 E3D7 372C 9122 D510 EB24 01CA 0B56 B518 id: 1024D/0B56B518 key: http://www.seitung.net/key pgpvzHTbESNbv.pgp Description: PGP signature
Re: man v. info
* Imre Vida ([EMAIL PROTECTED]) spake thusly: hi, i just read the (sub)thread above on man v. info and i thought it is much more important than to have it hidden in there. So i thought i try to pick it up again. The major sources of help/information for me are the apropos, the -h/--help options and the man pages. These are fast and efficient means to find what i want most of the time. As far as info is concerned, i fully agree with Karsten. It doesn't work intuitively for me either; i just get lost in the maze of links and 3 sentence pages I hate it for this. The lack of manpages, and outdated manpages are frustrating. And what Karsten brought up is also a nice idea: to have examples in man pages. There are some manpages with examples but most of them are without although they are really helpful. mode=my $.02 On IRIX, for one example, many man pages do have EXAMPLES section; they had it for ages. Writing a decent manpage is obviously way too hard. Let's invent a maze of twisty little hyperlinks, all alike, instead, and call it info./mode Dima -- I have not been able to think of any way of describing Perl to [person] Hello, blind man? This is color. -- DPM
Re: man v. info
on Tue, Dec 25, 2001 at 12:51:09PM -0600, Colin Watson ([EMAIL PROTECTED]) wrote: On Tue, Dec 25, 2001 at 05:24:26PM +0100, Imre Vida wrote: The lack of manpages, and outdated manpages are frustrating. And what Karsten brought up is also a nice idea: to have examples in man pages. There are some manpages with examples but most of them are without although they are really helpful. It would be nice to know how other people think about this and if there is sufficient interest to also talk about what should/could be done to change this. Come up with examples and send patches. That'll achieve results much faster than anything else I can think of. Specific instructions on how to do this? I significantly reformatted the printcap(5) man page at one point and sent the result to the package maintainer, with no results or response. If you'll look at printcap manpage, you'll find that large portions of it are essentially pre formatted text (or the groff equivalent), and structured for a terminal window rather wider than 80 characters. Might be useful to go through the manpages and look for similar issues Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html pgpQwUfXNbeXM.pgp Description: PGP signature
RE: man v. info
On 25-Dec-01 Imre Vida wrote:
[snip]
The major sources of help/information for me are
the apropos, the -h/--help options and the man pages.
These are fast and efficient means to find what i want
most of the time.
As far as info is concerned, i fully agree with Karsten.
It doesn't work intuitively for me either; i just get
lost in the maze of links and 3 sentence pages
I hate it for this.
The lack of manpages, and outdated manpages are frustrating.
And what Karsten brought up is also a nice idea:
to have examples in man pages. There are some manpages with examples
but most of them are without although they are really helpful.
[snip]
I really agree with this. I find 'info' very frustrating;
the most useful way I have found to use it is simply to
scroll through as if it was one continous document, and
at that stage it might as well be in 'man' format anyway.
If you reall want to search through a 'man' page,
a simple way is
man whatever | col -b | less
('col -b' strips out any highlighting/underlining,
e.g. 'b^Hbo^Hol^Hld^Hd' and allows the keywords
to be searched for like all the others).
As to what to do about it, I can only suggest
reinstate the man pages in full. I know it's
not 'kosher' to disagreee with the GNU info
policy, but I think that those who do disagree
should say so. After all, it'a a Free and Open
World, isn't it?
Happy Christmas and New Year, and best wishes to all,
Ted.
E-Mail: (Ted Harding) [EMAIL PROTECTED]
Fax-to-email: +44 (0)870 167 1972
Date: 25-Dec-01 Time: 17:00:36
-- XFMail --
Re: man v. info
On Tue, Dec 25, 2001 at 05:00:36PM -, Ted Harding wrote: As to what to do about it, I can only suggest reinstate the man pages in full. I know it's not 'kosher' to disagreee with the GNU info policy, but I think that those who do disagree should say so. After all, it'a a Free and Open World, isn't it? I despise info. Use man as a base, and anything more elaborate that actually *requires* hyperlinking, use HTML. BTW, for HTML docs, put them all in *one* file with hyperlinks. There is no meaningful advantage to cutting it into twenty pieces, and it makes searching significantly more difficult. -- Carl Fink [EMAIL PROTECTED] Manager, Dueling Modems Computer Forum http://dm.net
Re: man v. info
Carl Fink wrote: BTW, for HTML docs, put them all in *one* file with hyperlinks. There is no meaningful advantage to cutting it into twenty pieces, and it makes searching significantly more difficult. For locally-stored docs that's arguable. The advantage of small files comes when you have to read it across a network, especially a WAN. When I want to search a directory of HTML files, I tend to grep it first, then view the files that seem to be apropos. Craig, enjoying the aftereffects of a superb Cabernet Sauvignon (Napa Valley, Clos du Val, 1994)
Re: man v. info
on Tue, Dec 25, 2001 at 06:32:31PM -0800, Craig Dickson ([EMAIL PROTECTED]) wrote: Carl Fink wrote: BTW, for HTML docs, put them all in *one* file with hyperlinks. There is no meaningful advantage to cutting it into twenty pieces, and it makes searching significantly more difficult. For locally-stored docs that's arguable. The advantage of small files comes when you have to read it across a network, especially a WAN. I'd disagree. Info nodes can be _quit_ small -- a screen or less of data. Load latency kills you more than the actual data transfer interval. I'd rather have, say, 1/10 the interrupts, of roughly 2-4 times the duration, than to be interrupted with great frequency. This can be further mitigated by browsers that render on partial load, or which allow background loading of pages (Galeon rocks for this). When I want to search a directory of HTML files, I tend to grep it first, then view the files that seem to be apropos. One better: $ less $( grep -l 'pattern' filelist ) Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html pgpwD7CXvdzt9.pgp Description: PGP signature
RE: man v. info
On Tue, 25 Dec 2001 [EMAIL PROTECTED] wrote: I really agree with this. I find 'info' very frustrating; [...] As to what to do about it, I can only suggest reinstate the man pages in full. I know it's not 'kosher' to disagreee with the GNU info policy, but I think that those who do disagree should say so. After all, it'a a Free and Open World, isn't it? Yup, info pretty much blows. It's very counterintuitive and completely unapproachable to the uninitiated. The only real decent interface for info is info2html, and it *still* blows because the only people who use info are GNU and nobody else... -- Baloo
Re: man v. info (was Re: mandb gets stuck!)
On Sun, Sep 02, 2001 at 11:54:09PM -0400, Brian Nelson wrote: I also agree. I think what bothers me most about info pages is that they often read like books. They're usually arranged in a format resembling chapters covering each topic in thorough detail. This is fine if I want to read a book about Emacs, for example, but sucks if I just want a quick reference for a command line switch or something. I don't know ... I find the CVS and grub info pages to be infinitely more informative (groan) than the manpages. OTOH it's only been the past two or three years that I've been able to navigate in an info browser, and I've been using linux for some time now :) -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpCam1uO3eKB.pgp Description: PGP signature
Re: man v. info (was Re: mandb gets stuck!)
Brian Nelson wrote: I also agree. I think what bothers me most about info pages is that they often read like books. Not suprising, they often *are* books. I have a book on my shelf that has about a 100% correspondence to the gdb info page. Though the gdb info page lacks RPM's autograph.. -- see shy jo
Re: man v. info (was Re: mandb gets stuck!)
On Sun, Sep 02, 2001 at 03:13:10PM -0700, Karsten M. Self wrote: on Sun, Sep 02, 2001 at 01:44:45PM +0200, Cliff Sarginson ([EMAIL PROTECTED]) wrote: On Sun, Sep 02, 2001 at 11:49:11AM +0100, Colin Watson wrote: On Sat, Sep 01, 2001 at 10:31:47PM +0800, Rino Mardo wrote: regretful snip I agree with every word you say! regards Cliff
Re: man v. info (was Re: mandb gets stuck!)
wow. ever thought of getting into law practice? :-) i think i touched on a very touchy issue here. i'll just go find a simple project for my python. thanks for all the replies guys! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: man v. info (was Re: mandb gets stuck!)
On Sun, Sep 02, 2001 at 03:13:10PM -0700, Karsten M. Self wrote: Personally, I'd strongly recommend that the GNU project revisit the issue of info pages altogether. They're not popular, they don't adequately replace man pages, and there is a far more successful and ubiquitous hypertext model (HTML) in use now. Moreover, the standard info navigation keybindings (and even the simplified bindings offered by tools such as pinfo) are neither ubiquitous, corrospondent to other SW tools (emacs excepted), nor self evident. Yep. Too many formats -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki [EMAIL PROTECTED], GnuPG-key: 1024D/D5DE453D + + My debian quick-reference, http://www.aokiconsulting.com/quick/+
Re: man v. info (was Re: mandb gets stuck!)
Karsten M. Self kmself@ix.netcom.com writes: The problem is that this is often specifically what is *not* sought by those who are looking for manpages. What's wanted is a short, concise, but illustrative reference providing: - A functional description of the command. - A synopsis of all options and/or switches for the command. - EXAMPLES!!! Examples of (typical) usage are essential. - Additional sections: FILES, SEE ALSO, BUGS, and AUTHOR, typically. There is a utility to convert the man page equivalent portion of a typical info page to something resembling manpage format. Personally, I'd strongly recommend that the GNU project revisit the issue of info pages altogether. They're not popular, they don't adequately replace man pages, and there is a far more successful and ubiquitous hypertext model (HTML) in use now. Moreover, the standard info navigation keybindings (and even the simplified bindings offered by tools such as pinfo) are neither ubiquitous, corrospondent to other SW tools (emacs excepted), nor self evident. I also agree. I think what bothers me most about info pages is that they often read like books. They're usually arranged in a format resembling chapters covering each topic in thorough detail. This is fine if I want to read a book about Emacs, for example, but sucks if I just want a quick reference for a command line switch or something. It seems to me that GNU has nothing to lose and plenty to gain by maintaining man pages. Of course man pages can't replace a true documentation system like info, but a good man page is extremely useful. Nice post Karsten. -- Brian Nelson [EMAIL PROTECTED]
