Improve OCUndeclaredVariableWarning>>openMenuIn

[privat]

Low-hanging fruit. A small cleanup of openMenuIn that reduces the hackish level a little

• Remove overkill parameter
• Move the menu to the only class that cares
• Drop ugly dead hack (possibly related to some code removed a long time ago)

[Ducasse]

Jean the problem with using UI manager directly is that you are introducing a dependency to the UI part and the compiler should not depend on it. The current architecture really need a cleaning.
So we should check for now the Compiler could be configured to still open a menu but not via an explicit reference to UIManager.
Now this notion of openMenu from the compiler is totally horrible. People completely missed the point of layers.
This is the caller of the compiler that should try/catch.

[MarcusDenker]

What I wanted to:

• always compile Undeclared vars, like in non-interactive mode
• Compile them in a way that they raise the exception at runtime (if in interactive development mode()
• improve the tools to show a repair icon for Undeclared.

[estebanlm]

please do not submit more enhancements until we open P12 development.
right now, we are just accepting bugfixes.

[privat]

@Ducasse I agree, except that the PR does to add a new dependency, because it existed already before. What the PR does is moving the dependency in a single class (instead of spreading around 2½ classes).
The cover letter states "reduces the hackish level a little" because it is what it does.

Is the code still bad? Yes, but a little less.
If it's still bad, then why do we care? Because currently the state of the code is so bad (high coupling, low cohesion) that trying to improve stuff too broadly breaks a lot of things, and it's frustrating. But small, iterative and incremental changes helps to validate things in bite-size steps (both for CI and code review by humans).

My whole plan is to drastically sever the compiler<->UI relationship and simplify the whole API of the compiler, that includes all the crazy hacks and specific corner cases accumulated over time.

@MarcusDenker yes I agree, but that is not for short term because a lot of things are missing or breaking. I tried various kind of more radical approaches in some of my development branches (including nuke the whole thing), with non-conclusive results. Thus, the small proposed change here is a step towards the "nuke" result.

@estebanlm yes, see #12978 (comment)

[MarcusDenker]

good clean. The workaround for the RubSmalltalkCommentMode is good to remove, as this was a real ugly hack that might not be needed anymore

[privat]

@estebanlm Maybe this PR might interest the Pharo11 branch since it fixes the error reporting when having undeclared variables in the class definition pane of calypso (see blogpost).
But if you think it's too intrusive, I will change the base to Pharo12 oops wrong PR (I have so much open 😭)

[privat]

Tests on Pharo12 ok, except a crash on windows. This feels unrelated