[QScintilla] Merit of proposed signals markerLineDeleted() and markerLineUndelete()

[Phil Thompson]

On Sat, 04 May 2013 16:22:57 -0500, Daniel J Sebald
<daniel.sebald at ieee.org> wrote:
> Hi Folks,
> 
> I was working with QScintilla the other day and found it reasonably easy

> to work with, thanks.
> 
> 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.
> 
> What are you thoughts?

These are all issues with the underlying Scintilla code. I'd suggest
rephrasing them in those terms (eg. refer to notifications rather than
signals) and reporting them as Scintilla bugs.

Phil