[Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model
Status: Accepted Owner: guillermopolito New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 The accessor should be added to load last version of OCompletion in Core 1.2
Comment #1 on issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 Slice in the inbox: Name: SLICE-Issue-3385-TextEditor-doest-not-understand-model-GuillermoPolito.1 Author: GuillermoPolito Time: 7 December 2010, 3:01:23 pm UUID: c0ba6fe0-6c3a-e643-a568-76649f598ee9 Ancestors: Dependencies: System-Text-GuillermoPolito.116 Added accessor
Updates: Status: fixed Labels: Milestone-1.2 Comment #2 on issue 3385 by stephane.ducasse: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 (No comment was entered for this change.)
Comment #3 on issue 3385 by stephane.ducasse: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 I do not understand why this is the solution model: aModel ^model it looks like a hack
Updates: Status: Closed Comment #4 on issue 3385 by marcus.denker: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 I added an accessor 12273
Comment #5 on issue 3385 by rydier: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 Also see the ensuing discussion the commit message created on mailing list: http://forum.world.st/Issue-3385-in-pharo-TextEditor-doest-not-understand-mo... Should we create a new issue to find a better solution as discussed here for 1.3 rather than reopen this one?
Comment #6 on issue 3385 by marcus.denker: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 I would add a new bug entry...
On Tue, 7 Dec 2010, pharo@googlecode.com wrote:
Status: Accepted Owner: guillermopolito
New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385
The accessor should be added to load last version of OCompletion in Core 1.2
OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk code completion, while TextEditor is intended to be a text editor (ask Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and not to TextEditor. Levente
So Levente you're saying that given the following use case you musn't add #model to TextEditor but change TextEditor collaboration with an instance of SmalltalkEditor OCompletion works well to edit code in the system browser as is, the DNU occurs when as an example you do a class find (Cmd+f) on SystemBrowser and you start typing on that "Class name or fragment" window looking for something. Cheers, Francisco On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 7 Dec 2010, pharo@googlecode.com wrote:
Status: Accepted
Owner: guillermopolito
New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385
The accessor should be added to load last version of OCompletion in Core 1.2
OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk code completion, while TextEditor is intended to be a text editor (ask Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and not to TextEditor.
Levente
On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
So Levente you're saying that given the following use case you musn't add #model to TextEditor but change TextEditor collaboration with an instance of SmalltalkEditor
OCompletion works well to edit code in the system browser as is, the DNU occurs when as an example you do a class find (Cmd+f) on SystemBrowser and you start typing on that "Class name or fragment" window looking for something.
Adding the accessor is fine of course, it may be useful for other things too. I'm saying that OCompletion is intended to work in places where code completion is necessary and those places are usually SmalltalkEditors. There are two things to think about: - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor? Btw using the latest version of PharoCore (12271) I can't reproduce the error in the way you described it. Levente
Cheers, Francisco
On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 7 Dec 2010, pharo@googlecode.com wrote:
Status: Accepted
Owner: guillermopolito
New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385
The accessor should be added to load last version of OCompletion in Core 1.2
OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk code completion, while TextEditor is intended to be a text editor (ask Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and not to TextEditor.
Levente
I agree with Levente. The basic completion (cmd-q) is also only usable with a SmalltalkEditor. Cheers Alain Le 08/12/2010 03:58, Levente Uzonyi a écrit :
On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
So Levente you're saying that given the following use case you musn't add #model to TextEditor but change TextEditor collaboration with an instance of SmalltalkEditor
OCompletion works well to edit code in the system browser as is, the DNU occurs when as an example you do a class find (Cmd+f) on SystemBrowser and you start typing on that "Class name or fragment" window looking for something.
Adding the accessor is fine of course, it may be useful for other things too. I'm saying that OCompletion is intended to work in places where code completion is necessary and those places are usually SmalltalkEditors. There are two things to think about: - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor?
Btw using the latest version of PharoCore (12271) I can't reproduce the error in the way you described it.
Levente
Cheers, Francisco
On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 7 Dec 2010, pharo@googlecode.com wrote:
Status: Accepted
Owner: guillermopolito
New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385
The accessor should be added to load last version of OCompletion in Core 1.2
OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk code completion, while TextEditor is intended to be a text editor (ask Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and not to TextEditor.
Levente
Levente, that's weird, i'm sending you a screenshot i'm running PharoCore 12271 with Ocompletion-ul.88 loaded I really like how you clear the way with these two questions, - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor? Using OCompletion is ok i think, in another email i said that having two way autocompletion with the TextEditor element and the recent WHATEVER used list above dont make sense to me, but some argue that they use their mouse to go to a recently used class. i think the finder window should be minimal, just the input text element -no recent used list- and have autocompletion (ie. web autocompletion). As web users we see that a lot, i will not miss the recent WHATEVER list. On your second question, imho we're trying to find a Smalltalk class or Smalltalk WHATEVER, could be better to have a SmalltalkEditor instance instead of TextEditor one. Cheers, Francisco [image: PharoScreenshot.1.png] On Wed, Dec 8, 2010 at 4:20 AM, Alain Plantec <alain.plantec@free.fr> wrote:
I agree with Levente. The basic completion (cmd-q) is also only usable with a SmalltalkEditor. Cheers Alain
Le 08/12/2010 03:58, Levente Uzonyi a écrit :
On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
So Levente you're saying that given the following use case you musn't add
#model to TextEditor but change TextEditor collaboration with an instance of SmalltalkEditor
OCompletion works well to edit code in the system browser as is, the DNU occurs when as an example you do a class find (Cmd+f) on SystemBrowser and you start typing on that "Class name or fragment" window looking for something.
Adding the accessor is fine of course, it may be useful for other things too. I'm saying that OCompletion is intended to work in places where code completion is necessary and those places are usually SmalltalkEditors. There are two things to think about: - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor?
Btw using the latest version of PharoCore (12271) I can't reproduce the error in the way you described it.
Levente
Cheers, Francisco
On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 7 Dec 2010, pharo@googlecode.com wrote:
Status: Accepted
Owner: guillermopolito
New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385
The accessor should be added to load last version of OCompletion in Core 1.2
OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk code completion, while TextEditor is intended to be a text editor (ask Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and not to TextEditor.
Levente
On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
Levente,
that's weird, i'm sending you a screenshot i'm running PharoCore 12271 with Ocompletion-ul.88 loaded
Right, I forgot to change the ToolSet to ECToolSet. Now I see the problem.
I really like how you clear the way with these two questions, - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor?
Using OCompletion is ok i think, in another email i said that having two way autocompletion with the TextEditor element and the recent WHATEVER used list above dont make sense to me, but some argue that they use their mouse to go to a recently used class.
i think the finder window should be minimal, just the input text element -no recent used list- and have autocompletion (ie. web autocompletion). As web users we see that a lot, i will not miss the recent WHATEVER list.
A big +1 (note that I'm not a Pharo user). If there's need for the recent classes, then it should be available via a different menu item + shortcut.
On your second question, imho we're trying to find a Smalltalk class or Smalltalk WHATEVER, could be better to have a SmalltalkEditor instance instead of TextEditor one.
If the idea is to keep this tool this way (recent classes list + no autocompleter), then I'd probably change it to SmalltalkEditor. But adding the method #model to TextMorph will "fix" this problem anyway. Levente
Cheers, Francisco
[image: PharoScreenshot.1.png]
On Wed, Dec 8, 2010 at 4:20 AM, Alain Plantec <alain.plantec@free.fr> wrote:
I agree with Levente. The basic completion (cmd-q) is also only usable with a SmalltalkEditor. Cheers Alain
Le 08/12/2010 03:58, Levente Uzonyi a écrit :
On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
So Levente you're saying that given the following use case you musn't add
#model to TextEditor but change TextEditor collaboration with an instance of SmalltalkEditor
OCompletion works well to edit code in the system browser as is, the DNU occurs when as an example you do a class find (Cmd+f) on SystemBrowser and you start typing on that "Class name or fragment" window looking for something.
Adding the accessor is fine of course, it may be useful for other things too. I'm saying that OCompletion is intended to work in places where code completion is necessary and those places are usually SmalltalkEditors. There are two things to think about: - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor?
Btw using the latest version of PharoCore (12271) I can't reproduce the error in the way you described it.
Levente
Cheers, Francisco
On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 7 Dec 2010, pharo@googlecode.com wrote:
Status: Accepted
Owner: guillermopolito
New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385
The accessor should be added to load last version of OCompletion in Core 1.2
OCompletion shouldn't be used in a TextEditor. OCompletion is for Smalltalk code completion, while TextEditor is intended to be a text editor (ask Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and not to TextEditor.
Levente
I agree with everyone in that OCompletion makes non sense with TextEditor. How can we make it work with SmalltalkEditor and avoid the case in the screenshot of Francisco? I can help you if you need it :). Cheers, Guille 2010/12/8 Levente Uzonyi <leves@elte.hu>
On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
Levente,
that's weird, i'm sending you a screenshot i'm running PharoCore 12271 with Ocompletion-ul.88 loaded
Right, I forgot to change the ToolSet to ECToolSet. Now I see the problem.
I really like how you clear the way with these two questions, - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor?
Using OCompletion is ok i think, in another email i said that having two way autocompletion with the TextEditor element and the recent WHATEVER used list above dont make sense to me, but some argue that they use their mouse to go to a recently used class.
i think the finder window should be minimal, just the input text element -no recent used list- and have autocompletion (ie. web autocompletion). As web users we see that a lot, i will not miss the recent WHATEVER list.
A big +1 (note that I'm not a Pharo user). If there's need for the recent classes, then it should be available via a different menu item + shortcut.
On your second question, imho we're trying to find a Smalltalk class or Smalltalk WHATEVER, could be better to have a SmalltalkEditor instance instead of TextEditor one.
If the idea is to keep this tool this way (recent classes list + no autocompleter), then I'd probably change it to SmalltalkEditor. But adding the method #model to TextMorph will "fix" this problem anyway.
Levente
Cheers, Francisco
[image: PharoScreenshot.1.png]
On Wed, Dec 8, 2010 at 4:20 AM, Alain Plantec <alain.plantec@free.fr> wrote:
I agree with Levente. The basic completion (cmd-q) is also only usable
with a SmalltalkEditor. Cheers Alain
Le 08/12/2010 03:58, Levente Uzonyi a écrit :
On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote:
So Levente you're saying that given the following use case you musn't add
#model to TextEditor but change TextEditor collaboration with an instance of SmalltalkEditor
OCompletion works well to edit code in the system browser as is, the DNU occurs when as an example you do a class find (Cmd+f) on SystemBrowser and you start typing on that "Class name or fragment" window looking for something.
Adding the accessor is fine of course, it may be useful for other things too. I'm saying that OCompletion is intended to work in places where code completion is necessary and those places are usually SmalltalkEditors. There are two things to think about: - should OCompletion be used in that panel? - should that panel use TextEditor instead of SmalltalkEditor?
Btw using the latest version of PharoCore (12271) I can't reproduce the error in the way you described it.
Levente
Cheers,
Francisco
On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 7 Dec 2010, pharo@googlecode.com wrote:
Status: Accepted
Owner: guillermopolito
New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385
The accessor should be added to load last version of OCompletion in Core 1.2
OCompletion shouldn't be used in a TextEditor. OCompletion is for
Smalltalk code completion, while TextEditor is intended to be a text editor (ask Juan). That's why OCompletion adds the model accessor to SmalltalkEditor and not to TextEditor.
Levente
participants (5)
-
Alain Plantec -
Francisco Ortiz Peñaloza -
Guillermo Polito -
Levente Uzonyi -
pharo＠googlecode.com