Changeset: requestCode.cs

Hi all! :-)

This changeset extends the UIManager protocol by a set of methods for requesting code. It provides FillInTheCodeBlankMorph, a subclass of FillInTheBlankMorph which supports convenient code input. Convenience includes syntax highlighting, and, if installed, support for Autocompletion. This is how it looks in action:

This is a typical call of the new method #requestCode:cue: (diffed to the current version):

Or another one:

In addition to the UIManager protocol and FillInTheCodeBlankMorph, the changeset patches three Trunk methods that can benefit from the change (Debugger>>#runUntil, Debugger>>#returnValue and MessageSet>>#filterToMessagesThat). Also, there is a small number of convenience methods I added to Compiler and CompilationCue.

As you may have noticed, I used CompilationCue to bundle all the compilation relevant data - i.e. receiver, environment, context -, because I did not like to define messages that take six or more arguments in the UIManager. However, I'm not sure whether CompilationCue is the right data class for this purpose? It also defines source and requestor which are not relevant here, and all its constructors require a source as well. However, we already have many places where receiver, environment and often also context are exchanged between objects: for Compiler, for SHStylerST80 and SHParser, and for Autocompletion. Would that be reasonable to introduce a separate data class for this purpose?

Note: Before merging this, let's talk about the UserNotification proposal again. Provided that we decide to implement that in a visible future, I'd prefer not to define all these 5 versions of #requestCode:cue: on UIManager.

Looking forward to your feedback! :-)

Best,

Christoph

Marcel gave the germane critique that such dialogs should preserve the possibility to replace the initial selection with a custom filter, without caring about any header, what's not possible with arguments at the moment.

Neither in the Trunk:

Nor with this changeset:

How could we solve this better?

How would you think about this solution?

(Disclaimer, the screenshot is hacked via ObjectExplorer and no implementation exists at the moment. Ignore the ugly styling.)

The upper text field even could be read-only.

Question: Should we treat the input as method or block code? That is, should the answer 'true' be evaluated to 'true' or 'self'?

In general, I like to present the user a method-like dialog because this is more convenient for explaining the meaning of the arguments. On the contrary, the default return value of a method is self, not the latest statement.

Would it be misleading if the following "worked"?

Call for opinions!

Best,

Christoph

Am 15.02.2020 19:47:02 schrieb Thiede, Christoph <[hidden email]>:

> Not sure I understand this correctly... is the requirement that you should be able to type right away without accidentally overwriting the boilerplate code of the operation? The surrounding block and its arguments in this case.

This is correct.

> Just mention the variable names that can be used in the prompt.

Hm ... This feels like a workaround ... For true Smalltalkers, it should be easier to understand a code signature than actually reading natural language.

> This makes them fix, but is it necessary to be able to change them?

At least it would be a cool feature, or would it be too cool?

---

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Samstag, 15. Februar 2020 18:02:01
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: requestCode.cs

 

Am Sa., 15. Feb. 2020 um 17:30 Uhr schrieb Thiede, Christoph
<[hidden email]>:
>
> Marcel gave the germane critique that such dialogs should preserve the possibility to replace the initial selection with a custom filter, without caring about any header, what's not possible with arguments at the moment.
>

Not sure I understand this correctly... is the requirement that you
should be able to type right away without accidentally overwriting the
boilerplate code of the operation? The surrounding block and its
arguments in this case.

If you just want an expression, why indicate asking for a complete
method text? If you avoid that, the question about ^ or not can be
avoided. Just mention the variable names that can be used in the
prompt. This makes them fix, but is it necessary to be able to change
them?

Hi Marcel,

> Keep it as simple as possible. Re-use and apply the UI that is already there. :-)