Hi Jenei, On Friday, 2011-09-02 10:09:10 +0200, Eike Rathke wrote:
Without messing with the parser itself (and even then we wouldn't know if following stages would handle the result) I don't see a clean way to solve this, so I suggest to keep delComment() in parseTree() and discard getComment()/concatComment(), unfortunately that will lose comments at some (unimportant?) stage, but the query form seems to remember the original query at least.
So, this turned out to end up as something quite different.. The query form remembers the original string only until it is saved and closed, when reopening the recomposed string is presented. What I did now is to append all comments to the query while still at least preserving the line order within the comments, i.e. comments from different lines end up on different lines, not munged all together. As the parser does not handle any comments, not "-- ..." nor "// ..." nor "/* ... */" I took also care of the latter. That had to be done anyway to not have the comment extracter/deleter be confused by them. /* multi line comments */ are also handled. To lump all comments together at the end of the query and losing all context if the query consisted of multiple lines or inline comments were used is certainly ugly, but at least those syntactically correct queries actually work now and comments are preserved _somehow_. In case the parser would preserve newlines some day, the code should automatically handle that as well and append comments to each line as appropriate. Apart from the /**/ comment style changes you'll see that I changed the flow of the if's conditions so less code has to be executed on each pass of a loop, and introduced initial checks to not do these loops at all if no comments are present. I also did some minor renaming on variables, e.g. rQuery instead of sQuery if it's a reference and all that to better suit our usual style. And introduced lots of blanks ;-) Please see http://cgit.freedesktop.org/libreoffice/core/commit/?id=bc0a497f08d52450fd74c6372c9f6780f6715e40 for the result. Thanks for getting this going! Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Attachment:
signature.asc
Description: Digital signature