On Mar 25, 2018, at 11:18 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
One of the many nice things in Squeak is that you can evaluate code in any text field.
OK. It seems that PrintIt, DoIt, etc., are not still present in, say, a TextMorph dragged from Supplies, after loading my changeset. Hmm.
A little compromise could be to remove "DefaultEditorClass" and just use #editorClass to return "TextEditor" in "TextMorph" and "SmalltalkEditor" in "TextMorphForEditView" ... which you might have been already suggested in your previous mails. :-)
Yes. :D
As H. Hirzel suggested earlier in this thread, I wonder if the fact TextMorph is using SmalltalkEditor is actually a mistake from history.
It seems SmalltalkEditor is not currently a very fleshed-out class. So I did mean to demonstrate that some amount of functionality will probably need to be yanked out of TextEditor and into SmalltalkEditor or a StructuredEditor / CodeEditor. This seems to be in the spirit of jrm’s post on in this thread … and is also what I intended to partially demonstrate in my changeset.
Efforts made here may also aid what Tim Rowledge pointed out (if I’m reading correctly): that the text-styling capabilities and text-editing shortcuts are currently kind of difficult to comprehend. For example, I’ve been trying to come to terms with in which cases Cmd-0 through Cmd-5 will have any of their various (overloaded?) effects. Sometimes, they make text disappear. But sometimes, they do indeed change font qualities. I think it may depend on whether text styles have been applied by one method or another. Still digging into that one: I was recently hunting down a DNU from hitting Cmd-9 only while inside a purple-colored styled text (a string).
Anyway, we might want to have "TextEditor", "StructuredEditor", and "SmalltalkEditor” ?
Yes, this sounds good to me too. I do fear the line might be quite blurred between StructuredEditor and SmalltalkEditor, but hopefully not.
Yes, the use of TextMorphForEditView is not necessarily an indication for a programming tool.
Yet, I did seem to find that TextMorphForEditView is mostly used in browsers, workspaces, and other ToolBuilder(?)-related windows. So, actually, TextMorphForEditView seemed to be the most code-editing-specialized text morph. I wonder if there are places this is not the case.
Hmmm…
Hmmm indeed!
Thanks, Tim
Best, Marcel
Am 25.03.2018 08:33:14 schrieb Tm Jhnsn digit@sonic.net:
Hi Marcel,
I certainly agree with you that this is a useful feature which some people prefer/expect in code editors. But here I am also thinking about "text" "editors" like Microsoft Word, OpenOffice, Notepad, TextEdit, etc. I suppose I am bringing about a philosophical question.
Thanks, Tim
On Mar 24, 2018, at 11:12 PM, Taeumel, Marcel wrote:
Hi, there.
Both autoIndent and autoEnclose are not quite Smalltalk-specific. Take a look at other text editors out there like Sublime or Atom. Keeping the indent or adding the second character of an enclosing pair is quite generic.
Please, do not move these things down to SmalltalkEditor.
Yet, we could think about separate preferences for Smalltalk editors and other editors.
Best, Marcel
Am 24.03.2018 um 21:18 schrieb H. Hirzel :
Hi Tim
Thank you for looking into this issue and for the insightful analysis
In my Squeak6.0alpha update: #17330 image I have
TextMorph defaultEditorClass
answering
SmalltalkEditor
I wonder how this got set
TextMorph defaultEditorClass: aTextEditorClass "Sets the default editor class for TextMorph" "
has no senders.
And BTW the comment in
TextMorph defaultEditorClass: aTextEditorClass
needs to be updated marking 'TextMorphEditor' as deprecated.
I wonder if it is just a mistake that the class variable DefaultEditorClass in TextMorph got set wrongly?
Regards Hannes
On 3/24/18, Tim Johnson wrote: Hi all,
I went on a journey this morning which could have been quixotic, but I believe I actually found and slayed a small windmill.
I was a bit annoyed by how autoEnclose (and by extension autoIndent) were in effect for even the most basic of TextMorphs, e.g. those dragged out of the Supplies flap. I was also kind of disappointed that turning on/off the auto-enclose preference affected all text morphs, even those not specifically designated for Smalltalk code editing. I was emboldened when I saw the class comment for TextEditor: "[I] have no specific facilities for editing Smalltalk code. Those are found in SmalltalkEditor."
I found myself able to address this by making a few changes:
- moving autoEnclose and autoIndent functionality out of TextEditor and
into SmalltalkEditor
changing the default editor class for TextMorph to TextEditor
specifying that the #editorClass for TextMorphForEditView should be a
SmalltalkEditor
- changing PreferenceWizard to recognize these preferences have a new
home
I'm attaching a changeset to this email and not uploading an .mcz to inbox (sorry). This is because I don't know how to represent changes across many projects in Monticello, and I sort of consider this a proof-of-concept rather than something I think warrants immediate inclusion in the image.
Please do let me know what you think about this idea.
I also fear my implementation of SmalltalkEditor>>#dispatchOnKeyboardEvent: might be lacking.
Thanks, Tim
ps - I think a next step of moving Smalltalk editing support into SmalltalkEditor might be to move the call to ToolSet>>#codeCompletionAround:textMorph:keyStroke: out of TextMorph>>#keyStroke: and into its subclass, in TextMorphForEditView>>#keyStroke:. I didn't complete that move and did not quite figure out how the subclass version of that method works.