#2459 Multiple issues with Qt port

[8day]

I've found multiple issues with ScintillaEditBase, like custom undocumented signals, seemingly old and unused/useless methods, custom and inconsistent function signatures used for signals (wrong order of args, missing args, etc.), missing signals, etc.

There are also plenty of issues with ScintillaEdit, like use of wrong types, old, rotting code (leftover from PySide days?), not to mention inconsistent API convention used for methods -- use of snake-case names, etc. There's also a signal with wrong order of args and two missing args. The way I see it, it's best to completely replace it with ScintillaCall-based logic, possibly even generate by ScintillaAPIFacer.py by adding a few args to that script's logic.

As for ScintillaDocument, it uses weird snake-case API that is inconsistent with the rest of code, it uses wrong types all over the place, as well as one signal has missing args.

So, judging by the fact that you are unwilling to accept breaking changes, I wanted to ask if you are OK with these issues fixed and committed into repository, seeing that there's so many and they are too obvious, meaning Qt port is barely maintained? ATM Qt port deviates from rest of Scintilla so much that the only reliable source of info about the API is the source code itself, therefore users should examine source code before doing anything fancy.

[John Ehresman]

Just wanted to say that the qt scintilla code (ScintillaEdit et al) is in use and works well for our purposes. There are a number of different naming conventions (and other conventions) -- some of which comes from the difference between Qt conventions v Scintilla conventions v Python conventions. If changes are to be made, I think they should be in response to specific problems.

[Neil Hodgson]

ScintillaEdit .. use of snake-case names,

There is a --underscore-names option in qt/ScintillaEdit/WidgetGen.py to choose between naming conventions.

completely replace it with ScintillaCall-based logic.

This can be done by C++ client code. A ScintillaCall object can be instantiated with the results of a couple of calls to ScintillaEdit (or other Scintilla wrapper) and then used instead of the ScintillaEdit class. ScintillaCall only helps C++ clients and many projects want to use Scintilla from their preferred language like the Lua binding used for user scripts in SciTE.

The ScintillaDocument class provides view-independent document access in a way that is not well supported by ScintillaCall or the basic API. There is an IDocumentEditable place-holder that may advance into a similar role in the future.

I wanted to ask if you are OK with these issues fixed and committed into repository

Fixes should aim at minimising incompatibility. If compatibility is not possible, the change should be discussed with other stakeholders, either here or on the mailing list to ensure that downstream projects don't break.