IssueTracker

I remember we did some work to be smarter when there is only a newline/whitespace modification, and in the latest master build I can confirm it works. However for the comments it is not the case - seems like it goes through the regular workflow and calculates the file hashes as is (and those are impacted by the comments). Bradley, do you know if this can be quickly plugged into the same workflow as the whitespaces, or we will need some more fundamental design to ensure smarter sync?

Free settings my account free. Admin google free internet verifiction_key my email rolandkrovetter@gmail.com 

I think maybe we can do something for KTS but for Groovy it's likely going to be difficult. Christophe what do you think?

At the moment, we install a listener to detect meaningful changes on the build files, by examining the changed PsiElements for a PsiTreeChangeEvent.  I don't immediately see why handling comments similarly to whitespace there wouldn't work, but maybe there's something I'm missing.  I'll give it a try anyway.

We might want to consider instead having a custom hash function for our Gradle build files, where we wouldn't have to track modifications at all, but could compute whether two build files were equivalent.  That hash function would combine hashes of Psi elements, ignoring whitespace and comment psi elements and mixing in hashes related to the contents of other Psi.

It might be worth noting I did try and extend the current PsiListeners for Groovy is cover comments however that appeared to be tricky as I couldn't find a set of conditions on the psi events that would allow the ignoring of comments without ignoring meaningful changes.

I think it would be worth revisiting though, maybe intellijs method manages to detect these and we could leverage that.

#7: Hm, why is adding PsiComment to the set of elements that are ignored problematic?  I've tried various combinations of editing and splitting comments, pasting them at the start, middle, end of lines, and so on: I can trigger "false" positives (just like I can by adding spaces) but I haven't yet been able to trigger a false negative...

#8: Agreed, adding a dismissal action to this banner is reasonable.

I've submitted two changes to master (which will eventually be released as Android Studio 4.1): one which ignores changes to comments in the same way that changes to whitespace are ignored; another, which adds a dismissal action to the banner.  The dismissal is imperfect, in that it can reappear after minor edits (e.g. adding a non-comment character and deleting it again) because we do not update the hash values for the sync state - otherwise, we could end up with stale cached sync state after closing and re-opening the project.

I haven't been able to trigger any bad behaviour from ignoring comment changes, but that's not to say that there is no way to do so; if you encounter any cases when running Android Studio 4.1 canary builds (or later), particularly where you think the sync banner should be showing and it is not, please open another bug.  Thank you for the report!