<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p>Hi all! :-)</p>
<p><br>
</p>
<p>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:</p>
<p><br>
</p>
<p><img size="185838" contenttype="image/png" id="img741220" style="" contextid="img620033" tabindex="0" height="180" width="405" sizeoption="small" src="cid:2865a4e2-48fe-4d5f-ad76-d02203731d22"><br>
</p>
<p></p>
<p><br>
</p>
<p>This is a typical call of the new method #requestCode:cue: (diffed to the current version):</p>
<p><br>
</p>
<p><img size="118741" contenttype="image/png" id="img369895" style="user-select: none;" contextid="img826998" height="180" width="432" sizeoption="small" tabindex="0" src="cid:6b6885ae-7834-400d-b2ee-b39f9895f706"><br>
</p>
<p><br>
</p>
<p>Or another one:</p>
<p><br>
</p>
<p><img size="104047" contenttype="image/png" id="img158464" style="user-select: none;" contextid="img65798" height="180" width="229" sizeoption="small" tabindex="0" src="cid:00e50b6c-381f-47a4-8fa9-5148eaca123a"><br>
</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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?</p>
<p><br>
</p>
<p>Note: Before merging this, let's talk about the <a href="http://forum.world.st/Discussion-Warning-vs-Halt-or-quot-Why-is-a-warning-a-notification-quot-td5106457.html#a5106605" class="OWAAutoLink">UserNotification proposal</a> 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.</p>
<p><br>
</p>
<p>Looking forward to your feedback! :-)</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
</body>
</html>