#2359 Change History shows wrong state after undo from save point

[Markus Nißl]

This bug is reproducible with SciTE 5.3.1:

1. Open a file.
2. Type abc. -> The change tracking marker is orange (= This line is different to its state on disk). Correct.
3. Save the file. -> The marker is green (=This line is the same as its state on disk). Correct.
4. Type def. -> The marker is orange (= This line is different to its state on disk). Correct.
5. Save the file. -> The marker is green (=This line is the same as its state on disk). Correct.
6. Undo. -> The marker is green ... which is wrong: The line is not the same as its state on disk.

[Neil Hodgson]

I am loath to open this one up as the likely outcome is more feature option flags making change history even more complex.

At (6), the line contains a saved insertion 'abc' and a reverted insertion 'def'. With in-text change indicators change.history=7, there is a green underline for 'abc' and a blue triangle where 'def' was reverted-to-origin.

This is summarized onto the margin as both saved and reverted-to-origin. With the default margin markers, the blue reverted-to-origin state is not visible but it can be revealed with translucent markers or using a different symbol like a left side rectangle.

marker.reverted.to.origin=style:leftrect,fore:#40A0BF,back:#40A0BF

The reverted-to-origin state could be prioritized over saved but that would (arguably) be even less correct.

It may be better to summarize this line as reverted-to-modified. During development there were attempts to interpret mixed states in a nicer way but that was more complex and had more cases - its possible to have all 4 states on one line and insertions and deletions may have different desired levels of prominence. Therefore, the released version shows multiple markers allowing application developers or users to choose multiple marker symbols or to have states obscure lower priority ones.

The documentation describes the common 'happy-path' in a way that users can understand. During the long development of change history, users (including application developers) were uninterested in details and even argued in favour of inaccurate implementations as better than nothing. Documentation could be added for lines with multiple states but that shouldn't obscure the simple commonly occurring states.

[Markus Nißl]

I agree that features should default to behaviour that is intuitive and hence understandable at first glance.

I'm a long time (20 years) user of both Microsoft's SQL Server Management Studio and Visual Studio where I had first contact with code editor change tracking being displayed in the margin. The implementation of the two differs and if I recall correctly, SSMS features four states, but IMHO, three states are sufficient for most users:

1. Not changed since loaded.
2. Changed, but not yet saved.
3. Changed and saved.

There are two very important aspects:

• Has a line changed since the last save point? (Irrelevant if the line matches a previous save point.)
• What you see as persisted (state 3) is indeed persisted.

If the document reaches a save point, then only lines in states 1 and 3 are possible. This is what confuses me most by the current implementation: the margin tells the user that the line was saved to disk while it isn't.

Are you in favour of a switch which influences the final marker state? I.e. to either go for the current implementation or a reduced (but clearer) 3 state visualisation.

[Neil Hodgson]

three states are sufficient for most users

Compatibility with Visual Studio requires reverted-to-origin.

Are you in favour of a switch which influences the final marker state?

That is going to depend on how it works.

[Markus Nißl]

Compatibility with Visual Studio requires reverted-to-origin.

I've just tested my report bug scenario with both SSMS 19 and VS 2022 which I didn't have at my disposal yesterday. I wasn't aware of the fact that both applications support reverted-to-origin , a state I have never actively noticed, obviously. Hence my "plea" for three states.

Anyway, both applications don't show the bug I described in my original post.