Tue, Apr 16
The build issue got fixed.
Fri, Apr 12
Wed, Apr 10
Ok, then we keep that license and push this as is.
I found nothing helpfull for this question. There is still the list of Unix commands, where I did only small additions and which is nearly half the lines of code.
When in doubt, I think it is better to stick to the rules. So I would like to keep it LGPL.
Sun, Apr 7
If you think you nearly changed everything, I guess MIT is ok.
If you think still too much is derived, I can live with LGPL ;=)
I let you decide.
Sat, Apr 6
Fri, Apr 5
Thanks for the contribution.
On a first glance, that looks ok, no hard coded colors, test case, ...
We would prefer if the license would be MIT, is that possible?
Wed, Apr 3
Sun, Mar 24
Sat, Mar 23
Updated groovy.xml version from 5 to 6
You also have to increase the "version" from 5 to 6. Could you provide an updated patch?
Fri, Mar 22
Mar 7 2019
Mar 5 2019
Mar 4 2019
;=) Any updates?
Feb 28 2019
Feb 24 2019
I also do not see an issue with this.
But beside the stuff with the xcvxv.xcvc stuff, I think you can commit this already as a first step to have a nicer highlighting, nice to see all hard coded colors gone!
For the . stuff in keywords, have you tried to specify some
I would have no issues with this if Volker is ok, too.
Remove outdate Octave tests
Add tests for Octave highlighting
Feb 23 2019
Cool, thanks! ...which now leads us to the point where the only missing part is a unit test for the two new public functions :-)
Feb 22 2019
Ok, this seems to work now here, too ;) Will merge it, thanks again.
Yeah, I just missed to recheck the sorting logic. Before the change we just needed the best match so the partial sort was completely sufficient. Now we need a complete sorted vector, so stable sort is the way to go ;)
Thanks for taking a look again ;=)
Feb 21 2019
Ah sorry completely missed that part. Unfortunately I'm out of office already, I'll take a look as soon as I'm back tomorrow.
Actually, do we need a partial sort? Should we not just stable_sort the complete vector by prio? That should keep stuff with same prio untouched, or?
I think the + 1 is the only real issue, the other issue stems from my local setting that I have no compiled in QRC.
I think one error is the sort of the empty vector with the begin() + 1
But even then, make test fails, after fixing this.
Please take a look and run the tests.
The partial sort is bad ;=()
Beside that this fails ;=)
Yes, this is nice, nice trick with value(0) to avoid adding an element to the vector but just letting the API default construct it.
That should implement all the latest suggestions/comments
No problem, I just reopened it that I remember to take a look again at it myself.
I just run into this issue wanting to land some patches on a openSUSE Leap machine.
Okay I've tested it with 3.12.2 and there were no issues.
I'm not familiar enough with cmake to tell whether there is a simpler version for what I try to achieve here. I just need the -D QT_NAMESPACE compiler options. Is there someone in the community who might know how to make it in a more elegant way.
If not I do not need that target_link_libraries part in Qt Creator, because we still only support building via qmake or qbs. It was just to be complete here. So it could be removed without breaking our use case, but it would break namespace builds for any one else.