A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval. textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString
+ self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger
+ aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn. + self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn.
self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt
self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
[cid:23717c7d-e38c-4ef9-b852-51c42943885d]
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval.
textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString
+ self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger
+ aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn.
+ self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn.
self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt
self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
+1
Best, Marcel Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz [http://source.squeak.org/inbox/Morphic-ct.1586.mcz]
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval. textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString + self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger + aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn. + self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn. self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
Only drawback: If you copy the result to use it for another computation, you spread the link formatting all over your code ...
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 10:36:07 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
+1
Best, Marcel
Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
[cid:23717c7d-e38c-4ef9-b852-51c42943885d]
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval.
textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString
+ self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger
+ aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn.
+ self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn.
self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt
self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
Is it because you do not append "emphasisHere" after your custom emphasis? Am 12.11.2019 13:15:43 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Only drawback: If you copy the result to use it for another computation, you spread the link formatting all over your code ... Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 10:36:07 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz +1
Best, Marcel Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz [http://source.squeak.org/inbox/Morphic-ct.1586.mcz]
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval. textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString + self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger + aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn. + self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn. self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
Hi Marcel,
Thanks for the hint, I played a bit around with emphasisHere. But if I am not mistaken, you cannot set emphasisHere for the next character to be typed while another text (the printIt result) is currently selected?
This is also only one half of the problem. Personally, I often copy one printIt result to use it at another place. (I know, variables would be a better option, however, I feel convenient to do this.) It looks kind of weird if this link is spread all over your workspace:
[cid:1a56dcc7-b8be-4dd1-81fa-4e9983c966f8]
So unless someone has a great idea to avoid this (a special RunArray of attributes that are private to an editor? a TextAttribute that cannot be copied?), I would rather tend to withdraw my proposal ...
(Btw: A somehow related issue is that the search bar accepts formatted text from clipboard but does not style it, so in my image, it often looks kind of missstyled:
[cid:ddfbae54-9593-4ea1-aec1-7e552acbd8be])
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 14:05:23 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Is it because you do not append "emphasisHere" after your custom emphasis?
Am 12.11.2019 13:15:43 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Only drawback: If you copy the result to use it for another computation, you spread the link formatting all over your code ...
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 10:36:07 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
+1
Best, Marcel
Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
[cid:23717c7d-e38c-4ef9-b852-51c42943885d]
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval.
textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString
+ self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger
+ aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn.
+ self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn.
self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt
self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
... spread all over your workspace ...
What do you mean by that? Copy-and-paste of text should always carry those attributes. With "spreading" I thought you mean you would unintentionally extend those text links to other characters.
What about this style after a print-it :
World extent 3840@2004 [explore]
Tricky. We want to preserve to preserve the actual #printString ... Does [cmd]+[0] still work?
Best, Marcel Am 13.11.2019 18:06:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
Thanks for the hint, I played a bit around with emphasisHere. But if I am not mistaken, you cannot set emphasisHere for the next character to be typed while another text (the printIt result) is currently selected?
This is also only one half of the problem. Personally, I often copy one printIt result to use it at another place. (I know, variables would be a better option, however, I feel convenient to do this.) It looks kind of weird if this link is spread all over your workspace:
So unless someone has a great idea to avoid this (a special RunArray of attributes that are private to an editor? a TextAttribute that cannot be copied?), I would rather tend to withdraw my proposal ...
(Btw: A somehow related issue is that the search bar accepts formatted text from clipboard but does not style it, so in my image, it often looks kind of missstyled: )
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 14:05:23 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Is it because you do not append "emphasisHere" after your custom emphasis? Am 12.11.2019 13:15:43 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Only drawback: If you copy the result to use it for another computation, you spread the link formatting all over your code ... Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 10:36:07 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz +1
Best, Marcel Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz [http://source.squeak.org/inbox/Morphic-ct.1586.mcz]
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval. textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString + self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger + aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn. + self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn. self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
Hi Marcel,
yes, <cmd>0 still works. It is an interesting idea to put the link aside to the actual print string, but I have to admit that both approaches would make the usual workflow of copying and reusing the printIt string more complicated, unfortunately ...
Another idea, should we maybe consider some kind of TextMorph/editor extension that is indeed not affected by clipboard? Visually, something like:
[cid:c4954e41-9206-4223-ab5e-ea0d86e2d30e]
Such a text attachment would need to be laid out like regular TextAnchors, however, they must not be selected by the cursor. One could describe the idea as an extension to the TextAnchor that prohibits an editor to select it.
***
BTW: Another related problem is that unless you delete the printed-it string, all following commands in a workspace will be miss-styled (see above). Someone recently mentioned that Pharo restarts styling after #codeExcess in each new line, which sounds great. Should we maybe add a similar feature to Shout?
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 14. November 2019 09:28:58 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
... spread all over your workspace ...
What do you mean by that? Copy-and-paste of text should always carry those attributes. With "spreading" I thought you mean you would unintentionally extend those text links to other characters.
What about this style after a print-it :
World extent 3840@2004 [explore]
Tricky. We want to preserve to preserve the actual #printString ... Does [cmd]+[0] still work?
Best, Marcel
Am 13.11.2019 18:06:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
Thanks for the hint, I played a bit around with emphasisHere. But if I am not mistaken, you cannot set emphasisHere for the next character to be typed while another text (the printIt result) is currently selected?
This is also only one half of the problem. Personally, I often copy one printIt result to use it at another place. (I know, variables would be a better option, however, I feel convenient to do this.) It looks kind of weird if this link is spread all over your workspace:
[cid:1a56dcc7-b8be-4dd1-81fa-4e9983c966f8]
So unless someone has a great idea to avoid this (a special RunArray of attributes that are private to an editor? a TextAttribute that cannot be copied?), I would rather tend to withdraw my proposal ...
(Btw: A somehow related issue is that the search bar accepts formatted text from clipboard but does not style it, so in my image, it often looks kind of missstyled:
[cid:ddfbae54-9593-4ea1-aec1-7e552acbd8be])
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 14:05:23 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Is it because you do not append "emphasisHere" after your custom emphasis?
Am 12.11.2019 13:15:43 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Only drawback: If you copy the result to use it for another computation, you spread the link formatting all over your code ...
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 10:36:07 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
+1
Best, Marcel
Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
[cid:23717c7d-e38c-4ef9-b852-51c42943885d]
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval.
textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString
+ self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger
+ aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn.
+ self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn.
self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt
self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
If you're wanting the result of a printit to be easily inspectable I see a couple of easy options - a) the printit is already highlighted so all you have to do is cmd-i b) if that isn't good enough - maybe you clicked somewhere else and want to go back, and it's too much work to select the relevant text - how about adding another text attribute for 'inspect this'? We already have 'do it', 'print it' and 'link', and I assume you're intending to add 'code style it' sometime soon.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Florida: more red in the face
... the usual workflow of copying and reusing the printIt string more complicated ...
Note that print-it does not always produce a "store string" and is thus not always executable. ;-)
Best, Marcel Am 14.11.2019 12:58:22 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
yes, <cmd>0 still works. It is an interesting idea to put the link aside to the actual print string, but I have to admit that both approaches would make the usual workflow of copying and reusing the printIt string more complicated, unfortunately ...
Another idea, should we maybe consider some kind of TextMorph/editor extension that is indeed not affected by clipboard? Visually, something like:
Such a text attachment would need to be laid out like regular TextAnchors, however, they must not be selected by the cursor. One could describe the idea as an extension to the TextAnchor that prohibits an editor to select it.
***
BTW: Another related problem is that unless you delete the printed-it string, all following commands in a workspace will be miss-styled (see above). Someone recently mentioned that Pharo restarts styling after #codeExcess in each new line, which sounds great. Should we maybe add a similar feature to Shout?
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 14. November 2019 09:28:58 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
... spread all over your workspace ...
What do you mean by that? Copy-and-paste of text should always carry those attributes. With "spreading" I thought you mean you would unintentionally extend those text links to other characters.
What about this style after a print-it :
World extent 3840@2004 [explore]
Tricky. We want to preserve to preserve the actual #printString ... Does [cmd]+[0] still work?
Best, Marcel Am 13.11.2019 18:06:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
Thanks for the hint, I played a bit around with emphasisHere. But if I am not mistaken, you cannot set emphasisHere for the next character to be typed while another text (the printIt result) is currently selected?
This is also only one half of the problem. Personally, I often copy one printIt result to use it at another place. (I know, variables would be a better option, however, I feel convenient to do this.) It looks kind of weird if this link is spread all over your workspace:
So unless someone has a great idea to avoid this (a special RunArray of attributes that are private to an editor? a TextAttribute that cannot be copied?), I would rather tend to withdraw my proposal ...
(Btw: A somehow related issue is that the search bar accepts formatted text from clipboard but does not style it, so in my image, it often looks kind of missstyled: )
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 14:05:23 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Is it because you do not append "emphasisHere" after your custom emphasis? Am 12.11.2019 13:15:43 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Only drawback: If you copy the result to use it for another computation, you spread the link formatting all over your code ... Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 10:36:07 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz +1
Best, Marcel Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz [http://source.squeak.org/inbox/Morphic-ct.1586.mcz]
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval. textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString + self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger + aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn. + self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn. self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
I know, but sometimes it is executable, and I would not like to miss this possibility :-)
@tim: Such a TextPrintIt (subclass of TextDoIt) sounds interesting! However, it does not solve the problem that you are not able to copy the plain text even longer, I think.
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual.
Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector.
We would not even need to display this Attribute visually if it works reliably.
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 15. November 2019 09:25:12 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
... the usual workflow of copying and reusing the printIt string more complicated ...
Note that print-it does not always produce a "store string" and is thus not always executable. ;-)
Best, Marcel
Am 14.11.2019 12:58:22 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
yes, <cmd>0 still works. It is an interesting idea to put the link aside to the actual print string, but I have to admit that both approaches would make the usual workflow of copying and reusing the printIt string more complicated, unfortunately ...
Another idea, should we maybe consider some kind of TextMorph/editor extension that is indeed not affected by clipboard? Visually, something like:
[cid:c4954e41-9206-4223-ab5e-ea0d86e2d30e]
Such a text attachment would need to be laid out like regular TextAnchors, however, they must not be selected by the cursor. One could describe the idea as an extension to the TextAnchor that prohibits an editor to select it.
***
BTW: Another related problem is that unless you delete the printed-it string, all following commands in a workspace will be miss-styled (see above). Someone recently mentioned that Pharo restarts styling after #codeExcess in each new line, which sounds great. Should we maybe add a similar feature to Shout?
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 14. November 2019 09:28:58 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
... spread all over your workspace ...
What do you mean by that? Copy-and-paste of text should always carry those attributes. With "spreading" I thought you mean you would unintentionally extend those text links to other characters.
What about this style after a print-it :
World extent 3840@2004 [explore]
Tricky. We want to preserve to preserve the actual #printString ... Does [cmd]+[0] still work?
Best, Marcel
Am 13.11.2019 18:06:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
Thanks for the hint, I played a bit around with emphasisHere. But if I am not mistaken, you cannot set emphasisHere for the next character to be typed while another text (the printIt result) is currently selected?
This is also only one half of the problem. Personally, I often copy one printIt result to use it at another place. (I know, variables would be a better option, however, I feel convenient to do this.) It looks kind of weird if this link is spread all over your workspace:
[cid:1a56dcc7-b8be-4dd1-81fa-4e9983c966f8]
So unless someone has a great idea to avoid this (a special RunArray of attributes that are private to an editor? a TextAttribute that cannot be copied?), I would rather tend to withdraw my proposal ...
(Btw: A somehow related issue is that the search bar accepts formatted text from clipboard but does not style it, so in my image, it often looks kind of missstyled:
[cid:ddfbae54-9593-4ea1-aec1-7e552acbd8be])
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 14:05:23 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Is it because you do not append "emphasisHere" after your custom emphasis?
Am 12.11.2019 13:15:43 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Only drawback: If you copy the result to use it for another computation, you spread the link formatting all over your code ...
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 12. November 2019 10:36:07 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
+1
Best, Marcel
Am 10.11.2019 16:07:23 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
[cid:23717c7d-e38c-4ef9-b852-51c42943885d]
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Sonntag, 10. November 2019 16:06:26 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1586.mcz
==================== Summary ====================
Name: Morphic-ct.1586 Author: ct Time: 10 November 2019, 4:06:17.228559 pm UUID: d752eb23-2116-0945-b043-aff08fed94fd Ancestors: Morphic-mt.1584
Proposal: Style printIt results as a pluggable link that can be clicked to inspect the result.
To enable this behavior, this commit also extends #insertAndSelect:at: to allow for inserting both strings and texts.
=============== Diff against Morphic-mt.1584 ===============
Item was changed: ----- Method: PluggableTextMorph>>printIt (in category 'menu commands') ----- printIt | oldEditor | textMorph editor selectFrom: selectionInterval first to: selectionInterval last; model: model. "For, eg, evaluateSelection" textMorph handleEdit: [(oldEditor := textMorph editor) evaluateSelectionAndDo: [:result | selectionInterval := oldEditor selectionInterval. textMorph installEditorToReplace: oldEditor. + textMorph handleEdit: [ oldEditor afterSelectionInsertAndSelect: + (oldEditor printTextFor: result)]. - textMorph handleEdit: [oldEditor afterSelectionInsertAndSelect: result printString]. selectionInterval := oldEditor selectionInterval.
textMorph editor selectFrom: selectionInterval first to: selectionInterval last. self scrollSelectionIntoView]]!
Item was changed: ----- Method: TextEditor>>afterSelectionInsertAndSelect: (in category 'new selection') ----- + afterSelectionInsertAndSelect: aStringOrText - afterSelectionInsertAndSelect: aString
+ self insertAndSelect: aStringOrText at: self stopIndex ! - self insertAndSelect: aString at: self stopIndex !
Item was changed: ----- Method: TextEditor>>insertAndSelect:at: (in category 'new selection') ----- + insertAndSelect: aStringOrText at: anInteger - insertAndSelect: aString at: anInteger
+ aStringOrText isString ifTrue: [ + ^ self + insertAndSelect: (Text string: aStringOrText attributes: emphasisHere) + at: anInteger]. - self closeTypeIn.
+ self closeTypeIn. self selectInvisiblyFrom: anInteger to: anInteger - 1. self openTypeIn.
self replace: self selectionInterval + with: (Text string: ' ' attributes: emphasisHere), aStringOrText - with: (Text string: (' ', aString) attributes: emphasisHere) and: []. - self closeTypeIn.!
Item was changed: ----- Method: TextEditor>>printIt (in category 'do-its') ----- printIt
self evaluateSelectionAndDo: [:result | (model respondsTo: #printIt:result:) ifTrue: [model perform: #printIt:result: with: self selection with: result] + ifFalse: [self afterSelectionInsertAndSelect: (self printTextFor: result)]]! - ifFalse: [self afterSelectionInsertAndSelect: result printString]]!
Item was added: + ----- Method: TextEditor>>printTextFor: (in category 'do-its') ----- + printTextFor: anObject + + ^ Text + string: anObject printString + attributes: {PluggableTextAttribute evalBlock: [anObject inspect]}!
Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual.
Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector.
We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de: Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@student.hpi.uni-potsdam.de]> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Marcel, it's great that you have found a solution to this idea! :-)
^ (self class interactivePrintIt and: [(anObject isString or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 16. April 2021 17:27:54 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual.
Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector.
We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, it's great that you have found a solution to this idea! :-)
+ ^ (self class interactivePrintIt and: [(anObject isString or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 16. April 2021 17:27:54 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de: Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@student.hpi.uni-potsdam.de]> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 16. April 2021 19:52:16 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, it's great that you have found a solution to this idea! :-)
^ (self class interactivePrintIt and: [(anObject isString or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 16. April 2021 17:27:54 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual.
Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector.
We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel Am 19.04.2021 13:21:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
> Also consider this snippet where the print-link does not exist for an MCVersionName Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 16. April 2021 19:52:16 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, it's great that you have found a solution to this idea! :-)
+ ^ (self class interactivePrintIt and: [(anObject isString or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 16. April 2021 17:27:54 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de: Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@student.hpi.uni-potsdam.de]> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
All,
How about:
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
so inspectors can skip unitary objects?
Just a thought .. Subbu
On 19/04/21 8:36 pm, Marcel Taeumel wrote:
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel
Am 19.04.2021 13:21:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 19:52:16 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, it's great that you have found a solution to this idea! :-)
+ ^ (self class interactivePrintIt and: [(anObject isString
or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 17:27:54 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de mailto:Christoph.Thiede@student.hpi.uni-potsdam.de> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed? Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Marcel, hi all,
I keeping considering this type check as something bad and unexpected. :-)
First, as I have mentioned earlier, subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example. Second, even a string can be non-trivial, for instance, "String value: 1234", where I only will see a question mark unless I inspect the result. Yes, in the second example, I could also trouble the Compiler again for a new inspect-it, but I just don't see why we should restrict these useful links for certain types of results. Also, in all situations where you do some experiments concerning identity, an inspector would be very helpful to track individual instances. Re-evaluating the expression would not be a solution here.
To summarize, I just would not say that any object in Squeak can have a boring structure. It's just the other way around, these clickable results are a great way to make the inspector more visible in the system.
PS: We should also consider making the new links available for print-its in the search bar.
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von K K Subbu kksubbu.ml@gmail.com Gesendet: Montag, 19. April 2021 18:23:22 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
All,
How about:
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
so inspectors can skip unitary objects?
Just a thought .. Subbu
On 19/04/21 8:36 pm, Marcel Taeumel wrote:
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel
Am 19.04.2021 13:21:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 19:52:16 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, it's great that you have found a solution to this idea! :-)
^ (self class interactivePrintIt and: [(anObject isString
or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 17:27:54 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de mailto:Christoph.Thiede@student.hpi.uni-potsdam.de> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed? Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Christoph
On 19. Apr 2021, at 19:29, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi Marcel, hi all,
I keeping considering this type check as something bad and unexpected. :-)
Note that in this instance, 'isInspectable' is actually a plain behavior check, not a type check at all. It's not "isMorph" or something. While "is*" is often used/misused/abused as type check, this kind here is actually not one of these :
Best regards -Tobias
First, as I have mentioned earlier, subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example. Second, even a string can be non-trivial, for instance, "String value: 1234", where I only will see a question mark unless I inspect the result. Yes, in the second example, I could also trouble the Compiler again for a new inspect-it, but I just don't see why we should restrict these useful links for certain types of results. Also, in all situations where you do some experiments concerning identity, an inspector would be very helpful to track individual instances. Re-evaluating the expression would not be a solution here.
To summarize, I just would not say that any object in Squeak can have a boring structure. It's just the other way around, these clickable results are a great way to make the inspector more visible in the system.
PS: We should also consider making the new links available for print-its in the search bar.
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von K K Subbu kksubbu.ml@gmail.com Gesendet: Montag, 19. April 2021 18:23:22 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
All,
How about:
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
so inspectors can skip unitary objects?
Just a thought .. Subbu
On 19/04/21 8:36 pm, Marcel Taeumel wrote:
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel
Am 19.04.2021 13:21:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 19:52:16 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, it's great that you have found a solution to this idea! :-)
^ (self class interactivePrintIt and: [(anObject isString
or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 17:27:54 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de mailto:Christoph.Thiede@student.hpi.uni-potsdam.de> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed? Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Tobias,
yes, I know. Then let's correct my formulation into: "this functionality check is something bad and unexpected". :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Tobias Pape Das.Linux@gmx.de Gesendet: Montag, 19. April 2021 19:40:43 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph
On 19. Apr 2021, at 19:29, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi Marcel, hi all,
I keeping considering this type check as something bad and unexpected. :-)
Note that in this instance, 'isInspectable' is actually a plain behavior check, not a type check at all. It's not "isMorph" or something. While "is*" is often used/misused/abused as type check, this kind here is actually not one of these :
Best regards -Tobias
First, as I have mentioned earlier, subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example. Second, even a string can be non-trivial, for instance, "String value: 1234", where I only will see a question mark unless I inspect the result. Yes, in the second example, I could also trouble the Compiler again for a new inspect-it, but I just don't see why we should restrict these useful links for certain types of results. Also, in all situations where you do some experiments concerning identity, an inspector would be very helpful to track individual instances. Re-evaluating the expression would not be a solution here.
To summarize, I just would not say that any object in Squeak can have a boring structure. It's just the other way around, these clickable results are a great way to make the inspector more visible in the system.
PS: We should also consider making the new links available for print-its in the search bar.
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von K K Subbu kksubbu.ml@gmail.com Gesendet: Montag, 19. April 2021 18:23:22 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
All,
How about:
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
so inspectors can skip unitary objects?
Just a thought .. Subbu
On 19/04/21 8:36 pm, Marcel Taeumel wrote:
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel
Am 19.04.2021 13:21:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 19:52:16 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, it's great that you have found a solution to this idea! :-)
^ (self class interactivePrintIt and: [(anObject isString
or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 17:27:54 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de mailto:Christoph.Thiede@student.hpi.uni-potsdam.de> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed? Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
On 19. Apr 2021, at 19:44, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi Tobias,
yes, I know. Then let's correct my formulation into: "this functionality check is something bad and unexpected". :-)
Ok, I don't really understand your reasoning… -t
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Tobias Pape Das.Linux@gmx.de Gesendet: Montag, 19. April 2021 19:40:43 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph
On 19. Apr 2021, at 19:29, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi Marcel, hi all,
I keeping considering this type check as something bad and unexpected. :-)
Note that in this instance, 'isInspectable' is actually a plain behavior check, not a type check at all. It's not "isMorph" or something. While "is*" is often used/misused/abused as type check, this kind here is actually not one of these :
Best regards -Tobias
First, as I have mentioned earlier, subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example. Second, even a string can be non-trivial, for instance, "String value: 1234", where I only will see a question mark unless I inspect the result. Yes, in the second example, I could also trouble the Compiler again for a new inspect-it, but I just don't see why we should restrict these useful links for certain types of results. Also, in all situations where you do some experiments concerning identity, an inspector would be very helpful to track individual instances. Re-evaluating the expression would not be a solution here.
To summarize, I just would not say that any object in Squeak can have a boring structure. It's just the other way around, these clickable results are a great way to make the inspector more visible in the system.
PS: We should also consider making the new links available for print-its in the search bar.
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von K K Subbu kksubbu.ml@gmail.com Gesendet: Montag, 19. April 2021 18:23:22 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
All,
How about:
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
so inspectors can skip unitary objects?
Just a thought .. Subbu
On 19/04/21 8:36 pm, Marcel Taeumel wrote:
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel
Am 19.04.2021 13:21:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 19:52:16 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, it's great that you have found a solution to this idea! :-)
^ (self class interactivePrintIt and: [(anObject isString
or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 17:27:54 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de mailto:Christoph.Thiede@student.hpi.uni-potsdam.de> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed? Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual. Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector. We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
even a string can be non-trivial, for instance, "String value: 1234", where I only will see a question mark unless I inspect the result.
That's why I would only skip ByteString, not WideString.
Also, in all situations where you do some experiments concerning identity, an inspector would be very helpful to track individual instances.
For most of the literals (or primitive kinds) I listed, object identity does not matter. Small integers and characters are immediate. Symbols are internalized. There is only one "nil", "true", "false." From the top of my head, I cannot think of an example, where you would be interested in two ByteStrings having the same identity. :-)
Best, Marcel
Am 19.04.2021 19:29:16 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, hi all,
I keeping considering this type check as something bad and unexpected. :-)
First, as I have mentioned earlier, subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example. Second, even a string can be non-trivial, for instance, "String value: 1234", where I only will see a question mark unless I inspect the result. Yes, in the second example, I could also trouble the Compiler again for a new inspect-it, but I just don't see why we should restrict these useful links for certain types of results. Also, in all situations where you do some experiments concerning identity, an inspector would be very helpful to track individual instances. Re-evaluating the expression would not be a solution here.
To summarize, I just would not say that any object in Squeak can have a boring structure. It's just the other way around, these clickable results are a great way to make the inspector more visible in the system.
PS: We should also consider making the new links available for print-its in the search bar.
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von K K Subbu kksubbu.ml@gmail.com Gesendet: Montag, 19. April 2021 18:23:22 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz All,
How about:
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
so inspectors can skip unitary objects?
Just a thought .. Subbu
On 19/04/21 8:36 pm, Marcel Taeumel wrote:
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel
Am 19.04.2021 13:21:53 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 19:52:16 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel, it's great that you have found a solution to this idea! :-)
+ ^ (self class interactivePrintIt and: [(anObject isString
or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 17:27:54 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke forums.jakob@resfarm.de:
Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de <mailto:Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@student.hpi.uni-potsdam.de]>> schrieb am Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual.
Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector.
We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi Marcel,
What is your stance towards using inspectors to quickly check identity, regarding ByteString? Note: to make this practical, one needs to turn on the "Reuse windows" preference.
Example workflow: 1. Expression print-it. 2. "Oh I have seen this string before, is it the same instance or another one?" 3. (Click on the result to open the inspector on the result object.) 4. Open an inspector on the other, previously encountered occurrence of the string (might be in another tool). If a second inspector appears, these are two distinct String instances.
To further motivate the question in 2., imagine that this ByteString is big, say, a several hundred MB CLOB. :-)
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi Jakob.
What is your stance towards using inspectors to quickly check identity, regarding ByteString?
I guess that I usually don't do it. I normally do not work in domains where efficient string construction matters or individual bytes/characters might fail ... waiting to be inspected. If I would expect a larger payload from a web request, for example, I would normally do explore-it or inspect-it directly -- or have the WebResponse open in an explorer already. I only rely on symbols being identical.
(I slightly recall a discussion where something in Squot relies on PackageInfo to never change its identity. ... which I still regard as a design smell bc. we have symbols for that and package names are symbols.)
To further motivate the question in 2., imagine that this ByteString is big, say, a several hundred MB CLOB. :-)
I would expect that, in such a scenario, print-it would rarely be used. Especially since that click would open a new tool and returning to that old one might destroy the text selection of "mouse over keyboard focus" is not enabled. Then you would have to remember how text undo works.
Hmmm... we might want to remove that interactive print-it text after the user has clicked on it :-)
Best, Marcel
Am 25.04.2021 19:39:00 schrieb Jakob Reschke jakres+squeak@gmail.com: Hi Marcel,
What is your stance towards using inspectors to quickly check identity, regarding ByteString? Note: to make this practical, one needs to turn on the "Reuse windows" preference.
Example workflow: 1. Expression print-it. 2. "Oh I have seen this string before, is it the same instance or another one?" 3. (Click on the result to open the inspector on the result object.) 4. Open an inspector on the other, previously encountered occurrence of the string (might be in another tool). If a second inspector appears, these are two distinct String instances.
To further motivate the question in 2., imagine that this ByteString is big, say, a several hundred MB CLOB. :-)
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel :
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph :
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel :
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi all,
So visual consistency for Christoph means: all results are highlighted(/click-inspectable). Whereas for Marcel it means: all complex/interesting results are highlighted/click-inspectable.
What does everyone else think about this?
I sometimes wish that the print-it results in the workspace would be treated differently than the text that I typed myself. Highlighting them (link or otherwise) could help to spot the frontier between expression and result after some more actions, but would otherwise not help me much. When I intended to use the printed result in my next expression, highlighting it as a result would be inappropriate, but I rarely ever want to do this. For most complex objects, this is not even possible because their print strings are not Smalltalk expressions. But I cannot use a non-Smalltalk expression with a link on it in my next expression either, so the feature does not help me in that case anyway. (What I would rather need is a "put this into a variable" command, kind of a refactoring operation for the Workspace.) If I wanted to send further messages to a returned 'String' I would most likely move it onto its own line for convenient Cmd-p/i first anyway, I would not keep it to the right of the expression that evaluated to the 'String'.
With this reasoning, I would rather lean towards Christoph's interpretation now. (Also I believe it does not hurt so much if one can also inspect the primitive results.) But I have not used the feature in practice so far, so I will let some time pass for now.
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
You could also conduct/enforce an informal user study by just changing the decision in Trunk after a few months, and count the number of complaints before and after. ;-)
Am So., 25. Apr. 2021 um 19:43 Uhr schrieb Jakob Reschke jakres+squeak@gmail.com:
Hi all,
So visual consistency for Christoph means: all results are highlighted(/click-inspectable). Whereas for Marcel it means: all complex/interesting results are highlighted/click-inspectable.
What does everyone else think about this?
I sometimes wish that the print-it results in the workspace would be treated differently than the text that I typed myself. Highlighting them (link or otherwise) could help to spot the frontier between expression and result after some more actions, but would otherwise not help me much. When I intended to use the printed result in my next expression, highlighting it as a result would be inappropriate, but I rarely ever want to do this. For most complex objects, this is not even possible because their print strings are not Smalltalk expressions. But I cannot use a non-Smalltalk expression with a link on it in my next expression either, so the feature does not help me in that case anyway. (What I would rather need is a "put this into a variable" command, kind of a refactoring operation for the Workspace.) If I wanted to send further messages to a returned 'String' I would most likely move it onto its own line for convenient Cmd-p/i first anyway, I would not keep it to the right of the expression that evaluated to the 'String'.
With this reasoning, I would rather lean towards Christoph's interpretation now. (Also I believe it does not hurt so much if one can also inspect the primitive results.) But I have not used the feature in practice so far, so I will let some time pass for now.
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi all,
please note that "CMD+0" will immediately remove that text action after the print-it (CMD+P) if you want to use it for something else. :-)
Best, Marcel Am 25.04.2021 19:43:40 schrieb Jakob Reschke jakres+squeak@gmail.com: Hi all,
So visual consistency for Christoph means: all results are highlighted(/click-inspectable). Whereas for Marcel it means: all complex/interesting results are highlighted/click-inspectable.
What does everyone else think about this?
I sometimes wish that the print-it results in the workspace would be treated differently than the text that I typed myself. Highlighting them (link or otherwise) could help to spot the frontier between expression and result after some more actions, but would otherwise not help me much. When I intended to use the printed result in my next expression, highlighting it as a result would be inappropriate, but I rarely ever want to do this. For most complex objects, this is not even possible because their print strings are not Smalltalk expressions. But I cannot use a non-Smalltalk expression with a link on it in my next expression either, so the feature does not help me in that case anyway. (What I would rather need is a "put this into a variable" command, kind of a refactoring operation for the Workspace.) If I wanted to send further messages to a returned 'String' I would most likely move it onto its own line for convenient Cmd-p/i first anyway, I would not keep it to the right of the expression that evaluated to the 'String'.
With this reasoning, I would rather lean towards Christoph's interpretation now. (Also I believe it does not hurt so much if one can also inspect the primitive results.) But I have not used the feature in practice so far, so I will let some time pass for now.
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel :
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph :
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel :
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi Marcel,
I would expect that, in such a scenario, print-it would rarely be used.
You are arguing from the status quo where printed-it (print-itted?) results are effectively lost for further observation. With the new attribute, a workflow no longer needs to make this assumption. I would rather think of these attributes as notebook-like cell outputs. Unless a user wants to reuse the result in another expression from within the same text field, he or she is not required to use any variables at all. In contexts without workspace bindings (such as inspectors), this is even the only way now to persist object results. Thus, speaking generally, users could indeed rely on print-its for costly operations as of now. :-)
Hmmm... we might want to remove that interactive print-it text after the user has clicked on it :-)
Please don't introduce self-destroying objects in Squeak! :-)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 26. April 2021 18:53:40 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi all,
please note that "CMD+0" will immediately remove that text action after the print-it (CMD+P) if you want to use it for something else. :-)
Best, Marcel
Am 25.04.2021 19:43:40 schrieb Jakob Reschke jakres+squeak@gmail.com:
Hi all,
So visual consistency for Christoph means: all results are highlighted(/click-inspectable). Whereas for Marcel it means: all complex/interesting results are highlighted/click-inspectable.
What does everyone else think about this?
I sometimes wish that the print-it results in the workspace would be treated differently than the text that I typed myself. Highlighting them (link or otherwise) could help to spot the frontier between expression and result after some more actions, but would otherwise not help me much. When I intended to use the printed result in my next expression, highlighting it as a result would be inappropriate, but I rarely ever want to do this. For most complex objects, this is not even possible because their print strings are not Smalltalk expressions. But I cannot use a non-Smalltalk expression with a link on it in my next expression either, so the feature does not help me in that case anyway. (What I would rather need is a "put this into a variable" command, kind of a refactoring operation for the Workspace.) If I wanted to send further messages to a returned 'String' I would most likely move it onto its own line for convenient Cmd-p/i first anyway, I would not keep it to the right of the expression that evaluated to the 'String'.
With this reasoning, I would rather lean towards Christoph's interpretation now. (Also I believe it does not hurt so much if one can also inspect the primitive results.) But I have not used the feature in practice so far, so I will let some time pass for now.
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel :
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph :
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel :
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi Christoph.
With the new attribute, a workflow no longer needs to make this assumption.
I am not talking about changing people. I hypothesized existing workflows. :-) What are people doing now and how can we avoid disrupting existing knowledge and expectations. Well, I am trying to treat this as a new feature, knowing that you have been using it for quite some time now. Any statistics on clicking on ByteStrings?
Please don't introduce self-destroying objects in Squeak! :-)
Who would ever want to keep the browser open after saving that source code? What's done is done. :-D
Best, Marcel Am 26.04.2021 20:28:21 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
I would expect that, in such a scenario, print-it would rarely be used.
You are arguing from the status quo where printed-it (print-itted?) results are effectively lost for further observation. With the new attribute, a workflow no longer needs to make this assumption. I would rather think of these attributes as notebook-like cell outputs. Unless a user wants to reuse the result in another expression from within the same text field, he or she is not required to use any variables at all. In contexts without workspace bindings (such as inspectors), this is even the only way now to persist object results. Thus, speaking generally, users could indeed rely on print-its for costly operations as of now. :-)
Hmmm... we might want to remove that interactive print-it text after the user has clicked on it :-)
Please don't introduce self-destroying objects in Squeak! :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 26. April 2021 18:53:40 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all,
please note that "CMD+0" will immediately remove that text action after the print-it (CMD+P) if you want to use it for something else. :-)
Best, Marcel Am 25.04.2021 19:43:40 schrieb Jakob Reschke jakres+squeak@gmail.com: Hi all,
So visual consistency for Christoph means: all results are highlighted(/click-inspectable). Whereas for Marcel it means: all complex/interesting results are highlighted/click-inspectable.
What does everyone else think about this?
I sometimes wish that the print-it results in the workspace would be treated differently than the text that I typed myself. Highlighting them (link or otherwise) could help to spot the frontier between expression and result after some more actions, but would otherwise not help me much. When I intended to use the printed result in my next expression, highlighting it as a result would be inappropriate, but I rarely ever want to do this. For most complex objects, this is not even possible because their print strings are not Smalltalk expressions. But I cannot use a non-Smalltalk expression with a link on it in my next expression either, so the feature does not help me in that case anyway. (What I would rather need is a "put this into a variable" command, kind of a refactoring operation for the Workspace.) If I wanted to send further messages to a returned 'String' I would most likely move it onto its own line for convenient Cmd-p/i first anyway, I would not keep it to the right of the expression that evaluated to the 'String'.
With this reasoning, I would rather lean towards Christoph's interpretation now. (Also I believe it does not hurt so much if one can also inspect the primitive results.) But I have not used the feature in practice so far, so I will let some time pass for now.
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel :
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph :
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel :
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Any statistics on clicking on ByteStrings?
Not yet. A Trunk-wide telemetry program might help. :-) Apart from that, I think that I would use the feature more often if it was accessible via keyboard.
Who would ever want to keep the browser open after saving that source code? What's done is done. :-D
Not if you work in short feedback cycles, I guess ... ("Inspect - not what I wanted - close again. Think two seconds - no, I need this indeed - inspect again". Also known as "fiddling around". I do this very often ...)
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 27. April 2021 16:59:12 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph.
With the new attribute, a workflow no longer needs to make this assumption.
I am not talking about changing people. I hypothesized existing workflows. :-) What are people doing now and how can we avoid disrupting existing knowledge and expectations. Well, I am trying to treat this as a new feature, knowing that you have been using it for quite some time now. Any statistics on clicking on ByteStrings?
Please don't introduce self-destroying objects in Squeak! :-)
Who would ever want to keep the browser open after saving that source code? What's done is done. :-D
Best, Marcel
Am 26.04.2021 20:28:21 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Marcel,
I would expect that, in such a scenario, print-it would rarely be used.
You are arguing from the status quo where printed-it (print-itted?) results are effectively lost for further observation. With the new attribute, a workflow no longer needs to make this assumption. I would rather think of these attributes as notebook-like cell outputs. Unless a user wants to reuse the result in another expression from within the same text field, he or she is not required to use any variables at all. In contexts without workspace bindings (such as inspectors), this is even the only way now to persist object results. Thus, speaking generally, users could indeed rely on print-its for costly operations as of now. :-)
Hmmm... we might want to remove that interactive print-it text after the user has clicked on it :-)
Please don't introduce self-destroying objects in Squeak! :-)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 26. April 2021 18:53:40 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi all,
please note that "CMD+0" will immediately remove that text action after the print-it (CMD+P) if you want to use it for something else. :-)
Best, Marcel
Am 25.04.2021 19:43:40 schrieb Jakob Reschke jakres+squeak@gmail.com:
Hi all,
So visual consistency for Christoph means: all results are highlighted(/click-inspectable). Whereas for Marcel it means: all complex/interesting results are highlighted/click-inspectable.
What does everyone else think about this?
I sometimes wish that the print-it results in the workspace would be treated differently than the text that I typed myself. Highlighting them (link or otherwise) could help to spot the frontier between expression and result after some more actions, but would otherwise not help me much. When I intended to use the printed result in my next expression, highlighting it as a result would be inappropriate, but I rarely ever want to do this. For most complex objects, this is not even possible because their print strings are not Smalltalk expressions. But I cannot use a non-Smalltalk expression with a link on it in my next expression either, so the feature does not help me in that case anyway. (What I would rather need is a "put this into a variable" command, kind of a refactoring operation for the Workspace.) If I wanted to send further messages to a returned 'String' I would most likely move it onto its own line for convenient Cmd-p/i first anyway, I would not keep it to the right of the expression that evaluated to the 'String'.
With this reasoning, I would rather lean towards Christoph's interpretation now. (Also I believe it does not hurt so much if one can also inspect the primitive results.) But I have not used the feature in practice so far, so I will let some time pass for now.
Kind regards, Jakob
Am Sa., 24. Apr. 2021 um 17:43 Uhr schrieb Marcel Taeumel :
Hi Jakob,
thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.
Hey Christoph,
a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.
I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. People might think they found something interesting -- to then be disappointed that it is just a flat string.
Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?
Hi all,
here is again the list of objects I think we should exclude from having a text action on their print-it result:
ByteString ByteSymbol Number Boolean UndefinedObject
If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)
Reducing visual clutter is worth a few lines of extra source code.
Best, Marcel
Am 24.04.2021 15:42:08 schrieb Thiede, Christoph :
Hi Jakob, Hi Marcel,
thank you for reviving this discussion! :-)
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
Definitively also the latter.
While the type check might not be really necessary, avoiding visual clutter can be a good thing.
-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue, and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.
This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...
Best, Christoph
Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Samstag, 24. April 2021 11:43:06 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz
Hi Christoph, hi Marcel,
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel :
Hi Christoph,
[...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.
I am struggling to understand how your arguments address each other person's concerns. Did I understand your points correctly:
- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want to get the link. For example, MCVersionName loses its type information when printed, so when you would inspect the result, you would get a String instead of an MCVersionName. The other example is when you want to track identity. Indeed, sometimes it is useful to check whether one String is the same as another one retrieved (inspected) from somewhere else. I do this regularly in Squot when debugging the capturing and materialization (although seldom for Strings at this time because for these it already works as expected).
- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond just looking at the print string. Supposedly, one can just reevaluate the result or the expression. Adding the links there produces visual clutter and is distracting. Inspecting an MCVersionName would reveal no further information about the object than the print string does (that is, except for the type!).
Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")
I fully agree with Marcel on the immediates and singletons (true, false, nil, Symbols). While the type check might not be really necessary, avoiding visual clutter can be a good thing. Tradeoff is with having the special case in the code.
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value objects, since they are mutable, can be used as buffers, etc. Depends on the application.
On the other hand, Points are mostly used as value objects, but did not get the special case treatment. Though strictly, technically speaking, they are not different from Strings in this regard.
Inspecting the result string or the revaluating the original expression to do so is only safe if it does not provoke side effects. For Marcel's selection of classes, there are no side effects of reevaluating the result string. But reevaluating the original expression might not be free of side effects. I guess you would not reevaluate the expression to inspect an immediate or singleton, but for those objects that do have object identity, such as Strings, or where the type of the result is not obvious, MCVersionName, you might want to do that.
How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue. Then there would be no visual clutter, and if you know that the feature is there (and you have subsequently turned off the preference, for example), you would also not easily forget that you can use it.
Kind regards, Jakob
Hi Subbu.
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
All objects are "inspectable." I am talking about a language-specific configuration (or tweak?) for that interactive inspection feature.
I argue for this small list of exceptions also because I think that this list is unlikely to change in the near future.
Best, Marcel Am 19.04.2021 18:23:37 schrieb K K Subbu kksubbu.ml@gmail.com: All,
How about:
Object>>isInspectable ^true ByteString>>isInspectable ^false Number>>isInspectable ^false ...
so inspectors can skip unitary objects?
Just a thought .. Subbu
On 19/04/21 8:36 pm, Marcel Taeumel wrote:
Hi Christoph, hi all.
I think that we should not highlight the following kinds of Objects to reserve this feature for really interesting structures that are worth inspecting without an extra evaluate. The kinds to ignore are:
ByteString ByteSymbol Number Boolean UndefinedObject
So, we can use both (1) visuals and (2) interactivity to let the more complex objects say: "Hey, I have interesting structure! Did you mix up print-it with inspect-it? No worries, just click on me."
This effect will not be if any stoopid literal gets this treatment. :-)
Best, Marcel
Am 19.04.2021 13:21:53 schrieb Thiede, Christoph :
Hi Marcel,
I still stumble upon this edge case for some print-it results that do not support click-to-inspect. Why do we need this exception? :-)
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine.
I don't think it looks fine, why do you think so? :-)
Best, Christoph
*Von:* Squeak-dev im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 19:52:16 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi Christoph,
I think that this clickable link is a compromise between printString and storeString. For mouse navigation, you can always choose "inspect it" from the context menu on that text selection. ;-) I also found the link color annyoing for simple literals.
Also consider this snippet where the print-link does not exist for
an MCVersionName
Looks fine. ^__^ I am certain that we will collect more feedback on this feature during the next weeks and months. Let's refine it then.
Best, Marcel
Am 16.04.2021 18:39:10 schrieb Thiede, Christoph :
Hi Marcel, it's great that you have found a solution to this idea! :-)
+ ^ (self class interactivePrintIt and: [(anObject isString
or: [anObject isNumber]) not])
Is this necessary? I know that an inspector for a literal object like these does not make great sense, but this just feels like an unnecessary heuristic and limitation for me and adds complexity. I would like to be able to open an inspector always. Also consider this snippet where the print-link does not exist for an MCVersionName: :-)
MCRepository inbox allFileNames first
CI scripts will default to "true".
Unfortunately, no, mine just timed out while preparing the image. Also, my server images for @SqueakSmalltalkBot were interrupted. I'd opt for keeping preamble/postscript content in the update stream strictly non-interactive. :-)
Best,
Christoph
*Von:* Squeak-dev im Auftrag von Taeumel, Marcel *Gesendet:* Freitag, 16. April 2021 17:27:54 *An:* squeak-dev *Betreff:* Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz Hi all!
It is now in Trunk. You can opt-out via the preference browser. Still, you will be asked the first time when you update your image. CI scripts will default to "true".
Best, Marcel
Am 17.11.2019 17:36:11 schrieb Jakob Reschke :
Thiede, Christoph
schrieb am
Fr., 15. Nov. 2019, 09:38:
Just another idea (I seem to have too many of them :D): Some kind of UnderlyingObjectAttribute (with a better name, of course) an editor can check the selection before compiling it when inspectIt/exploreIt is pressed?
Example 1: ('2 + 3' asText) -> User presses inspectIt -> Editor checks for UnderylingObjectAttribute -> none found, so the string is compilaed as usual.
Example 2: (Text string: '2 + 3' attributes: (UnderylingObjectAttribute for: 5)) -> User presses inspectIt -> Editor finds an UnderylingObjectAttribute -> instead of compiling the selection, the cached result is reused for the inspector.
We would not even need to display this Attribute visually if it works reliably.
Make sure it is transient in some way because it would be quite annoying if the hidden object were out of date with regards to the text.
squeak-dev@lists.squeakfoundation.org