[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