February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3707 in pharo: Syntax highlighting looks strange

by pharo＠googlecode.com

Comment #13 on issue 3707 by stephane...(a)gmail.com: Syntax highlighting looks strange http://code.google.com/p/pharo/issues/detail?id=3707 here is the one of 1.1 defaultStyleTable "color can be a valid argument to Color class>>colorFrom: , or nil to use the editor text color. Multiple emphases can be specified using an array e.g. #(bold italic). If emphasis is not specified, #normal will be used. if pixel height is not specified , then the editor font size will be used. " ^#( "(symbol color [emphasisSymbolOrArray [textStyleName [pixelHeight]]])" (default ( black ) ) (invalid ( red ) ) (excessCode ( red ) ) (comment ( green muchDarker ) ) (unfinishedComment ( green muchDarker ) ) (#'$' ( magenta muchDarker) ) (character ( magenta muchDarker) ) (integer ( magenta muchDarker) ) (number ( magenta muchDarker) ) (#- ( magenta muchDarker) ) (symbol ( magenta muchDarker) ) (stringSymbol ( magenta muchDarker) ) (literalArray ( magenta muchDarker) ) (string ( magenta muchDarker) ) (unfinishedString ( magenta muchDarker) ) (assignment ( black ) ) (ansiAssignment ( black ) ) (literal ( black ) ) (keyword ( black ) ) (binary ( black ) ) (unary ( black ) ) (incompleteKeyword ( black ) ) (incompleteBinary ( black ) ) (incompleteUnary ( black ) ) (undefinedKeyword ( red ) ) (undefinedBinary ( red ) ) (undefinedUnary ( red ) ) (patternKeyword ( black ) bold ) (patternBinary ( black ) bold ) (patternUnary ( black ) bold ) (#self ( cyan muchDarker ) ) (#super ( cyan muchDarker ) ) (#true ( cyan muchDarker ) ) (#false ( cyan muchDarker ) ) (#nil ( cyan muchDarker ) ) (#thisContext ( cyan muchDarker ) ) (#return ( black ) ) (patternArg ( blue muchDarker ) ) (methodArg ( blue muchDarker ) ) (blockPatternArg ( blue muchDarker ) ) (blockArg ( blue muchDarker ) ) (argument ( blue muchDarker ) ) (blockArgColon black ) (leftParenthesis black ) (rightParenthesis black ) (leftParenthesis1 black ) (rightParenthesis1 black ) (leftParenthesis2 black ) (rightParenthesis2 black ) (leftParenthesis3 black ) (rightParenthesis3 black ) (leftParenthesis4 black ) (rightParenthesis4 black ) (leftParenthesis5 black ) (rightParenthesis5 black ) (leftParenthesis6 black ) (rightParenthesis6 black ) (leftParenthesis7 black ) (rightParenthesis7 black ) (blockStart black ) (blockEnd black ) (blockStart1 black ) (blockEnd1 black ) (blockStart2 black ) (blockEnd2 black ) (blockStart3 black ) (blockEnd3 black ) (blockStart4 black ) (blockEnd4 black ) (blockStart5 black ) (blockEnd5 black ) (blockStart6 black ) (blockEnd6 black ) (blockStart7 black ) (blockEnd7 black ) (arrayStart black ) (arrayEnd black ) (arrayStart1 black ) (arrayEnd1 black ) (byteArrayStart black ) (byteArrayEnd black ) (byteArrayStart1 black ) (byteArrayEnd1 black ) (leftBrace black ) (rightBrace black ) (cascadeSeparator black ) (statementSeparator black ) (externalCallType black ) (externalCallTypePointerIndicator black ) (primitiveOrExternalCallStart black ) (primitiveOrExternalCallEnd black ) (methodTempBar black ) (blockTempBar black ) (blockArgsBar black ) (primitive gray ) (externalFunctionCallingConvention gray ) (module gray ) (blockTempVar ( blue muchDarker ) ) (blockPatternTempVar ( blue muchDarker ) ) (instVar ( blue muchDarker ) ) (workspaceVar ( blue muchDarker ) ) (undefinedIdentifier ( red ) ) (incompleteIdentifier ( blue muchDarker ) ) (tempVar ( blue muchDarker ) ) (patternTempVar ( blue muchDarker ) ) (poolConstant ( blue muchDarker ) ) (classVar ( blue muchDarker ) ) (globalVar ( blue muchDarker ) ) )

