[QScintilla] Merit of proposed signals markerLineDeleted() and markerLineUndelete()
Baz Walter
bazwal at ftml.net
Sun May 5 18:14:21 BST 2013
On 04/05/13 22:22, Daniel J Sebald wrote:
> I did find one behavior to be problematic. It is when a line is deleted
> which contains a marker. When non-marker lines are added or deleted,
> lines having markers adjust appropriately, and one is able to access
> that line number via marker handle. All good.
>
> However, when a line is delete that has a marker, that marker becomes
> associated with a line that still remains in the edit window. I realize
> there is some question as what to do in that case. However, if
> QScintilla had two signals
>
> markerLineDeleted (int mhandle, int linenr)
> markerLineUndeleted (int mhandle, int linenr)
>
> or something similar then the programmer could act accordingly to, for
> example, remove that marker or maybe change the marker to some other
> marker indicating questionable location.
>
> I've also noticed if the line in which there is a marker is deleted (and
> the marker goes to another line), when the "undo" button is pressed and
> the deleted line restored, the marker doesn't go back to the original
> line but stays at the line post delete. Could that be fixed to have the
> marker go back to the original line?
>
> If there were a markerLineDeleted (mhandle, linenr), the programmer
> could record the linenr at the time it was deleted. Then if there is a
> markerLineUndeleted (mhandle, linenr) signal, the programmer could move
> the marker back to its position at the time it was deleted.
It looks like Scintilla may provide some low-level stuff that could be
enough to roll your own solution.
I suggest you take a look at the SCN_MODIFIED notification:
http://www.scintilla.org/ScintillaDoc.html#SCN_MODIFIED
which sets the SC_MOD_CHANGEMARKER flag when the markers have changed,
and also gives the line on which the changes occurred.
--
Regards
Baz Walter
More information about the QScintilla
mailing list