[squeak-dev] 'color print' option no longer works

> Ian Trudel wrote:
>>
>> Q: How customizable Shout is in term of colours and formatting?
>
> Plenty:
>
> 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           (red muchDarker)   italic)
>  (#'$'                  (red muchDarker)   )
>  (character                (red muchDarker)   )
>  (integer                  (red muchDarker)   )
>  (number                (red muchDarker)   )
>  (#-                    (red muchDarker)   )
>  (symbol                  (blue muchDarker)      )
>  (stringSymbol              (blue muchDarker)      )
>  (literalArray              (blue muchDarker)      )
>  (string                  (magenta muchDarker)  normal      'Accuny')
>  (unfinishedString            red      normal      'Accuny')
>  (assignment                nil      bold      'Accuny')
>  (ansiAssignment             nil      bold)
>  (literal                  nil      italic)
>  (keyword                (blue muchDarker)      )
>  (binary                 (blue muchDarker)      )
>  (unary                  (blue muchDarker)      )
>  (incompleteKeyword            (gray muchDarker)      underlined)
>  (incompleteBinary             (gray muchDarker)      underlined)
>  (incompleteUnary            (gray muchDarker)      underlined)
>  (undefinedKeyword            red      )
>  (undefinedBinary             red      )
>  (undefinedUnary            red      )
>  (patternKeyword             nil      )
>  (patternBinary               nil      )
>  (patternUnary              nil      )
>  (#self                   (red muchDarker)  )
>  (#super                  (red muchDarker)  )
>  (#true                   (red muchDarker)  )
>  (#false                   (red muchDarker)  )
>  (#nil                   (red muchDarker)  )
>  (#thisContext               (red muchDarker)  )
>  (#return                (red muchDarker)  )
>  (patternArg               (blue muchDarker)      )
>  (methodArg                 (blue muchDarker)      )
>  (blockPatternArg             (blue muchDarker)      )
>  (blockArg                 (blue muchDarker)      )
>  (argument                 (blue muchDarker)      )
>  (blockArgColon              black    )
>  (leftParenthesis              black    )
>  (rightParenthesis            black    )
>  (leftParenthesis1            (green muchDarker)    )
>  (rightParenthesis1            (green muchDarker)    )
>  (leftParenthesis2            (magenta muchDarker)    )
>  (rightParenthesis2            (magenta muchDarker)    )
>  (leftParenthesis3            (red muchDarker)    )
>  (rightParenthesis3            (red muchDarker)    )
>  (leftParenthesis4            (green darker)    )
>  (rightParenthesis4            (green darker)    )
>  (leftParenthesis5            (orange darker)    )
>  (rightParenthesis5            (orange darker)    )
>  (leftParenthesis6            (magenta darker)    )
>  (rightParenthesis6            (magenta darker)    )
>  (leftParenthesis7            blue    )
>  (rightParenthesis7            blue    )
>  (blockStart                 black    )
>  (blockEnd                 black    )
>  (blockStart1                (green muchDarker)      )
>  (blockEnd1                (green muchDarker)      )
>  (blockStart2                (magenta muchDarker)    )
>  (blockEnd2                (magenta muchDarker)    )
>  (blockStart3                (red muchDarker)    )
>  (blockEnd3                (red muchDarker)    )
>  (blockStart4                (green darker)    )
>  (blockEnd4                (green darker)    )
>  (blockStart5                (orange darker)    )
>  (blockEnd5                (orange darker)    )
>  (blockStart6                (magenta darker)    )
>  (blockEnd6                (magenta darker)    )
>  (blockStart7                blue    )
>  (blockEnd7                blue    )
>  (arrayStart                black    )
>  (arrayEnd                black    )
>  (arrayStart1              black    )
>  (arrayEnd1                black    )
>  (leftBrace                 black    )
>  (rightBrace                 black    )
>  (cascadeSeparator             black    )
>  (statementSeparator             black    )
>  (externalCallType             black    )
>  (externalCallTypePointerIndicator     black    )
>  (primitiveOrExternalCallStart       black    )
>  (primitiveOrExternalCallEnd        black    )
>  (methodTempBar              gray    )
>  (blockTempBar               gray    )
>  (blockArgsBar              gray    )
>  (primitive                (green muchDarker)    bold)
>  (externalFunctionCallingConvention    (green muchDarker)    bold)
>  (module                  (green muchDarker)    bold)
>  (blockTempVar               gray    )
>  (blockPatternTempVar          gray    )
>  (instVar                 black    )
>  (workspaceVar              black    bold)
>  (undefinedIdentifier            red      )
>  (incompleteIdentifier          (gray darker)   (italic underlined))
>  (tempVar                (gray darker)  )
>  (patternTempVar            (gray darker)  )
>  (poolConstant              (gray muchDarker)  )
>  (classVar                (gray muchDarker)  )
>  (globalVar                black    bold) )
>
>
>

> The problem appears to be that Eliot has been using Shout for  
> formatting / displaying colorized Smalltalk code. Which makes good  
> sense since it avoids code duplication and gives us more options on  
> customizing the result.
>
> But it does lead to the same question that I raised earlier: Should  
> we include Shout by default? It is small, it gives us syntax  
> highlighting, prettty printing and other advantages. I would be  
> propose to trade services for it to keep the core image small and to  
> the point, but that's just my opinion.
>
> Comments welcome.

> Ah. I think I wasn't clear here. The goal is to provide syntax  
> highlighting hooks directly in SmalltalkEditor (see the earlier  
> discussion about the SmalltalkEditor/TextEditor distinction). These  
> hooks just happen to look a lot like the extension methods Shout  
> uses today ;-) But by the end of the day, all you will need from  
> Shout are the categories Shout-Parsing and Shout-Styling and you  
> will get highlighting without extra dependencies. If you happen to  
> write an alternative package that can be utilized with the same  
> protocol you will be able to hook this in seamlessly. And if you  
> think that syntax highlighting is a waste of memory, you can just  
> unload Shout.

>
> On 15-Aug-09, at 8:56 PM, Andreas Raab wrote:
>
>> Ah. I think I wasn't clear here. The goal is to provide syntax  
>> highlighting hooks directly in SmalltalkEditor (see the earlier  
>> discussion about the SmalltalkEditor/TextEditor distinction). These  
>> hooks just happen to look a lot like the extension methods Shout  
>> uses today ;-) But by the end of the day, all you will need from  
>> Shout are the categories Shout-Parsing and Shout-Styling and you  
>> will get highlighting without extra dependencies. If you happen to  
>> write an alternative package that can be utilized with the same  
>> protocol you will be able to hook this in seamlessly. And if you  
>> think that syntax highlighting is a waste of memory, you can just  
>> unload Shout.
>
> Aha! In that case, thumbs up. I'm definitely happy about the  
> TextEditor/SmalltalkEditor/MVC-removal work that's been happening,  
> and this would make a fine addition to it.

>> Great questions. I've been waiting for people to propose things  
>> they'd like to see in Squeak (assuming that they are also willing  
>> to work on them). And although I think we'd all like the image to  
>> get smaller, more compact and simpler, I don't think we should  
>> exclude anything before discussing it concretely. So yeah, I'd  
>> think that if people have stuff that is broadly desirable, please  
>> do put it forward.
>
> Ok, sounds good. "Let's discuss it" is usually a pretty good  
> policy. :-)

> Ah. I think I wasn't clear here. The goal is to provide syntax
> highlighting hooks directly in SmalltalkEditor (see the earlier
> discussion about the SmalltalkEditor/TextEditor distinction). These
> hooks just happen to look a lot like the extension methods Shout uses
> today ;-) But by the end of the day, all you will need from Shout are
> the categories Shout-Parsing and Shout-Styling and you will get
> highlighting without extra dependencies. If you happen to write an
> alternative package that can be utilized with the same protocol you will
> be able to hook this in seamlessly. And if you think that syntax
> highlighting is a waste of memory, you can just unload Shout.

> On Tue, Aug 18, 2009 at 1:10 AM, Andreas Raab <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Andreas Raab wrote:
>
>         Ah. I think I wasn't clear here. The goal is to provide syntax
>         highlighting hooks directly in SmalltalkEditor (see the earlier
>         discussion about the SmalltalkEditor/TextEditor distinction).
>         These hooks just happen to look a lot like the extension methods
>         Shout uses today ;-) But by the end of the day, all you will
>         need from Shout are the categories Shout-Parsing and
>         Shout-Styling and you will get highlighting without extra
>         dependencies. If you happen to write an alternative package that
>         can be utilized with the same protocol you will be able to hook
>         this in seamlessly. And if you think that syntax highlighting is
>         a waste of memory, you can just unload Shout.
>
>
>     The hooks are now in place. If you update from the trunk, you can
>     load shout, it will work out of the box, and none of its extension
>     methods have any impact whatsoever (other than to litter your image
>     a little ;-) I'm lobbying Andy to make a release so that we can only
>     use the "core" pieces of shout (Shout-Parsing and Shout-Styling); as
>     soon as we got that we're ready to push shout into the trunk.
>
>     In case you're curious, I implemented this by adding a subtype to
>     the ToolBuilder text spec, a code pane spec. It's specific intent is
>     for code editing so it does by default use syntax highlighting (and
>     perhaps auto-completion and other purely coding-related facilities).
>     I also renamed some of the shout specific methods
>     (shoutAboutToStyle:) to just be called, e.g., #aboutToStyle: to
>     avoid conflicts with the extensions in Shout (these are installed
>     but not used if you're running trunk images).
>
>     So ... anyone having a good code completion handy?
>
>     Cheers,
>      - Andreas
>
>
>
> ------------------------------------------------------------------------
>
>