Preferences ignoreStyleIfOnlyBold

>
>
>
> On Fri, Jan 3, 2014 at 12:03 PM, Frank Shearar <[hidden email]>
> wrote:
>
>>
>> OK, so that's you & I in agreement. I think Colin's happy for it to
>> go. Any ol' timers out there with warnings of doom, before I rip this
>> out?
>
>
> No, I certainly wouldn't miss it.
>
> I will say this, however. I don't know if it goes all the way back to ST-80,
> but I do remember that styled code was considered important in the early
> days of Squeak. I seem to remember some tweaks to Monticello when it first
> came out that would allow it to store styled code the same way it's stored
> in the changes file. IIRC we even supported hyperlinks in code, although I
> don't remember actually seeing one in the wild.
>
> Therefore, we ought to decide if this is a change in policy—i.e., we're
> going to support plain-text source code only—or if we're just rejiggering
> preferences for better modularity. If it's a policy change, we have a free
> hand simplify the codebase accordingly, take styling commands out of code
> editors and so on. It doesn't have to be done right away, but let's consider
> that on the agenda for 4.6.
>
> On the other hand, if we consider styled source code important, we should
> figure out how to change the preferences to play nicely with Shout for those
> who use it, while still retaining the ability to manually style code and
> persist those styles along with the content of the code.
>
> Personally, I'd vote for plain-text only code. I can see the value of styled
> code, but that's not the way the world went, and it's no longer worth the
> complexity or friction when dealing with the world outside of the image.

> On Fri, Jan 3, 2014 at 12:03 PM, Frank Shearar
> <[hidden email]>wrote:
>
>
>> OK, so that's you & I in agreement. I think Colin's happy for it to
>> go. Any ol' timers out there with warnings of doom, before I rip this
>> out?
>
>
> No, I certainly wouldn't miss it.
>
> I will say this, however. I don't know if it goes all the way back to
> ST-80, but I do remember that styled code was considered important in the
> early days of Squeak. I seem to remember some tweaks to Monticello when it
> first came out that would allow it to store styled code the same way it's
> stored in the changes file. IIRC we even supported hyperlinks in code,
> although I don't remember actually seeing one in the wild.
>
> Therefore, we ought to decide if this is a change in policy—i.e., we're
> going to support plain-text source code only—or if we're just rejiggering
> preferences for better modularity. If it's a policy change, we have a free
> hand simplify the codebase accordingly, take styling commands out of code
> editors and so on. It doesn't have to be done right away, but let's
> consider that on the agenda for 4.6.
>
> On the other hand, if we consider styled source code important, we should
> figure out how to change the preferences to play nicely with Shout for
> those who use it, while still retaining the ability to manually style code
> and persist those styles along with the content of the code.
>
> Personally, I'd vote for plain-text only code. I can see the value of
> styled code, but that's not the way the world went, and it's no longer
> worth the complexity or friction when dealing with the world outside of
> the
> image.
>
> Colin
>
>

>
> On 03.01.2014, at 20:18, Chris Muller <[hidden email]> wrote:
>
>>>> OK, so that's you & I in agreement. I think Colin's happy for it to
>>>> go. Any ol' timers out there with warnings of doom, before I rip this
>>>> out?
>>>
>>> Just FYI: this makes it impossible to use/port CodeTalk[1] in/to
>>> Squeak 4.5.
>>> And I actually used it once or twice, not that this would be important :)
>>
>> Oh, that does matter.  Tobias, I think you're saying CodeTalk wants to
>> store Text into the .changes and possibly MC because that's where it
>> stores its code annotations.  Is that right?  But they don't actually
>> need that preference too do they?
>
> It just stores its information as text attributes, which then goes to
> the Changes file, IIRC.
> It has to patch monticello in order to save the information but that
> is independent of the style stuff.
>
> As a matter of fact, CodeTalk forces the Preference to be ON.

>> We should account for Robert Hirschfelds group which has put out some
>> great tools and projects.  CodeTalk wants to continue to push
>> Smalltalk ahead of the rest of the world still stuck in plain-text.
>>
>> So, based on this, I think we should not change policy w.r.t. storing
>> Text vs. Strings.  Text has #asString, so it doesn't seem there should
>> be any extra complexity to deal with the outside world; probably less
>> than trying to rip out something that's integrated and works.
>>
>
> Thanks.
>
> Best
>         -Tobias
>
>
>>> [1] https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/codetalk

> On 3 January 2014 19:32, Tobias Pape <[hidden email]> wrote:
>>
>> On 03.01.2014, at 20:18, Chris Muller <[hidden email]> wrote:
>>
>>>>> OK, so that's you & I in agreement. I think Colin's happy for it to
>>>>> go. Any ol' timers out there with warnings of doom, before I rip this
>>>>> out?
>>>>
>>>> Just FYI: this makes it impossible to use/port CodeTalk[1] in/to
>>>> Squeak 4.5.
>>>> And I actually used it once or twice, not that this would be important :)
>>>
>>> Oh, that does matter.  Tobias, I think you're saying CodeTalk wants to
>>> store Text into the .changes and possibly MC because that's where it
>>> stores its code annotations.  Is that right?  But they don't actually
>>> need that preference too do they?
>>
>> It just stores its information as text attributes, which then goes to
>> the Changes file, IIRC.
>> It has to patch monticello in order to save the information but that
>> is independent of the style stuff.
>>
>> As a matter of fact, CodeTalk forces the Preference to be ON.
>
> So effectively CodeTalk turns
>
> newText := (requestor notNil and: [Preferences confirmFirstUseOfStyle])
>     ifTrue: [aText askIfAddStyle: priorMethodOrNil req: requestor]
>     ifFalse: [aText]
>
> into aText?

>
> On 03.01.2014, at 20:36, Frank Shearar <[hidden email]> wrote:
>
>> On 3 January 2014 19:32, Tobias Pape <[hidden email]> wrote:
>>>
>>> On 03.01.2014, at 20:18, Chris Muller <[hidden email]> wrote:
>>>
>>>>>> OK, so that's you & I in agreement. I think Colin's happy for it to
>>>>>> go. Any ol' timers out there with warnings of doom, before I rip this
>>>>>> out?
>>>>>
>>>>> Just FYI: this makes it impossible to use/port CodeTalk[1] in/to
>>>>> Squeak 4.5.
>>>>> And I actually used it once or twice, not that this would be important :)
>>>>
>>>> Oh, that does matter.  Tobias, I think you're saying CodeTalk wants to
>>>> store Text into the .changes and possibly MC because that's where it
>>>> stores its code annotations.  Is that right?  But they don't actually
>>>> need that preference too do they?
>>>
>>> It just stores its information as text attributes, which then goes to
>>> the Changes file, IIRC.
>>> It has to patch monticello in order to save the information but that
>>> is independent of the style stuff.
>>>
>>> As a matter of fact, CodeTalk forces the Preference to be ON.
>>
>> So effectively CodeTalk turns
>>
>> newText := (requestor notNil and: [Preferences confirmFirstUseOfStyle])
>>    ifTrue: [aText askIfAddStyle: priorMethodOrNil req: requestor]
>>    ifFalse: [aText]
>>
>> into aText?
>>
>
> effectively.
>
>> Doing that means we can rip out #askIfAddStyle:req and Preferences
>> confirmFirstUseOfStyle. That would sever the Collections -> Tools
>> dependency, and would be a late Christmas treat for me.
>
> *g*
>
> but make sure there is an #asString before any of that enters the compiler.