hello, it would be very helpful if the structured documentation on http://devmanual.gentoo.org/ can be viewed also as one single html file. searching in such structured doc is very annoying. thanks. (btw. href to bugzilla on intro page is wrong.) Reproducible: Always
If you have the skills the sources can be found via: http://anonsvn.gentoo.org/
Good idea, but I don't think any of us have the necessary skills or time at this point to do anything about this. We'll definitely revisit it later though.
*** Bug 215236 has been marked as a duplicate of this bug. ***
*** Bug 281157 has been marked as a duplicate of this bug. ***
*** Bug 320833 has been marked as a duplicate of this bug. ***
<ping!> I was gonna file the same bug (enhancement request), and found out that one. When I take the time to carefully RTFM, I like to do so away from the computer (printed or ereader), so a single-page helps to do that. So… that was already six years ago? I think even the website's framework changed since then. For instance, "Comment 1" points to the location of the source… which does not exist anymore. What would be involved to perform that? Does someone finally know how to get it implemented? If not, well, I understand, as I'm sorry to tell you I don't know that either…
Something like this could be useful perhaps, courtesy of NP-Hardass: http://blog.siphos.be/2013/04/transforming-guidexml-to-docbook/
would be nice :)
I couldn't invest much time in this but with a short time of hacking I got this: http://dev.gentoo.org/~gokturk/devmanual/bug185477/text.pdf. It should be fairly straightforward for someone who knows more xsl than I do :)
I this still an issue, now that we have search functionality?
(In reply to Ulrich Müller from comment #10) > I this still an issue, now that we have search functionality? This would still be nice for printing, and the javascript search is really hacky. Ctrl-f is better in every way, so I'd much rather have this than that. (Or both, if there's any reason to keep the JS search around too.)
(In reply to Michael Orlitzky from comment #11) > (In reply to Ulrich Müller from comment #10) > > I this still an issue, now that we have search functionality? > > This would still be nice for printing, and the javascript search is really > hacky. Ctrl-f is better in every way, so I'd much rather have this than > that. (Or both, if there's any reason to keep the JS search around too.) JS search does stemming on search terms. So if you search for "package", it'll stem it down to "packag" and match things like "package", "packaging" etc. Also, multi-term search in JS would perform better than your ctrl-f.
(In reply to Göktürk Yüksek from comment #12) > > JS search does stemming on search terms. So if you search for "package", > it'll stem it down to "packag" and match things like "package", "packaging" > etc. Also, multi-term search in JS would perform better than your ctrl-f. If the JS search returns results that I didn't search for, that's another reason to prefer ctrl-f =P In this case, as soon as I type the "packag" part of "packaging", firefox will do exactly the same thing. If I type the rest of the word, then clearly I don't want things that only contain "packag". The best user interface is the one that does what I asked it to.
(In reply to Michael Orlitzky from comment #13) > (In reply to Göktürk Yüksek from comment #12) > > > > JS search does stemming on search terms. So if you search for "package", > > it'll stem it down to "packag" and match things like "package", "packaging" > > etc. Also, multi-term search in JS would perform better than your ctrl-f. > > If the JS search returns results that I didn't search for, that's another > reason to prefer ctrl-f =P > > In this case, as soon as I type the "packag" part of "packaging", firefox > will do exactly the same thing. If I type the rest of the word, then clearly > I don't want things that only contain "packag". The best user interface is > the one that does what I asked it to. I provided a very simple stemming example. The stemming is decided based on the overall content, so it's a bit smarter than you think. If we're gonna follow that line of arguing, I can also ctrl-f the search results to look for an exact match :P Your argument is rather personal however. When I type package, I do want things that contain package, packaged, packaging etc. I like the fact that I search for "remove ebuilds" and I get a hit for "removing an ebuild". You on the other hand want an exact match. We can see if we are able to facilitate searches without stemming. The point is that ctrl-f doesn't achieve what I want, but I can achieve what you want with a bit more programming. I don't see much value arguing that ctrl-f is superior to a search mechanism though. Maybe what lunr.js does is overkill to your search needs but clearly it is more feature-rich than ctrl-f.
(In reply to Göktürk Yüksek from comment #14) > > Your argument is rather personal however. Sure, all I'm saying is that personally I prefer ctrl-f and no javascript. And when I was still learning this stuff, a printable devmanual would have been awesome.