Feb. 26, 2011

Re: [Pharo-project] Issue 3707 in pharo: Syntax highlighting looks strange

by pharo＠googlecode.com

Updates: Status: Fixed Comment #12 on issue 3707 by stephane...(a)gmail.com: Syntax highlighting looks strange http://code.google.com/p/pharo/issues/detail?id=3707 So I would close this issue. I tried to reproduce the attached png and I cannot really see self. so cyan is not really adapted.

Feb. 26, 2011

Re: [Pharo-project] Issue 3707 in pharo: Syntax highlighting looks strange

by pharo＠googlecode.com

Comment #11 on issue 3707 by stephane...(a)gmail.com: Syntax highlighting looks strange http://code.google.com/p/pharo/issues/detail?id=3707 BTW the bold for the instance var is nice because you can see immediately if the class is doing an instance variable access. Finally I do not see why this would be a showstopper especially when there is a setting to change all these parameters. Looks is often quite personal.

Feb. 26, 2011

Re: [Pharo-project] Issue 3707 in pharo: Syntax highlighting looks strange

by pharo＠googlecode.com

Comment #10 on issue 3707 by stephane...(a)gmail.com: Syntax highlighting looks strange http://code.google.com/p/pharo/issues/detail?id=3707 marcus from which image did you do your screen shot? Because I tried with 1.0, 1.1 and pasted it in 1.2 but I do not get the same results. and even in 1.0, 1.1 the methods do not look the same as in yours.

Feb. 26, 2011

Re: [Pharo-project] Issue 3707 in pharo: Syntax highlighting looks strange

by pharo＠googlecode.com

Comment #9 on issue 3707 by stephane...(a)gmail.com: Syntax highlighting looks strange http://code.google.com/p/pharo/issues/detail?id=3707 SHTextStylerST80>>defaultStyleTable I'm currently checking 1.0 and 1.2

Feb. 26, 2011

Re: [Pharo-project] Do we want to integrate Keymappings? What's the way to follow? [WAS] More on Keymappings

by StÃ©phane Ducasse

yes we should fix all the senders first. Stef > Deprecating it should be the way i think. But we should take care with the senders, because it's very easy to break the text editors :P. > > On Sat, Feb 26, 2011 at 3:06 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sat, Feb 26, 2011 at 6:59 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Stef and everybody, > > I'd love to have it too, and I'd like to know what should a solution have to be integrated :). Should we integrate it in the core? or let it in the Dev? > > I know that a minimum solution should be to have this keymapper replace completely the old and hardcoded keymappings. Once it is integrated, it'll be easier to change and go on. > > > Exactly. I would do that: integrate a minimal core to replace old stuff and then load extensions in the dev image. > WHen you have such minimal code, with comments, tests, etc, maybe we can integrate it in 1.3 > > BTW, if you integrate such minmal core, the old core has to me removed? or it should be deprecated first? > > > Guille > > > On Sat, Feb 26, 2011 at 2:48 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks this is still on my todo to have a look at them. > I want a good keymapper in the system... :) > > Stef > > On Feb 26, 2011, at 5:42 AM, Guillermo Polito wrote: > > > What do we have now? > > > > - Can provide settings for a set of morphs > > > > - Can provide settings for a TextEditors (Smalltalk editor and related) > > > > - Settings integration > > I added some methods to the Settings Tree Builder in order to avoid references from the users code. > > > > - I ran Slint over it and cleaned it a lot more :). ( And learnt that Slint is there :P ) > > > > More info in here: http://guilleel3.blogspot.com/ > > > > Guille > > > > >

Feb. 26, 2011

Re: [Pharo-project] Do we want to integrate Keymappings? What's the way to follow? [WAS] More on Keymappings

by Guillermo Polito

