GNOME Bugzilla – Bug 535020
beagle translate '#' in Docbook entry to %23, which cause yelp searching not work.
Last modified: 2008-06-16 02:24:04 UTC
Please describe the problem: In beagle/Filter FilterDocbook.cs, Indexable indexable = new Indexable (UriFu.PathToFileUri (String.Format ("{0}#{1}", base_path, entry.Id))); this will make # to be tranlated to '%23'. See also https://bugzilla.novell.com/show_bug.cgi?id=372186 Steps to reproduce: 1. Started Help browser from main menu 2. ran a search for evolution and clicking on the following links pops up an error dialog. Actual results: * "Command Line Options from Novell Evolution 2.6 User Guide" The Uniform Resource Identifier ‘file:///opt/gnome/share/gnome/help/evolution-2.6/C/evolution-2.6.xml%23bsekq8r’ is invalid or does not point to an actual file. * IMAP Receiving Options from Novell Evolution 2.6 User Guide The Uniform Resource Identifier ‘file:///opt/gnome/share/gnome/help/evolution-2.6/C/evolution-2.6.xml%23bstggh0’ is invalid or does not point to an actual file. * Using Search Folders from Novell Evolution 2.6 User Guide The Uniform Resource Identifier ‘file:///opt/gnome/share/gnome/help/evolution-2.6/C/evolution-2.6.xml%23usage-mail-organize-vfolders’ is invalid or does not point to an actual file. - In the main/root Help Topics window when I tried some of links and I got these errors. Expected results: Open corresponding help page. Does this happen every time? Yes. Other information:
Created attachment 111574 [details] [review] proposed patch for 0.2.18 to fix this bug.
First of all, this is against 0.2.18 as you mentioned. Recent yelp contains a new searching code and it requires beagle-0.3.x. So there is some chance that recent yelp with beagle-0.3.x works ok (beagle code for the docbook didnt change from 0.2.18 to 0.3.x but yelp code to search using beagle changed several months ago). Secondly, beagle always returns the URI in the escaped form i.e. # replaced by %23, ' ' replaced by %20 etc. So if recent yelp is having the same problems, then the uri should be first unescaped and then used. If you can confirm that recent yelp versions are having the same problem, then we can move the bug to yelp and ask it to get fixed there. Otherwise it is NOTABUG.
Thanks, I test the beagle-0.3.7-11. When I run "beagle-query file-roller", the following url has been returned: ... file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml%23file-roller-select-files file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml%23file-roller-open file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml%23file-roller-pattern file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml%23file-roller-working ... But the above %23 ('#') is validated in url, and should not be escaped. Because the '#' in the url indicates anchor in destination xml file. The "file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml%23file-roller-working" means a file named "file-roller.xml#file-roller-working" in the filesystem. The "file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml#file-roller-working" means a file named "file-roller.xml" and go to the anchor "file-roller-working". In the newest yelp search, it seems to strips all the DocbookEntry, because the file "file-roller.xml#file-roller-working" doesn't exists due to the improper url.
> The > "file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml%23file-roller-working" > means a file named "file-roller.xml#file-roller-working" in the filesystem. > > The > "file:///usr/share/gnome/help-bundle/file-roller/C/file-roller.xml#file-roller-working" > means a file named "file-roller.xml" and go to the anchor > "file-roller-working". Ahhh yes. I see your point. Unfortunately this faintly reminds me of a technical limitation in beagle due to which we sometimes cannot use '#' unescaped in URIs. I will try to workaround that problem; if I cannot fix this in beagle then I will think of a way to fix it in yelp instead. Thanks for bringing this into notice.
I checked in a fix in svn r4781. The required API changes were committed in r4777. The URIs should be correctly generated now; the '#' fragment separators will not be escaped.
Thanks.