Comment 45 for bug 594073

After looking some time again:
One the one hand you are completely right. Neither killing the undo/redo
list nor the need to annotate everything is something one wants for
"simple" highlighting. On the other hand using the exact netlist export
process garantees that the highlighting is consistent with the exported
netlist. So is introducing a parallel procedure with temporary
annotation (which hopefully does not break something else) and avoidence
of the cleanup really the best option? What if someone changes the
behaviour only in one of both procedures?

So imho if one wants to get it right one should change the netlist
export to respect the undo/redo list - or is it good pratice that
export/sync breaks the undo/redo?
If I am not mistaken clearing the undo/redo list is done in (all
eeschema files listed):
LIB_EDIT_FRAME::OnImportPart
LIB_EDIT_FRAME::LoadComponentFromCurrentLib
LIB_EDIT_FRAME::CreateNewLibraryPart
SCH_SCREEN::~SCH_SCREEN
DIALOG_ERC::TestErc
SCH_SCREENS::SchematicCleanUp

For the here discussed case only the later three are of interested.
Interestingly SCH_SCREEN::SchematicCleanUp is called several times
without a correlated ClearUndoRedoList (e.g. AddNoConnect, EndSegment).
So my question is: Is ClearUndoRedoList really required/reasonable?
Regarding the annotation it would be better if it would not be required
but again: to avoid double doing and later divergence in behaviour I
would argue that it is the lesser evil to make annotation mandetory for
net highlighting - the user is still free to not use net highlighting at
all. Maybe I am naive but from a users perspective not having net
highlighting at all seems to me like a bigger issue than dealing with
annotation and even more threating is a net highlighting which is
potentially not consistent to netlist export.

P.S: Annotiation messes with undo/redo but neither clears the list nor
does it track changes if i am not mistaken. Just apply some changes
(e.g. rename parts), revert some changes, then run annotiation and play
around with undo/redo.

best regards

Am 01.11.2016 um 13:06 schrieb jean-pierre charras:
> Sorry to say that, but neither are good (and neither are acceptable).
>
> Unannotated components are not an issue to highlighting a connection.
> I means the reference is not really used, although it cannot be fully ignored.
>
> In fact you have 2 issues, when calling prepareForNetlist() (that is currently designed to prepare a netlist for a board):
> - it cleanup the schematic (merge collinear wires, and therefore change the wire list).
> - it tests everything strange thing in annotation.
>
> Cleanup the schematic avoid side effects in connection calculation:
> - It avoid false connections (This is a rare case, not very important here). But it has a side effect: if the wire list is modified, the undo/redo list is cleared (is has no matter when creating a netlist for a board, but it is is annoying in this case)
> It could be avoided here.
> - It calls CheckAnnotate().
> CheckAnnotate() tests incorrect annotation (duplicates, not annotated and a few other things)
> As I say previously, not annotated components are not blocking (other issues are, but they are very infrequent).
> However annotating them before the schematic is finished is very annoying (think to not interchangeable units for instance).
> Moreover, annotating components clears the undo/redo list.
>
> Therefore:
> * prepareForNetlist(), when called to highlight a net, should not cleanup the schematic and should no test for not annotated items.
> * Not annotated items (only to calculate the connection list) should receive a temporary annotation (for instance the full timestamp).
> The reason is the fact if you have 2 different components having the same ref (say R?) and the same pin number (say 1) all connection to pins (R? pin 1) will be merged.
>