No need to get personal.
From your own posts:
So it checks every property of type string (though you are proposing that only happens when the output is expanded).
It is still unnecessary.
If you have a code change to propose, please do raise it in a pr.
We can then review the specifics and consider any issues related to the actual working implementation.
It just seems more elegant if the editor knows from the fieldname, let's say msg._backlinks[], that it contains the id of a different item in the flows file.
In the same way the editor knows that the property wires[ ] in the flow contains ids of other flow items.
1 Like
Done! 
I welcome the review!
1 Like
I'm still confused as to how/why/what with this PR
Will the PR cause every debug message in the sidebar to have a monitoring property?
No way! 
Using the monitoring property was just to give an example of how this looks like.
The goal is that if there's a string in a debug message that represents the id of a node/flow (and it doesn't matter where this string / id comes from), you may click on this string and get a visual identification around the node/flow(tab) represented by this id / string.
Are you aware there's a similar feature (already present) for numbers? Just click on any number in the debug panel...
I'll have a sleep and see if it makes sense to me in the morning
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
