This is an automatically generated e-mail. To reply, visit:

On October 5th, 2012, 8:27 p.m., Michel Ludwig wrote:

Ok, this looks very good already. I just have have a few suggestions for improving the patch even more.

Sorry, but I don't see how 'cleanStruct()' could help avoid any race conditions. Could you elaborate on that?

On October 5th, 2012, 10:17 p.m., Eugene Shalygin wrote:

As well as I remember, I came to understanding while I was analyzing why do I see absence of the master documents when I have many projects openend. What happened is that same info object has been scheduled for parcing twice or more. I do not remember, unfortunately, what was leading to that. Some of the projects are sharing the same files, if that can play role. Anyway, in that case the second scheduling cleans up structure that was built in result of the first parsing, and this cleaned object is used for project tree building or something like that. And I saw incorrect project trees, empty bibliography completion lists and so on. Then I moved cleaning into the install* methods, and that, as I thought, should lead to cleaning in the same thread that builds project tree, and the problem disappeared. And I thought that it is more logical to clean structure right before populating with the new one. So I would leave it even if double parsing will not (and shall not) happen.

On October 6th, 2012, 8:37 a.m., Michel Ludwig wrote:

Hhmmm, I think if this problem still occurs it must have been caused by something else as all the code in TextInfo and the structure view is executed in the GUI thread, which means that no race conditions can occur (the output parser is passed to the event loop of the GUI thread using a blocking signal/slot connection, see 'KileDocument::Manager::handleParsingComplete'

So, at the places where 'cleanStruct' was called it had no effect as it was followed immediately by 'operator=' and everything GUI-related runs in the GUI thread only. 

On October 6th, 2012, 1:31 p.m., Eugene Shalygin wrote:

I disagree. When we call m_ki->structureWidget()->update(itemInfo, true) from projectOpenItem(), it was cleaning structure  immediately, and then was scheduling the parsing of the item. And if parsing  queue contains many items, result of parsing of some other item uses clean structure of this item. And this happens if the same items is scheduled for parcing twice.

On October 6th, 2012, 3:46 p.m., Michel Ludwig wrote:

Ok, but that's a different issue. Your fix was right for the reason that you had emptied 'Info::cleanStruct()'.

On October 6th, 2012, 3:56 p.m., Eugene Shalygin wrote:

Pardon me, but cleanStruct() is what I've added. Before this code was in updateStruct() and causing above described problem. So, despite I did not understand your last comment completely, I think that main iea was that we leave clearStruct()?
No, that's exactly the point. It is unnecessary to clear any information before the parsing takes place.

On October 5th, 2012, 8:27 p.m., Michel Ludwig wrote:

src/documentinfo.cpp (Diff revision 4)
const long* TextInfo::getStatistics(KTextEditor::View *view)
		return KUrl();
		return Info::url();
I don't know how much work this will be but could you try to remove the 'Info::url()' method completely? It just causes too many problems, for example when files are renamed.

It should be sufficient to use 'urlFor' from the doc manager instead.

On October 5th, 2012, 10:17 p.m., Eugene Shalygin wrote:

Well, I've tried. Indeed, it leads to many changes. Some of them are trivial, some are not. For example, Info::lastModifiedFile() uses url(). Where can I get doc manger from in that function?

Perhaps, it would be better if I remove introduced by patch changes in Info constructors, and switch to the using of doc manager in the parser thread, then you accept this patch ;) and further clean up can be done independently?

On October 6th, 2012, 8:36 a.m., Michel Ludwig wrote:

Ok, let's do it this way.

On October 6th, 2012, 1:31 p.m., Eugene Shalygin wrote:

Ups... Manager::urlFor(TextInfo* textInfo) calls Manager::itemFor(Info *docinfo, KileProject *project /*=0*/) which in turn calls Manager::itemFor(const KUrl &url, KileProject *project /*=0L*/) with docinfo->url()

Thus, by removing url from Info we destroy this chain.

On October 6th, 2012, 3:46 p.m., Michel Ludwig wrote:

Ok, let's wait with this for now then. The whole thing is a mess anyway and needs to be cleaned up!

Could you just remove the additional URL parameter that you have added from the patch?

On October 6th, 2012, 3:56 p.m., Eugene Shalygin wrote:

Sorry, I can not :) If the parser does not know the url, it can not deliver the results to a proper destination. That is why I've started all this work with adding url to Info objects, because without that, the url exists only for Infos with documents. So the idea was to provide information to parser without loading KateDocument. This includes url and file contents.
Calling 'KileDocument::Manager::urlFor' in 'DocumentParserThread::addDocument' should now work for project items as well.

On October 5th, 2012, 8:27 p.m., Michel Ludwig wrote:

src/kiledocmanager.cpp (Diff revision 4)
void Manager::projectOpenItem(KileProjectItem *item, bool openProjectItemViews)
	//oops, doc apparently was open while the project settings wants it closed, don't trash it, update openState instead
It looks like this is still needed somewhere...

On October 5th, 2012, 10:17 p.m., Eugene Shalygin wrote:

Can not understand how that is possible: we create view now only if item->isOpen() == true, then why should we check it again? The same applies to the trashDoc() call, doesn't it?

On October 6th, 2012, 3:56 p.m., Eugene Shalygin wrote:

Any comment about this?
That seems fine.

- Michel

On October 5th, 2012, 5:33 p.m., Eugene Shalygin wrote:

Review request for Kile.
By Eugene Shalygin.

Updated Oct. 5, 2012, 5:33 p.m.


Kile shedules parsing of all projet items when it opens a project. But because Manager::m_projects does not contain currently loading project at that time, Manager can not resolve projet items to documents and parsing does not happen.

This patch adds curently parsing project to m_projects collection before invoking projectOpenItem() and thus parsing goes. Then we crate Info* object for each project item (if it does not exist) and sneding it to parsing.
In the next step, in Manager::handleParsingComplete(), TextInfo object is determined via opened documents list, as I understood. To install results for all project items, the patch adds a second branch that determines TextInfo object via KileProjectItem::getInfo() and the item is accessed via Manager::itemFor() (that is why project must be added to m_projects before parsing)

Also the patch changes Info* classes in a way that makes possible to parse files without loading them into KatePart, i.e. without Document object creation. This speeds up project loading. At least on my machine before most of the time was spent in spell checker initialization. We do not need a spell checker for parsing :). To parse a file we use a tiny helper function that loads file contents (getFileContents() in anonymous namespace, parserthread.cpp).

Then it tries to fix a race between parsing and cleaning of Info object by separating the cleaning code into cleanInfo() method and calling it from installParserResults()

With these changes completion works for all bib items and labels in project even if these files are not opened.


Manual testing


  • src/documentinfo.h (16d6e49)
  • src/documentinfo.cpp (923d099)
  • src/kiledocmanager.h (5edc14e)
  • src/kiledocmanager.cpp (aa8a1d8)
  • src/parser/parserthread.cpp (4e80c41)

View Diff