Version: 2.5.6 (using KDE 3.5.6, Kubuntu (feisty) 4:3.5.6-0ubuntu14.1) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.20-16-generic Hello. It is possible to by mistake make Kate open an already open file again twice using the Search in files function. That may cause conflicts between the two tabs who edit the same file. Here's how this bug happened to me: 1. Open a few documents from the same folder. 2. Open Search for files. 3. Clear the Folder: field. 4. Type a slash character in this field. Using the file name completion pop-up, choose the top level directory which holds the files you're editing. Continue choosing folders in the pop-up until you are in the documents' folder. Now, the Folder: field holds a path ending with a slash character. This can be done by hand as well. 5. DO A SEARCH. 6. Double-click in the search result on a search hit in an already opened document. 7. Now, Kate will open the file, even though it's already opened. The new node in the Documents panel will have the mouse-over-hint file:///home/username/dir//foo.c while the already open one has file:///home/username/dir/foo.c As you can see, the trailing slash character from the Folder field, has moved to the file URL, which now holds two slashes. So i suspect two bugs here, one which copies the trailing slash, and one which opens a file with a weird URL.
I can't program in C++, just C, but i can read and maybe understand the code. A "slash eliminator" could be implemented in in the file kdebase-3.5.6/kate/app/kategrepdialog.cpp in the function void GrepTool::itemSelected(const QString& item) I think that would be the most straightforward. Maybe the following code snippet i created in my mind is just nonsense. Feel free to ignore it. Line 296: Dir.rightfilename = m_workingDir + QDir::separator() + filename; could be replaced with if( strcmp(m_workingDir.right(1), "/") ) Dir.rightfilename = m_workingDir + filename; else Dir.rightfilename = m_workingDir + QDir::separator() + filename;
Thanks for your detailed report. However, this is just one instantiation of a more general problem (bug #142596). To keep the bug-database managable, I'm marking this report as a duplicate of that. Concerning a fix, url normalization should probably be done at a more central place as well, as this does not only affect the find in file tool. *** This bug has been marked as a duplicate of 142596 ***
I didn't write the plugin, but it should use KURL if it doesn't, really ;)
It's not a bug in the plugin, and it's not about KUrl itself. This is a bug in katepart itself. katepart should look whether the file (in normalized mode, see KUrl::cleanPath) is already opened.
On Friday 14 December 2007, Dominik Haumann wrote: > katepart should look whether the file (in normalized mode, see > KUrl::cleanPath) is already opened. Right, and that can't be hard to fix :)