Summary: | Certain manpages are not displayed completely | ||
---|---|---|---|
Product: | [Unmaintained] kio | Reporter: | Andreas Schnaiter <spam> |
Component: | man | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | nicolasg, prigault |
Priority: | NOR | ||
Version: | 3.5 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Andreas Schnaiter
2005-12-09 00:52:41 UTC
I cannot reproduce but perhaps I have not the same wget version. What is the output of wget --version As for the general problem, yes, the man: KIO slave has arrived to its limit. So for complext man pages, especially those that expect groff features, cannot be displaed correctly. Have a nice day! Well ... I extra asked around in #kde to see if my build was borked ... two people answered and had the same problem ... The very same manpage worked on 3.4.2 If you could only remember which other manpages were also not working *g* wget --version GNU Wget 1.10.2 Copyright (C) 2005 Free Software Foundation, Inc. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Originally written by Hrvoje Niksic <hniksic@xemacs.org>. Have a nice day also =) I can confirm. I have download the wget tarball and built the man page. man:wget stops working correctly at the URL having a + sign in the description of --restrict-file-names=windows (then it indeed never ends). Making the man KIO slave not handling + in a HTTP URL makes it work. However I do not understand why such a little difference makes such a big effect. Have a nice day! SVN commit 487411 by goutte: Fix off-by-one when trying to find URLs in the text. CCBUG:117971 M +4 -4 man2html.cpp --- branches/KDE/3.5/kdebase/kioslave/man/man2html.cpp #487410:487411 @@ -935,12 +935,12 @@ break; } nr=0; - if (idtest[0] && idtest[0]<c) idtest[0]=strstr(c+1,"://"); - if (idtest[1] && idtest[1]<c) idtest[1]=strchr(c+1,'@'); + if (idtest[0] && idtest[0]<=c) idtest[0]=strstr(c+1,"://"); + if (idtest[1] && idtest[1]<=c) idtest[1]=strchr(c+1,'@'); if (idtest[2] && idtest[2]<c) idtest[2]=strstr(c,"www."); if (idtest[3] && idtest[3]<c) idtest[3]=strstr(c,"ftp."); - if (idtest[4] && idtest[4]<c) idtest[4]=strchr(c+1,'('); - if (idtest[5] && idtest[5]<c) idtest[5]=strstr(c+1,".h>"); + if (idtest[4] && idtest[4]<=c) idtest[4]=strchr(c+1,'('); + if (idtest[5] && idtest[5]<=c) idtest[5]=strstr(c+1,".h>"); for (i=0; i<numtests; i++) nr += (idtest[i]!=NULL); } output_real(c); The major bug in the wget(1) man page is not fixed. There seems to be however some details left: --cut-dirs: there are some extra empty lines --html-extensions: the is a \. instead of a simple . (before the HTML regexp). Have a nice day! I can confirm this behaviour. Calling the 'wget' manpage from 'man:/' ioslave still consumes 100% CPU time after applying the patch. Regards, Ruben On Monday 12 December 2005 15:46, Ruben Jenster wrote: (...) > ------- I can confirm this behaviour. > Calling the 'wget' manpage from 'man:/' ioslave still consumes 100% CPU > time after applying the patch. Sorry, I meant the contrary. (It was "now" not "not".) I meant that the major was fixed and it remained only details. However you seems tzo tell that you still get a problem. :-( > > Regards, > Ruben *** Bug 118648 has been marked as a duplicate of this bug. *** > Calling the 'wget' manpage from 'man:/' ioslave still consumes 100% CPU
> time after applying the patch.
This is not what I see. Applying the patch fixes the problem completely in my case.
Regards,
Philippe
Confirmed fixed again with KDE3.5.6, and no input on the problem for over a year. This bug is fixed and should be closed IMO. Consider it fixed, then. |