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

On October 6th, 2012, 9:27 p.m., Michel Ludwig wrote:

Do you want to work on error handling as well now? I think it would be good if errors that occur during the loading are not immediately reported to the user but only all the projects have been opened. Then, there could be some dialog popping up listing the files that couldn't have been opened. What do you think?

(and exception are not really used in KDE/Qt code ;))

On October 6th, 2012, 10:06 p.m., Eugene Shalygin wrote:

Happy to see that this changes finally landed! Thank you so much for all the help and changes to the code!

Good to see that even without RAII/exceptions one can use tricks like the one for local files in NetAccess::download() and turn Manager::loadTextURLContents() into a readable function. Just as a little help for a reader it would be better to move the comment to the line with actual action and to mention the trick in download() (as their authors have used so non self-describing name), please?

However, I do not see any harm from exception in an application like Kile: it is hard to find a compiler that does not support them, we a not a library and thus do not have users those must use exceptions also, and we know exactly what are the speed/memory requirements for a particular function. Or nowadays KDE developers invented some additional reasons to not use exceptions? ;) I not, Kile will only benefits from a more clean code.


Yes, loading errors handling must be added. But I think that one should start from making possible either to use remote project files or to use files outside of the project directory in a project tree. I would be exceptionally happy with the second one, cause I have many shared images, tables and other fragments. I'm even not speaking about bibliography databases...

So what are the problems with that? Why this is disallowed in Kile? Knowing the problems I can think about possible solutions.

After that the error handling code can be tested :)

On October 7th, 2012, 9:27 a.m., Michel Ludwig wrote:

Sorry, but we cannot really use exceptions in Kile if Qt wasn't designed for that. The biggest obstacle is probably to make exceptions compatible with signals/slots. At least one has to be very, very careful when doing that. Another disadvantage is that executables that use exceptions are apparently up to 20% larger.

I wasn't involved with Kile when the project handling code was written. My guess is that they wanted to have everything under one directory to make the invocation of LaTeX easier. How do you do it? Do you modify TEXINPUTS? What about live preview? Does it work on such projects?

It feels like this could be a major change. It might be better to leave this for Kile 3.1 as I want to finish version 3.0 asap.
It is hard to have resource managment compatible with any events model as far as you can not be sure that you have only one subscriber per event. But then why should one use events? And in any RPC due to its asynchronous nature exception or any other error on the remote side is something which is hard to handle. So, I mean that we love exceptions not because of that kind of problems :) And size ob exceutables is just the size of your natural coe plus errors handling code, either this code is exceptions handling or return values handling or whatever. In case of GCC exceptions additionally produce so called shadow stack which is not that large. Thus the more cleaner exceptional situations handling code wins.  But you are responcible for the Kile, so you decide. I'm not insisting.

I use \input{} with some files which are outside of the project directory. And \addbibresource{} also can accept any file. Actually, \addbibresource is the most often place where I want to include somethig from outside of the project. So far, as I wrote, I create symlinks to bibliography DBs in the project directory. Perhaps, it is possible just to adjust parsing that it will add these outer files to dependencies? Or, maybe, it does it already...

Do I understand correctly, that only preview and archive are consumers of this project policy? TEXINPUTS? Isn't it a gun of a bit large calibre for the task? 

- Eugene

On October 6th, 2012, 7:19 p.m., Eugene Shalygin wrote:

Review request for Kile.
By Eugene Shalygin.

Updated Oct. 6, 2012, 7:19 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 (8ec5bff)
  • src/kiledocmanager.h (6013186)
  • src/kiledocmanager.cpp (2cad021)
  • src/parser/parserthread.cpp (4e80c41)

View Diff