Deprecating it should be the way i think. But we should take care with the senders, because it's very easy to break the text editors :P. On Sat, Feb 26, 2011 at 3:06 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Feb 26, 2011 at 6:59 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Stef and everybody, >> >> I'd love to have it too, and I'd like to know what should a solution have >> to be integrated :). Should we integrate it in the core? or let it in the >> Dev? >> >> I know that a minimum solution should be to have this keymapper replace >> completely the old and hardcoded keymappings. Once it is integrated, it'll >> be easier to change and go on. >> > > > Exactly. I would do that: integrate a minimal core to replace old stuff > and then load extensions in the dev image. > WHen you have such minimal code, with comments, tests, etc, maybe we can > integrate it in 1.3 > > BTW, if you integrate such minmal core, the old core has to me removed? or > it should be deprecated first? > > >> >> Guille >> >> >> On Sat, Feb 26, 2011 at 2:48 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Thanks this is still on my todo to have a look at them. >>> I want a good keymapper in the system... :) >>> >>> Stef >>> >>> On Feb 26, 2011, at 5:42 AM, Guillermo Polito wrote: >>> >>> > What do we have now? >>> > >>> > - Can provide settings for a set of morphs >>> > >>> > - Can provide settings for a TextEditors (Smalltalk editor and related) >>> > >>> > - Settings integration >>> > I added some methods to the Settings Tree Builder in order to avoid >>> references from the users code. >>> > >>> > - I ran Slint over it and cleaned it a lot more :). ( And learnt that >>> Slint is there :P ) >>> > >>> > More info in here: http://guilleel3.blogspot.com/ >>> > >>> > Guille >>> >>> >>> >> >

Feb. 26, 2011

Re: [Pharo-project] Issue 3762 in pharo: Refactor TextEditor >> dispatchOn:

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #1 on issue 3762 by stephane...(a)gmail.com: Refactor TextEditor >> dispatchOn: http://code.google.com/p/pharo/issues/detail?id=3762 tx camillo slices are easier for us because we can see them.

Feb. 26, 2011

Re: [Pharo-project] Fwd: [Metacello] Metacello 1.0-beta.28.3.1 released

by Guillermo Polito

Thanks Dale! :) On Sat, Feb 26, 2011 at 2:42 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > > Begin forwarded message: > > From: Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com>> > Date: February 25, 2011 9:12:04 PM PST > To: Metacello <metacello(a)googlegroups.com<mailto: > metacello(a)googlegroups.com>> > Subject: [Metacello] Metacello 1.0-beta.28.3.1 released > Reply-To: "metacello(a)googlegroups.com<mailto:metacello@googlegroups.com>" > <metacello(a)googlegroups.com<mailto:metacello@googlegroups.com>> > > Targeted at Pharo1.2 > > - fix Issue 3758: Metacello has 12 failing tests in 1.2 > http://code.google.com/p/pharo/issues/detail?id=3758 > - well ... add expectedFails for the tests are failing due to the fix > for Pharo Issue 3660 > > Dale > > >

Feb. 26, 2011

Re: [Pharo-project] Do we want to integrate Keymappings? What's the way to follow? [WAS] More on Keymappings

by Mariano Martinez Peck

On Sat, Feb 26, 2011 at 6:59 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Stef and everybody, > > I'd love to have it too, and I'd like to know what should a solution have > to be integrated :). Should we integrate it in the core? or let it in the > Dev? > > I know that a minimum solution should be to have this keymapper replace > completely the old and hardcoded keymappings. Once it is integrated, it'll > be easier to change and go on. > Exactly. I would do that: integrate a minimal core to replace old stuff and then load extensions in the dev image. WHen you have such minimal code, with comments, tests, etc, maybe we can integrate it in 1.3 BTW, if you integrate such minmal core, the old core has to me removed? or it should be deprecated first? > > Guille > > > On Sat, Feb 26, 2011 at 2:48 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Thanks this is still on my todo to have a look at them. >> I want a good keymapper in the system... :) >> >> Stef >> >> On Feb 26, 2011, at 5:42 AM, Guillermo Polito wrote: >> >> > What do we have now? >> > >> > - Can provide settings for a set of morphs >> > >> > - Can provide settings for a TextEditors (Smalltalk editor and related) >> > >> > - Settings integration >> > I added some methods to the Settings Tree Builder in order to avoid >> references from the users code. >> > >> > - I ran Slint over it and cleaned it a lot more :). ( And learnt that >> Slint is there :P ) >> > >> > More info in here: http://guilleel3.blogspot.com/ >> > >> > Guille >> >> >> >

Feb. 26, 2011