Can Plugin control which lines are marked in green/orange by Change History?
-
Hello,
when my SQL Formatter Plugin formats a SQL statement it replaces the old non-formatted statement by the new beautified statement with following (simplified) logiccurrentScint.SetSel(posSelStart, posSelEnd); currentScint.ReplaceSel(formattedSQL);Even if the formatted SQL has only 1 line changed or when nothing has been changed, the Change History will show an orange change indicator for all lines.
My question: Is there a way to tell the change history indicator which lines to mark in green and which lines to mark in orange. The SQL Formatter plugin knows which lines have changed. So, the plugin could set the indicator by itself.
Regards
Guido -
@Guido-Thelen said in Can Plugin control which lines are marked in green/orange by Change History?:
Hello,
when my SQL Formatter Plugin formats a SQL statement it replaces the old non-formatted statement by the new beautified statement with following (simplified) logiccurrentScint.SetSel(posSelStart, posSelEnd); currentScint.ReplaceSel(formattedSQL);Even if the formatted SQL has only 1 line changed or when nothing has been changed, the Change History will show an orange change indicator for all lines.
From a text editor’s perspective, changes to formatting (indentation, newline sequences, etc) are changes, because to do those, you are literally changing the text of the file. So Notepad++ disagrees with your claim that “nothing has been changed” – that “
.ReplaceSel()” made a change.My question: Is there a way to tell the change history indicator which lines to mark in green and which lines to mark in orange. The SQL Formatter plugin knows which lines have changed. So, the plugin could set the indicator by itself.
I am not an expert in the Notepad++ codebase, but as far as I know, all Notepad++ does to facilitate the Change History feature is to send the SCI_SETCHANGEHISTORY message to Scinitlla, and possibly the SCI_SETUNDOCOLLECTION, so I’m not sure how a plugin could influence things on the Notepad++ side of that equation, because I believe the “is the line changed” status comes from Scintilla logic.
However, I don’t know whether or not you can lie to the underlying Scintilla component about whether there have been changes. Looking at the Change History section in the Scintilla documentation, it doesn’t show a way to override the status for a given line, but if you can figure out how to override the markers and/or indicators mentioned there for each line, you might be able to override what Scintilla (and thus Notepad++) think about each line.
My guess is that Scintilla will fight against you on that, but studying that section, and the marker and/or indicator sections, is probably your best bet to get started down that path, if it is possible.
-
I brushed up against the OP’s problem in a somewhat related way; this PythonScript issue tells my story: https://github.com/bruderstein/PythonScript/issues/272
It’s an interesting situation…
-
@PeterJones Hi Peter, thanks for answering in such detail :-)
Please open a file with N++, select the whole content with ctrl+A followed by ctrl+C and ctrl+V. The content of the file has not change, it has just been overriden/replaced by itself. The result will be a change history showing the whole file as changed although the content is 100% identical to the saved content.Is it the very overriding/replacing which leads to an orange marker? The content has not changed.
I prefer not to “fight” against Scintilla’s logic ;-)
Regards
Guido -
@Alan-Kilborn Hi Alan, indeed, it looks like a similar situation. Thanks for letting me know.
Regards
Guido -
Please open a file with N++, select the whole content with ctrl+A followed by ctrl+C and ctrl+V. The content of the file has not change, it has just been overriden/replaced by itself. The result will be a change history showing the whole file as changed although the content is 100% identical to the saved content.
In Scintilla’s mind, that is a change: probably because paste-over-selection involves deleting all the old selected text, and replacing with whatever happens to be in the clipboard; scintilla doesn’t check the contents of the clipboard first before deciding whether it’s a change or not. As far as I understand, that
Ctrl+A,Ctrl+C,Ctrl+Vis handled essentially completely inside Scintilla (those keys are bound to Scintilla messages, so when Notepad++ receives those keystrokes, it just sends those messages to Scintilla without otherwise intervening), without any Notepad++ involvement. So it’s Scintilla that is using its internal logic to decide that it’s a change, even if the before and after do look the same and compare the same.Is it the very overriding/replacing which leads to an orange marker? The content has not changed.
As far as I understand Scintilla’s logic, yes.
I prefer not to “fight” against Scintilla’s logic ;-)
As I’ve explained, the behavior described is Scintilla’s logic. Doing elsewise would require fighting against it.
-
Scintilla Release 5.3.2
- Released 6 December 2022.
- Add SCI_REPLACETARGETMINIMAL to change text without causing unchanged prefix and suffix to be marked as modified in change history.
might be of use. How good is it compared to SCI_REPLACETARGET I do not know.
-
@mpheath thanks for your reply. This looks very promising. I will need some time to test this new feature. As the plugin has been developped using C#, the PluginInfrastructure classes have to be adapted to include this new function (I never did this before). I will let you know about the results.
Regards
Guido -
-
@mpheath Actually, the SCI_REPLACETARGETMINIMAL did the trick. In this SQL I just added I linebreak after “FROM” and only the impacted lines are shown in orange
OF course, if there was another FROM statement all the lines between the two FROM statements would be shown in orange. This is fine for me.
Regards
Guido
