Bug 153993

Summary:	Kate Search in files opens already open files
Product:	[Applications] kate	Reporter:	Olle Bergkvist <olle.bergkvist>
Component:	general	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:

Description Olle Bergkvist 2007-12-13 20:50:06 UTC

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.

Comment 1 Olle Bergkvist 2007-12-13 21:29:38 UTC

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;

Comment 2 Thomas Friedrichsmeier 2007-12-14 00:20:26 UTC

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 ***

Comment 3 Anders Lund 2007-12-14 21:00:02 UTC

I didn't write the plugin, but it should use KURL if it doesn't, really ;)

Comment 4 Dominik Haumann 2007-12-14 21:09:38 UTC

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.

Comment 5 Anders Lund 2007-12-14 21:47:07 UTC

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 :)