Move strip trailing whitespace into main code; remove plugin

[jeremypw]

Fixes #1098

A hopefully minor behavior change is that stripping (and saving) now occurs whenever the document loses focus as well as on manual saving.

Stripping does not occur on every autosave as it could interfere unacceptably with ongoing editing.

An issue raised by this is what to do about the already installed plugin - this PR overwrites it so that it does not appear in the Extensions dialog. Alternative solutions welcome.

I guess that once the app is supplied only as a Flatpak this will not be an issue and the plugin overwriting code can be removed.

[jeremypw]

Bug found - converting to draft while fixing.

[jeremypw]

Reduced scope of PR so that current behaviour (strip only on manual save or close) is unaffected. Stripping on autosave would be easy to add later if required.

[jeremypw]

The problem with CI appears unrelated to this PR - it compiles OK locally.

[zeebok]

This looks good to me

[jeremypw]

A possible refinement is to have the "strip trailing whiltespace" functionality independent of saving so that it occurs even if "autosave" is off.

[zeebok]

Hmmm how would that look separated from saving? Remove the trailing white space when a user starts a new line?

[jeremypw]

No, I found it too intrusive for stripping to occur immediately after leaving a line. For example, I like to insert a blank line and the closing brace of an if () {} clause then go back and fill in the body of the clause - I do not want the indenting spaces to be removed at that point. The stripping would still occur when losing focus - e.g. switching to another document or a terminal even if the document is not autosaving. At the moment with master I have to consciously press <Ctrl>S on each document before running vala-lint.

[zeebok]

Gotcha. Do you think that might not do it often enough? If I write a quick fix, or just code for a short time, in a single doc and close Code it sounds like it wouldn't strip. Not a frequent scenario but one I can picture happening.

[jeremypw]

I think #1188 might be relevant here - this could also ensure stripping occurs.

[zeebok]

Yeah that seems good. Personally the more places it checks and does the stripping without interfering the better so it ensures a consistent experience. Losing focus, on saves, etc are all good places to me.

[jeremypw]

@zeebok Is it OK to merge this PR (which should behave pretty much the same as master, without regressions) and make changes to behaviour in future PRs?

[danirabbit]

I am in favor of moving plugins into the main source for sure 👍

Instead of using the phrase "blacklist" here, can we use "blocklist" instead?

[Marukesu]

An issue raised by this is what to do about the already installed plugin - this PR overwrites it so that it does not appear in the Extensions dialog. Alternative solutions welcome.

I think this should be handled from the package side, for source installations, we should recommend doing an sudo ninja uninstall before a new ninja install, so that old plugins get removed.

For the deb package, aren't plugins installed in the same package? so when an update occurs, they all got removed and only the ones in the new build installed?

the flatpak package aren't affected by this.

[jeremypw]

@Marukesu I didn't realise Code has an uninstall ninja target - not all projects (e.g. Files) have one. In that case, and in view of the fact that Flatpaks are unaffected I will remove the relevant code from this PR. I am uncertain whether just updating a deb will remove old plugins though.

[danirabbit]

Yeah the Deb package will cleanup old installed files like plugins so this only affects source installs

Blocklist removed