|This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106567/|
On October 3rd, 2012, 7:12 p.m., Michel Ludwig wrote:Ship It!
On October 3rd, 2012, 9:40 p.m., Eugene Shalygin wrote:Dear Michel, with commit c2a2fe238f8054206cca63d209e480809196739b full parsing is there, but why did you remove files loading without Kate? Project loading is slow... What was wrong with that?
On October 4th, 2012, 6:25 a.m., Michel Ludwig wrote:When KatePart loads a file, it additionally performs auto-detection of the encoding of the file. Thus, the only way of ensuring that Kile's loading of files will give the same results as the one of KatePart would actually be to use the file loading mechanism of KatePart, but that's currently not possible.
On October 4th, 2012, 11:05 a.m., Eugene Shalygin wrote:Thank you for the reply and patch rework (almost complete rework:) If you would point me the problems before, I be happy to help you with that) I see. Indeed I forgot about encodings. But as for me it is quite a large overhead --- creating of KatePart. I still want to solve this situation in one or another way. Because what do I see in calgrind drives me crazy: to load 19 documents Kate initializes myspell 231 times and (in the same time!) hunspell --- 215 times! It is more than 20 invocations of spellchecker initializations per document. This is close to to the point of absurdity. May Kile create so many views per document? If it is not the case, I believe this has to be solved. Right now I see the following possibilities: 1. Use, for instance, KEncodingProber to load document-less files. This can cover majority of encodings. Besides, there, on project loading, where document-less Infos are present, we need to get only structure of includes (or another resources inclusion). Can one expect that user provides localized versions of \include/\input commands? I understand that this way adds some inconsistency between different documents loading pathes, which is not good. It seems to me that KDevelop is using this approach and I did not see any problems with it. However I do not use other than cyrillic single byte encodings (in addition to UTF8). 2. Change KatePart behaviour in order to add possibility to exclude loading config for the document (which can initialize spellchecking, load terminal and who knows what else...) 3. Sort out things in Kate that reads config. I would go for the first one, because it is simple for us, and seems to do less harm than benefit.
On October 4th, 2012, 1:48 p.m., Eugene Shalygin wrote:I would like to add that if one would move towards more sophisticated latex parser, then for sure it must be implemented without KatePart. Kind of vote for number 1 :)
Hehe, no, even an extended parser would operate on QStrings only ;) I had a closer look at KatePart's file loading code and it seems that if an encoding is preset, no auto-detection is attempted unless some kind of encoding problem occurs. As Kile saves the encodings of project items anyway, all that is necessary is to call 'setCodec' on the QTextStream. This should work in 99.999% of the cases. But can you put the file reading code in the doc manager as well? and use KIO::NetAccess for remote documents? Of course, the ultimate solution would be to add a method to KatePart that can read documents without setting up a full KateDocument...
On September 26th, 2012, 9:12 p.m., Eugene Shalygin wrote:
Review request for Kile.
By Eugene Shalygin.
Updated Sept. 26, 2012, 9:12 p.m.