Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-22 Thread Christophe Demarey

Le 22 sept. 2015 à 07:49, philippe.b...@highoctane.be a écrit :

> 
> Le 22 sept. 2015 07:40, "Sven Van Caekenberghe"  a écrit :
> >
> >
> > > On 21 Sep 2015, at 23:53, stepharo  wrote:
> > >
> > > I think that having metadata (style) language and data (source code) 
> > > mixed together is a bad idea.
> > > I never like the ]lang[ tag because it is a huge hack. It does not even 
> > > exist in the Smalltalk syntax!!!
> > > We save code that the parser cannot parse. What we fun idea.
> > > So people are bashing for backward compatibility and we remove a bad way 
> > > to encode
> > > metadata then suddenly it looks like we were doing something bad.
> > >
> > > Stef
> >
> > I am with Stef, it is a silly idea to mix the two. Nobody uses this in 
> > Pharo. Cleaning up means simplifying too.
> 
> In the code no. But in the comments, that would be good to have back. In 
> color form. As we can write pillar class comments, can't we render them ? 
> Moose as an editor/viewer for pillar files
> 
> 

Yes, it is where we want to go: use Pillar for styled comments.
Once we have that, we can remove Text styling from source code / comments.



smime.p7s
Description: S/MIME cryptographic signature


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-22 Thread Sven Van Caekenberghe

> On 22 Sep 2015, at 08:47, Christophe Demarey  
> wrote:
> 
> 
> Le 22 sept. 2015 à 07:49, philippe.b...@highoctane.be a écrit :
> 
>> 
>> Le 22 sept. 2015 07:40, "Sven Van Caekenberghe"  a écrit :
>> >
>> >
>> > > On 21 Sep 2015, at 23:53, stepharo  wrote:
>> > >
>> > > I think that having metadata (style) language and data (source code) 
>> > > mixed together is a bad idea.
>> > > I never like the ]lang[ tag because it is a huge hack. It does not even 
>> > > exist in the Smalltalk syntax!!!
>> > > We save code that the parser cannot parse. What we fun idea.
>> > > So people are bashing for backward compatibility and we remove a bad way 
>> > > to encode
>> > > metadata then suddenly it looks like we were doing something bad.
>> > >
>> > > Stef
>> >
>> > I am with Stef, it is a silly idea to mix the two. Nobody uses this in 
>> > Pharo. Cleaning up means simplifying too.
>> 
>> In the code no. But in the comments, that would be good to have back. In 
>> color form. As we can write pillar class comments, can't we render them ? 
>> Moose as an editor/viewer for pillar files
>> 
>> 
> 
> Yes, it is where we want to go: use Pillar for styled comments.
> Once we have that, we can remove Text styling from source code / comments.

Yes, inside a comment, which should be totally opaque from a language syntax 
standpoint, you can do whatever you want: HTML, Markdown, Pillar, Pier, ...





Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-22 Thread Tudor Girba
Hi,

I think that having Pillar in comments is definitely the way to go.

In:
http://www.humane-assessment.com/blog/writing-pillar-books-with-the-gtinspector

I show also an extension that renders comments with PIllar highlighting.
This is working now in an inspector, but the same principle can be applied
to other browsers.

Cheers,
Doru



On Tue, Sep 22, 2015 at 8:47 AM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

>
> Le 22 sept. 2015 à 07:49, philippe.b...@highoctane.be a écrit :
>
>
> Le 22 sept. 2015 07:40, "Sven Van Caekenberghe"  a écrit :
> >
> >
> > > On 21 Sep 2015, at 23:53, stepharo  wrote:
> > >
> > > I think that having metadata (style) language and data (source code)
> mixed together is a bad idea.
> > > I never like the ]lang[ tag because it is a huge hack. It does not
> even exist in the Smalltalk syntax!!!
> > > We save code that the parser cannot parse. What we fun idea.
> > > So people are bashing for backward compatibility and we remove a bad
> way to encode
> > > metadata then suddenly it looks like we were doing something bad.
> > >
> > > Stef
> >
> > I am with Stef, it is a silly idea to mix the two. Nobody uses this in
> Pharo. Cleaning up means simplifying too.
>
> In the code no. But in the comments, that would be good to have back. In
> color form. As we can write pillar class comments, can't we render them ?
> Moose as an editor/viewer for pillar files
>
>
> Yes, it is where we want to go: use Pillar for styled comments.
> Once we have that, we can remove Text styling from source code / comments.
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-22 Thread Thierry Goubier
2015-09-22 9:10 GMT+02:00 Sven Van Caekenberghe :

>
> > On 22 Sep 2015, at 08:47, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
> >
> >
> > Le 22 sept. 2015 à 07:49, philippe.b...@highoctane.be a écrit :
> >
> >>
> >> Le 22 sept. 2015 07:40, "Sven Van Caekenberghe"  a écrit
> :
> >> >
> >> >
> >> > > On 21 Sep 2015, at 23:53, stepharo  wrote:
> >> > >
> >> > > I think that having metadata (style) language and data (source
> code) mixed together is a bad idea.
> >> > > I never like the ]lang[ tag because it is a huge hack. It does not
> even exist in the Smalltalk syntax!!!
> >> > > We save code that the parser cannot parse. What we fun idea.
> >> > > So people are bashing for backward compatibility and we remove a
> bad way to encode
> >> > > metadata then suddenly it looks like we were doing something bad.
> >> > >
> >> > > Stef
> >> >
> >> > I am with Stef, it is a silly idea to mix the two. Nobody uses this
> in Pharo. Cleaning up means simplifying too.
> >>
> >> In the code no. But in the comments, that would be good to have back.
> In color form. As we can write pillar class comments, can't we render them
> ? Moose as an editor/viewer for pillar files
> >>
> >>
> >
> > Yes, it is where we want to go: use Pillar for styled comments.
> > Once we have that, we can remove Text styling from source code /
> comments.
>
> Yes, inside a comment, which should be totally opaque from a language
> syntax standpoint, you can do whatever you want: HTML, Markdown, Pillar,
> Pier, ...
>

But, if you want to integrate with IDE support for that extended syntax,
then it would be nice to have an idea of the syntax used... Otherwise we're
back at the special leading char to determine the format :(

Side opinion to come to the point: I think that Pillar would make a better
implementation than
the ]style[ stuff.

Thierry


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-22 Thread p...@highoctane.be
On Tue, Sep 22, 2015 at 9:13 AM, Tudor Girba  wrote:

> Hi,
>
> I think that having Pillar in comments is definitely the way to go.
>
> In:
>
> http://www.humane-assessment.com/blog/writing-pillar-books-with-the-gtinspector
>
> I show also an extension that renders comments with PIllar highlighting.
> This is working now in an inspector, but the same principle can be applied
> to other browsers.
>

Yes, that's what I tried in the past.
The ability to associate graphics explaining structures is really useful
there.

Phil

>
> Cheers,
> Doru
>
>
>
> On Tue, Sep 22, 2015 at 8:47 AM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>>
>> Le 22 sept. 2015 à 07:49, philippe.b...@highoctane.be a écrit :
>>
>>
>> Le 22 sept. 2015 07:40, "Sven Van Caekenberghe"  a écrit :
>> >
>> >
>> > > On 21 Sep 2015, at 23:53, stepharo  wrote:
>> > >
>> > > I think that having metadata (style) language and data (source code)
>> mixed together is a bad idea.
>> > > I never like the ]lang[ tag because it is a huge hack. It does not
>> even exist in the Smalltalk syntax!!!
>> > > We save code that the parser cannot parse. What we fun idea.
>> > > So people are bashing for backward compatibility and we remove a bad
>> way to encode
>> > > metadata then suddenly it looks like we were doing something bad.
>> > >
>> > > Stef
>> >
>> > I am with Stef, it is a silly idea to mix the two. Nobody uses this in
>> Pharo. Cleaning up means simplifying too.
>>
>> In the code no. But in the comments, that would be good to have back. In
>> color form. As we can write pillar class comments, can't we render them ?
>> Moose as an editor/viewer for pillar files
>>
>>
>> Yes, it is where we want to go: use Pillar for styled comments.
>> Once we have that, we can remove Text styling from source code / comments.
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-21 Thread Eliot Miranda
Hi Stef,

> On Sep 21, 2015, at 2:53 PM, stepharo  wrote:
> 
> I think that having metadata (style) language and data (source code) mixed 
> together is a bad idea.
> I never like the ]lang[ tag because it is a huge hack. It does not even exist 
> in the Smalltalk syntax!!!
> We save code that the parser cannot parse. What we fun idea.
> So people are bashing for backward compatibility and we remove a bad way to 
> encode
> metadata then suddenly it looks like we were doing something bad.

It seems to me you are confusing functionality and implementation.  Just 
because you don't like the implementation is no reason to lose the 
functionality.  No implementation is perfect, so this path leads to a denuded 
system.  The onus is on the community to reimplement things well, not throw 
things away just because the implementation is problematic.  If I had chosen to 
implement Cog with a much nicer substrate then neither Squeak, nor Pharo nor 
Newspeak would have been able to benefit.  Instead I was pragmatic and made 
sure Cig supported the existing requirements, not done platonic ideal.  I wish 
you would adopt as a principle that functionality be retained as you are 
cleaning up Pharo.  Instead I see useful fictional its discarded because if 
scruples and I find it "unpleasant".


_,,,^..^,,,_ (phone)

> 
> Stef
> 



Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-21 Thread Craig Latta

 (autocorrect-unmangled version... ;)

 Eliot writes:

> ...I was pragmatic and made sure Cog supported the existing
> requirements, not some platonic ideal.  I wish you would adopt as a
> principle that functionality be retained as you are cleaning up
> Pharo.  Instead I see useful functionality is discarded because of
> scruples and I find it "unpleasant".


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)




Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-21 Thread philippe.b...@highoctane.be
Le 22 sept. 2015 07:40, "Sven Van Caekenberghe"  a écrit :
>
>
> > On 21 Sep 2015, at 23:53, stepharo  wrote:
> >
> > I think that having metadata (style) language and data (source code)
mixed together is a bad idea.
> > I never like the ]lang[ tag because it is a huge hack. It does not even
exist in the Smalltalk syntax!!!
> > We save code that the parser cannot parse. What we fun idea.
> > So people are bashing for backward compatibility and we remove a bad
way to encode
> > metadata then suddenly it looks like we were doing something bad.
> >
> > Stef
>
> I am with Stef, it is a silly idea to mix the two. Nobody uses this in
Pharo. Cleaning up means simplifying too.

In the code no. But in the comments, that would be good to have back. In
color form. As we can write pillar class comments, can't we render them ?
Moose as an editor/viewer for pillar files.

Phil


>
>


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-21 Thread Sven Van Caekenberghe

> On 21 Sep 2015, at 23:53, stepharo  wrote:
> 
> I think that having metadata (style) language and data (source code) mixed 
> together is a bad idea.
> I never like the ]lang[ tag because it is a huge hack. It does not even exist 
> in the Smalltalk syntax!!!
> We save code that the parser cannot parse. What we fun idea.
> So people are bashing for backward compatibility and we remove a bad way to 
> encode
> metadata then suddenly it looks like we were doing something bad.
> 
> Stef

I am with Stef, it is a silly idea to mix the two. Nobody uses this in Pharo. 
Cleaning up means simplifying too.




Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-21 Thread stepharo
I think that having metadata (style) language and data (source code) 
mixed together is a bad idea.
I never like the ]lang[ tag because it is a huge hack. It does not even 
exist in the Smalltalk syntax!!!

We save code that the parser cannot parse. What we fun idea.
So people are bashing for backward compatibility and we remove a bad way 
to encode

metadata then suddenly it looks like we were doing something bad.

Stef



Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-14 Thread Martin Dias
On Tue, Sep 8, 2015 at 12:29 PM, Henrik Johansen
 wrote:
>
>> On 08 Sep 2015, at 11:03 , Martin Dias  wrote:
>>
>> On Sat, Sep 5, 2015 at 1:10 PM, Nicolai Hess  wrote:
>>> The same for the  ]lang[ tag (see issue 15750)
>>
>> Ok. But I still don't know how to add a url to a method's source code
>> or comment from the UI.
>>
>> I mean, people with a non-English keyboard can produce source code
>> with ]lang[, but how can I produce a ]style[ ?
>>
>> Martín
>
> The whole mechanism is quite broken in Pharo4 upwards:

Not sure what to do in Pharo: parse the Text or just ignore the
]style[, but at least file-in should not raise an error. I reported
it:

https://pharo.fogbugz.com/f/cases/16575/CodeImporter-doesn-t-parse-style-chunks

Martín



Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-08 Thread Eliot Miranda
Hi Martin,

Sent from my iPhone

> On Sep 5, 2015, at 3:06 AM, Martin Dias  wrote:
> 
> Hi all
> 
>> On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman  wrote:
>>> On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda  
>>> wrote:
>>> 
>>> On Sep 4, 2015, at 1:33 PM, stepharo  wrote:
>>> 
>>> Nobody defines urls in method comment anymore.
>>> 
>>> I do.  Several places in the Cog JIT contain irks to specification
>>> documents.  I don't care how its implemented (providing it's preserved in
>>> text, or maybe have the pretty-printer scan comments for http://.  But it is
>>> sad that we can't have hyperlinks in text.
>>> 
>>> Look I know the implementation stinks, but it can be fixed.  But if the
>>> functionality is lost the system is weakened.  Instead of asking what you
>>> can get rid if why not ask what you can reimplement or enhance more
>>> elegantly.
>> 
>> Its a reasonable strategy to start the discussion at the extreme end
>> and work back from there :) But if its being used we should think
>> harder about it.  What alternatives/workarounds are there?
>> 
>> First just to clarify, the aim is to remove Text from the image for
>> the boot-strap?
> 
> Yes :) I heard that we want to do cut the dependency to Text-Core, so
> I browsed how to do it.
> 
> Ben, there is an explanation about ]style[ in the class comment of 
> RemoteString.
> 
> Eliot, I didn't thought that somebody was using Text. In fact, I don't
> know how to do it in Pharo... how do you do?

I develop the VM in Squeak.  There's a menu pick in the squeak text editor that 
lets you do it.  In the hierarchy of emphasis types there's a class called 
something like TextURL.  I'll take a look soon and check.

> I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I
> just tested filing-in the attached .st file and it doesn't work. I
> guess the new CodeImporter replaced the ChangeRecord implementation,
> and it raises an error when ]style[.
> 
> Martín
> 
> 
>> 
>> 1. Save the text internally as a string in the stream format and
>> up-convert to Text only when its being displayed?  But I guess these
>> styles aren't restricted to just occurring in comments and maybe cause
>> problem for compilation ??
>> 
>> 2. As a stepping stone, introduce a TextPlaceholder class within
>> minimal interface required by compilation which simply strips out all
>> styles when Text is missing from the Image. When Text is present it
>> #becomes back to it.  Maybe risks loosing styles editing is done on
>> the raw-stream-format.  Maybe any editor would show the raw ]style[
>> and the compiler asks for #source which strips styles out.
>> 
>> 3. Introduce Pillar and convert across.  What are the requirements?
>>   a. URLs
>>   b. Class/method links
>>   c. Would you expect that Pillar can only appear in comments? Or
>> in-line with code?
>>   d. Colouring?
>>   ...?
>> 
>> btw, I haven't come across this before. Can someone point me to some
>> url & styled code where I can have a look at it
>> 
>> cheers -ben
>> 
>>> Christ you're even using minis paced fonts.  It's like the dark
>>> ages in there ;-)
>>> 
>>> In addition would prefer to have an explicit syntax as in Pillar or html to
>>> represent
>>> an hyperlink. We could have
>>>*Class>>#method* when pillar is not loaded and else a nicer
>>> representation.
>>> ctrl-click on a class should jump on it already and we could map it to
>>> *Class>>#method*
>>> 
>>> In class comments we should use pillar and get a real text renderer.
>>> 
>>> 
>>> Hi Martin,
>>> 
 On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias  wrote:
 
 Hi all,
 
 The source code of a method could be a Text, with TextAttributes. In such
 case, it will be written down to a stream with a "]style[" suffix. Through 
 a
 special parsing, the system can reconstruct the original Text. I think the
 use of Text in source code or class comments is discouraged, but I
 understand we kept support for some backward compatibility. Now, may be 
 it's
 time to remove this feature.
 
 With Pablo, we looked for uses of ]style[ in the .sources and .changes
 files of a new Pharo 5.0, and there are no real uses. It appears in some
 comments only, as examples.
 
 We tried to find past discussions about this feature, because we're sure
 there were, but we couldn't.
 
 So, the questions is:
 
   Can we remove support for text in source code or class comments in
 Pharo 5.0?
>>> 
>>> 
>>> IIUC, ]style[ also supports things like embedding URL links and method
>>> references in class comments.  So I would request that it /not/ be removed.
>>> It is very useful to put clickable links in class comments.
>>> 
 
 
 I think I can propose a slice.
 
 Regards,
 Martín
 PS: I was trying to cut dependencies of Text-Core with System-Changes and
 

Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-08 Thread Martin Dias
On Sat, Sep 5, 2015 at 1:10 PM, Nicolai Hess  wrote:
> The same for the  ]lang[ tag (see issue 15750)

Ok. But I still don't know how to add a url to a method's source code
or comment from the UI.

I mean, people with a non-English keyboard can produce source code
with ]lang[, but how can I produce a ]style[ ?

Martín

>
> 2015-09-05 12:06 GMT+02:00 Martin Dias :
>>
>> Hi all
>>
>> On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman  wrote:
>> > On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda 
>> > wrote:
>> >>
>> >> On Sep 4, 2015, at 1:33 PM, stepharo  wrote:
>> >>
>> >> Nobody defines urls in method comment anymore.
>> >>
>> >> I do.  Several places in the Cog JIT contain irks to specification
>> >> documents.  I don't care how its implemented (providing it's preserved
>> >> in
>> >> text, or maybe have the pretty-printer scan comments for http://.  But
>> >> it is
>> >> sad that we can't have hyperlinks in text.
>> >>
>> >> Look I know the implementation stinks, but it can be fixed.  But if the
>> >> functionality is lost the system is weakened.  Instead of asking what
>> >> you
>> >> can get rid if why not ask what you can reimplement or enhance more
>> >> elegantly.
>> >
>> > Its a reasonable strategy to start the discussion at the extreme end
>> > and work back from there :) But if its being used we should think
>> > harder about it.  What alternatives/workarounds are there?
>> >
>> > First just to clarify, the aim is to remove Text from the image for
>> > the boot-strap?
>>
>> Yes :) I heard that we want to do cut the dependency to Text-Core, so
>> I browsed how to do it.
>>
>> Ben, there is an explanation about ]style[ in the class comment of
>> RemoteString.
>>
>> Eliot, I didn't thought that somebody was using Text. In fact, I don't
>> know how to do it in Pharo... how do you do?
>> I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I
>> just tested filing-in the attached .st file and it doesn't work. I
>> guess the new CodeImporter replaced the ChangeRecord implementation,
>> and it raises an error when ]style[.
>>
>> Martín
>>
>>
>> >
>> > 1. Save the text internally as a string in the stream format and
>> > up-convert to Text only when its being displayed?  But I guess these
>> > styles aren't restricted to just occurring in comments and maybe cause
>> > problem for compilation ??
>> >
>> > 2. As a stepping stone, introduce a TextPlaceholder class within
>> > minimal interface required by compilation which simply strips out all
>> > styles when Text is missing from the Image. When Text is present it
>> > #becomes back to it.  Maybe risks loosing styles editing is done on
>> > the raw-stream-format.  Maybe any editor would show the raw ]style[
>> > and the compiler asks for #source which strips styles out.
>> >
>> > 3. Introduce Pillar and convert across.  What are the requirements?
>> >a. URLs
>> >b. Class/method links
>> >c. Would you expect that Pillar can only appear in comments? Or
>> > in-line with code?
>> >d. Colouring?
>> >...?
>> >
>> > btw, I haven't come across this before. Can someone point me to some
>> > url & styled code where I can have a look at it
>> >
>> > cheers -ben
>> >
>> >> Christ you're even using minis paced fonts.  It's like the dark
>> >> ages in there ;-)
>> >>
>> >> In addition would prefer to have an explicit syntax as in Pillar or
>> >> html to
>> >> represent
>> >> an hyperlink. We could have
>> >> *Class>>#method* when pillar is not loaded and else a nicer
>> >> representation.
>> >> ctrl-click on a class should jump on it already and we could map it to
>> >> *Class>>#method*
>> >>
>> >> In class comments we should use pillar and get a real text renderer.
>> >>
>> >>
>> >> Hi Martin,
>> >>
>> >> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias 
>> >> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> The source code of a method could be a Text, with TextAttributes. In
>> >>> such
>> >>> case, it will be written down to a stream with a "]style[" suffix.
>> >>> Through a
>> >>> special parsing, the system can reconstruct the original Text. I think
>> >>> the
>> >>> use of Text in source code or class comments is discouraged, but I
>> >>> understand we kept support for some backward compatibility. Now, may
>> >>> be it's
>> >>> time to remove this feature.
>> >>>
>> >>> With Pablo, we looked for uses of ]style[ in the .sources and .changes
>> >>> files of a new Pharo 5.0, and there are no real uses. It appears in
>> >>> some
>> >>> comments only, as examples.
>> >>>
>> >>> We tried to find past discussions about this feature, because we're
>> >>> sure
>> >>> there were, but we couldn't.
>> >>>
>> >>> So, the questions is:
>> >>>
>> >>>Can we remove support for text in source code or class comments in
>> >>> Pharo 5.0?
>> >>
>> >>
>> >> IIUC, ]style[ also supports things like embedding URL links and method
>> >> 

Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-08 Thread Nicolai Hess
2015-09-08 11:03 GMT+02:00 Martin Dias :

> On Sat, Sep 5, 2015 at 1:10 PM, Nicolai Hess  wrote:
> > The same for the  ]lang[ tag (see issue 15750)
>
> Ok. But I still don't know how to add a url to a method's source code
> or comment from the UI.
>
> I mean, people with a non-English keyboard can produce source code
> with ]lang[, but how can I produce a ]style[ ?
>

Hi Martin,

In squeak, you can open a "choose style" dialog (select some text and use
shortcut cmd+6).
This lets you choose a text color or text links.
For example, this is working in the class comment editor too, you can open
the comment for
class Morph, select a word like "Rectangle" and put a link to that class
definition.
This style attributes are first only  a part of the Text instance, but
saving or file out the class definition
will include this style attributes with the ]style[ tag.

Writing the style code text is not supported in pharo anymore.
Changing the style (color and text links) with cmd+6 does not work in
Rubrics text components anymore.
It is working with the old PluggableTextMorph (but only color attributes -
no links).

Reading Text with style attributes is still working in Pharo (only color
and emphasis, no text links).
For example, put this "styled" text in a Workspace and inspect it:

'Red Gree Blue!
]style[(3 1 4 1 4)f1cred;b,f1b,f1cgreen;b,f1b,f1cblue;b!' readStream
nextChunkText




>
> Martín
>
> >
> > 2015-09-05 12:06 GMT+02:00 Martin Dias :
> >>
> >> Hi all
> >>
> >> On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman  wrote:
> >> > On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda <
> eliot.mira...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Sep 4, 2015, at 1:33 PM, stepharo  wrote:
> >> >>
> >> >> Nobody defines urls in method comment anymore.
> >> >>
> >> >> I do.  Several places in the Cog JIT contain irks to specification
> >> >> documents.  I don't care how its implemented (providing it's
> preserved
> >> >> in
> >> >> text, or maybe have the pretty-printer scan comments for http://.
> But
> >> >> it is
> >> >> sad that we can't have hyperlinks in text.
> >> >>
> >> >> Look I know the implementation stinks, but it can be fixed.  But if
> the
> >> >> functionality is lost the system is weakened.  Instead of asking what
> >> >> you
> >> >> can get rid if why not ask what you can reimplement or enhance more
> >> >> elegantly.
> >> >
> >> > Its a reasonable strategy to start the discussion at the extreme end
> >> > and work back from there :) But if its being used we should think
> >> > harder about it.  What alternatives/workarounds are there?
> >> >
> >> > First just to clarify, the aim is to remove Text from the image for
> >> > the boot-strap?
> >>
> >> Yes :) I heard that we want to do cut the dependency to Text-Core, so
> >> I browsed how to do it.
> >>
> >> Ben, there is an explanation about ]style[ in the class comment of
> >> RemoteString.
> >>
> >> Eliot, I didn't thought that somebody was using Text. In fact, I don't
> >> know how to do it in Pharo... how do you do?
> >> I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I
> >> just tested filing-in the attached .st file and it doesn't work. I
> >> guess the new CodeImporter replaced the ChangeRecord implementation,
> >> and it raises an error when ]style[.
> >>
> >> Martín
> >>
> >>
> >> >
> >> > 1. Save the text internally as a string in the stream format and
> >> > up-convert to Text only when its being displayed?  But I guess these
> >> > styles aren't restricted to just occurring in comments and maybe cause
> >> > problem for compilation ??
> >> >
> >> > 2. As a stepping stone, introduce a TextPlaceholder class within
> >> > minimal interface required by compilation which simply strips out all
> >> > styles when Text is missing from the Image. When Text is present it
> >> > #becomes back to it.  Maybe risks loosing styles editing is done on
> >> > the raw-stream-format.  Maybe any editor would show the raw ]style[
> >> > and the compiler asks for #source which strips styles out.
> >> >
> >> > 3. Introduce Pillar and convert across.  What are the requirements?
> >> >a. URLs
> >> >b. Class/method links
> >> >c. Would you expect that Pillar can only appear in comments? Or
> >> > in-line with code?
> >> >d. Colouring?
> >> >...?
> >> >
> >> > btw, I haven't come across this before. Can someone point me to some
> >> > url & styled code where I can have a look at it
> >> >
> >> > cheers -ben
> >> >
> >> >> Christ you're even using minis paced fonts.  It's like the dark
> >> >> ages in there ;-)
> >> >>
> >> >> In addition would prefer to have an explicit syntax as in Pillar or
> >> >> html to
> >> >> represent
> >> >> an hyperlink. We could have
> >> >> *Class>>#method* when pillar is not loaded and else a nicer
> >> >> representation.
> >> >> ctrl-click on a class should jump on it already and we could map it
> to
> >> >> 

Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-08 Thread Henrik Johansen

> On 08 Sep 2015, at 11:03 , Martin Dias  wrote:
> 
> On Sat, Sep 5, 2015 at 1:10 PM, Nicolai Hess  wrote:
>> The same for the  ]lang[ tag (see issue 15750)
> 
> Ok. But I still don't know how to add a url to a method's source code
> or comment from the UI.
> 
> I mean, people with a non-English keyboard can produce source code
> with ]lang[, but how can I produce a ]style[ ?
> 
> Martín

The whole mechanism is quite broken in Pharo4 upwards:




signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-05 Thread Nicolai Hess
The same for the  ]lang[ tag (see issue 15750)

2015-09-05 12:06 GMT+02:00 Martin Dias :

> Hi all
>
> On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman  wrote:
> > On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda 
> wrote:
> >>
> >> On Sep 4, 2015, at 1:33 PM, stepharo  wrote:
> >>
> >> Nobody defines urls in method comment anymore.
> >>
> >> I do.  Several places in the Cog JIT contain irks to specification
> >> documents.  I don't care how its implemented (providing it's preserved
> in
> >> text, or maybe have the pretty-printer scan comments for http://.  But
> it is
> >> sad that we can't have hyperlinks in text.
> >>
> >> Look I know the implementation stinks, but it can be fixed.  But if the
> >> functionality is lost the system is weakened.  Instead of asking what
> you
> >> can get rid if why not ask what you can reimplement or enhance more
> >> elegantly.
> >
> > Its a reasonable strategy to start the discussion at the extreme end
> > and work back from there :) But if its being used we should think
> > harder about it.  What alternatives/workarounds are there?
> >
> > First just to clarify, the aim is to remove Text from the image for
> > the boot-strap?
>
> Yes :) I heard that we want to do cut the dependency to Text-Core, so
> I browsed how to do it.
>
> Ben, there is an explanation about ]style[ in the class comment of
> RemoteString.
>
> Eliot, I didn't thought that somebody was using Text. In fact, I don't
> know how to do it in Pharo... how do you do?
> I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I
> just tested filing-in the attached .st file and it doesn't work. I
> guess the new CodeImporter replaced the ChangeRecord implementation,
> and it raises an error when ]style[.
>
> Martín
>
>
> >
> > 1. Save the text internally as a string in the stream format and
> > up-convert to Text only when its being displayed?  But I guess these
> > styles aren't restricted to just occurring in comments and maybe cause
> > problem for compilation ??
> >
> > 2. As a stepping stone, introduce a TextPlaceholder class within
> > minimal interface required by compilation which simply strips out all
> > styles when Text is missing from the Image. When Text is present it
> > #becomes back to it.  Maybe risks loosing styles editing is done on
> > the raw-stream-format.  Maybe any editor would show the raw ]style[
> > and the compiler asks for #source which strips styles out.
> >
> > 3. Introduce Pillar and convert across.  What are the requirements?
> >a. URLs
> >b. Class/method links
> >c. Would you expect that Pillar can only appear in comments? Or
> > in-line with code?
> >d. Colouring?
> >...?
> >
> > btw, I haven't come across this before. Can someone point me to some
> > url & styled code where I can have a look at it
> >
> > cheers -ben
> >
> >> Christ you're even using minis paced fonts.  It's like the dark
> >> ages in there ;-)
> >>
> >> In addition would prefer to have an explicit syntax as in Pillar or
> html to
> >> represent
> >> an hyperlink. We could have
> >> *Class>>#method* when pillar is not loaded and else a nicer
> >> representation.
> >> ctrl-click on a class should jump on it already and we could map it to
> >> *Class>>#method*
> >>
> >> In class comments we should use pillar and get a real text renderer.
> >>
> >>
> >> Hi Martin,
> >>
> >> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> The source code of a method could be a Text, with TextAttributes. In
> such
> >>> case, it will be written down to a stream with a "]style[" suffix.
> Through a
> >>> special parsing, the system can reconstruct the original Text. I think
> the
> >>> use of Text in source code or class comments is discouraged, but I
> >>> understand we kept support for some backward compatibility. Now, may
> be it's
> >>> time to remove this feature.
> >>>
> >>> With Pablo, we looked for uses of ]style[ in the .sources and .changes
> >>> files of a new Pharo 5.0, and there are no real uses. It appears in
> some
> >>> comments only, as examples.
> >>>
> >>> We tried to find past discussions about this feature, because we're
> sure
> >>> there were, but we couldn't.
> >>>
> >>> So, the questions is:
> >>>
> >>>Can we remove support for text in source code or class comments in
> >>> Pharo 5.0?
> >>
> >>
> >> IIUC, ]style[ also supports things like embedding URL links and method
> >> references in class comments.  So I would request that it /not/ be
> removed.
> >> It is very useful to put clickable links in class comments.
> >>
> >>>
> >>>
> >>> I think I can propose a slice.
> >>>
> >>> Regards,
> >>> Martín
> >>> PS: I was trying to cut dependencies of Text-Core with System-Changes
> and
> >>> System-Changes.
> >>
> >>
> >>
> >>
> >> --
> >> _,,,^..^,,,_
> >> best, Eliot
> >>
> >>
> >
>


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-05 Thread Martin Dias
Hi all

On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman  wrote:
> On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda  wrote:
>>
>> On Sep 4, 2015, at 1:33 PM, stepharo  wrote:
>>
>> Nobody defines urls in method comment anymore.
>>
>> I do.  Several places in the Cog JIT contain irks to specification
>> documents.  I don't care how its implemented (providing it's preserved in
>> text, or maybe have the pretty-printer scan comments for http://.  But it is
>> sad that we can't have hyperlinks in text.
>>
>> Look I know the implementation stinks, but it can be fixed.  But if the
>> functionality is lost the system is weakened.  Instead of asking what you
>> can get rid if why not ask what you can reimplement or enhance more
>> elegantly.
>
> Its a reasonable strategy to start the discussion at the extreme end
> and work back from there :) But if its being used we should think
> harder about it.  What alternatives/workarounds are there?
>
> First just to clarify, the aim is to remove Text from the image for
> the boot-strap?

Yes :) I heard that we want to do cut the dependency to Text-Core, so
I browsed how to do it.

Ben, there is an explanation about ]style[ in the class comment of RemoteString.

Eliot, I didn't thought that somebody was using Text. In fact, I don't
know how to do it in Pharo... how do you do?
I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I
just tested filing-in the attached .st file and it doesn't work. I
guess the new CodeImporter replaced the ChangeRecord implementation,
and it raises an error when ]style[.

Martín


>
> 1. Save the text internally as a string in the stream format and
> up-convert to Text only when its being displayed?  But I guess these
> styles aren't restricted to just occurring in comments and maybe cause
> problem for compilation ??
>
> 2. As a stepping stone, introduce a TextPlaceholder class within
> minimal interface required by compilation which simply strips out all
> styles when Text is missing from the Image. When Text is present it
> #becomes back to it.  Maybe risks loosing styles editing is done on
> the raw-stream-format.  Maybe any editor would show the raw ]style[
> and the compiler asks for #source which strips styles out.
>
> 3. Introduce Pillar and convert across.  What are the requirements?
>a. URLs
>b. Class/method links
>c. Would you expect that Pillar can only appear in comments? Or
> in-line with code?
>d. Colouring?
>...?
>
> btw, I haven't come across this before. Can someone point me to some
> url & styled code where I can have a look at it
>
> cheers -ben
>
>> Christ you're even using minis paced fonts.  It's like the dark
>> ages in there ;-)
>>
>> In addition would prefer to have an explicit syntax as in Pillar or html to
>> represent
>> an hyperlink. We could have
>> *Class>>#method* when pillar is not loaded and else a nicer
>> representation.
>> ctrl-click on a class should jump on it already and we could map it to
>> *Class>>#method*
>>
>> In class comments we should use pillar and get a real text renderer.
>>
>>
>> Hi Martin,
>>
>> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias  wrote:
>>>
>>> Hi all,
>>>
>>> The source code of a method could be a Text, with TextAttributes. In such
>>> case, it will be written down to a stream with a "]style[" suffix. Through a
>>> special parsing, the system can reconstruct the original Text. I think the
>>> use of Text in source code or class comments is discouraged, but I
>>> understand we kept support for some backward compatibility. Now, may be it's
>>> time to remove this feature.
>>>
>>> With Pablo, we looked for uses of ]style[ in the .sources and .changes
>>> files of a new Pharo 5.0, and there are no real uses. It appears in some
>>> comments only, as examples.
>>>
>>> We tried to find past discussions about this feature, because we're sure
>>> there were, but we couldn't.
>>>
>>> So, the questions is:
>>>
>>>Can we remove support for text in source code or class comments in
>>> Pharo 5.0?
>>
>>
>> IIUC, ]style[ also supports things like embedding URL links and method
>> references in class comments.  So I would request that it /not/ be removed.
>> It is very useful to put clickable links in class comments.
>>
>>>
>>>
>>> I think I can propose a slice.
>>>
>>> Regards,
>>> Martín
>>> PS: I was trying to cut dependencies of Text-Core with System-Changes and
>>> System-Changes.
>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>


HelpOnHelp class-example.st
Description: Binary data


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-04 Thread Eliot Miranda
Hi Martin,

On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias  wrote:

> Hi all,
>
> The source code of a method could be a Text, with TextAttributes. In such
> case, it will be written down to a stream with a "]style[" suffix. Through
> a special parsing, the system can reconstruct the original Text. I think
> the use of Text in source code or class comments is discouraged, but I
> understand we kept support for some backward compatibility. Now, may be
> it's time to remove this feature.
>
> With Pablo, we looked for uses of ]style[ in the .sources and .changes
> files of a new Pharo 5.0, and there are no real uses. It appears in some
> comments only, as examples.
>
> We tried to find past discussions about this feature, because we're sure
> there were, but we couldn't.
>
> So, the questions is:
>
>Can we remove support for text in source code or class comments in
> Pharo 5.0?
>

IIUC, ]style[ also supports things like embedding URL links and method
references in class comments.  So I would request that it /not/ be
removed.  It is very useful to put clickable links in class comments.


>
> I think I can propose a slice.
>
> Regards,
> Martín
> PS: I was trying to cut dependencies of Text-Core with System-Changes and
> System-Changes.
>



-- 
_,,,^..^,,,_
best, Eliot


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-04 Thread stepharo

eliot

Nobody defines urls in method comment anymore. In addition would prefer 
to have an explicit syntax as in Pillar or html to represent

an hyperlink. We could have
*Class>>#method* when pillar is not loaded and else a nicer 
representation.
ctrl-click on a class should jump on it already and we could map it to 
*Class>>#method*


In class comments we should use pillar and get a real text renderer.



Hi Martin,

On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias > wrote:


Hi all,

The source code of a method could be a Text, with TextAttributes.
In such case, it will be written down to a stream with a "]style["
suffix. Through a special parsing, the system can reconstruct the
original Text. I think the use of Text in source code or class
comments is discouraged, but I understand we kept support for some
backward compatibility. Now, may be it's time to remove this feature.

With Pablo, we looked for uses of ]style[ in the .sources and
.changes files of a new Pharo 5.0, and there are no real uses. It
appears in some comments only, as examples.

We tried to find past discussions about this feature, because
we're sure there were, but we couldn't.

So, the questions is:

   Can we remove support for text in source code or class comments
in Pharo 5.0?


IIUC, ]style[ also supports things like embedding URL links and method 
references in class comments.  So I would request that it /not/ be 
removed.  It is very useful to put clickable links in class comments.




I think I can propose a slice.

Regards,
Martín
PS: I was trying to cut dependencies of Text-Core with
System-Changes and System-Changes.




--
_,,,^..^,,,_
best, Eliot




Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-04 Thread Eliot Miranda


Sent from my iPhone

> On Sep 4, 2015, at 1:33 PM, stepharo  wrote:
> 
> eliot 
> 
> Nobody defines urls in method comment anymore.

I do.  Several places in the Cog JIT contain irks to specification documents.  
I don't care how its implemented (providing it's preserved in text, or maybe 
have the pretty-printer scan comments for http://.  But it is sad that we can't 
have hyperlinks in text.

Look I know the implementation stinks, but it can be fixed.  But if the 
functionality is lost the system is weakened.  Instead of asking what you can 
get rid if why not ask what you can reimplement or enhance more elegantly.  
Christ you're even using minis paced fonts.  It's like the dark ages in there 
;-)

> In addition would prefer to have an explicit syntax as in Pillar or html to 
> represent 
> an hyperlink. We could have 
> *Class>>#method* when pillar is not loaded and else a nicer 
> representation. 
> ctrl-click on a class should jump on it already and we could map it to 
> *Class>>#method*
> 
> In class comments we should use pillar and get a real text renderer.
> 
> 
>> Hi Martin,
>> 
>>> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias  wrote:
>>> Hi all,
>>> 
>>> The source code of a method could be a Text, with TextAttributes. In such 
>>> case, it will be written down to a stream with a "]style[" suffix. Through 
>>> a special parsing, the system can reconstruct the original Text. I think 
>>> the use of Text in source code or class comments is discouraged, but I 
>>> understand we kept support for some backward compatibility. Now, may be 
>>> it's time to remove this feature. 
>>> 
>>> With Pablo, we looked for uses of ]style[ in the .sources and .changes 
>>> files of a new Pharo 5.0, and there are no real uses. It appears in some 
>>> comments only, as examples.
>>> 
>>> We tried to find past discussions about this feature, because we're sure 
>>> there were, but we couldn't.
>>> 
>>> So, the questions is:
>>> 
>>>Can we remove support for text in source code or class comments in Pharo 
>>> 5.0?
>> 
>> IIUC, ]style[ also supports things like embedding URL links and method 
>> references in class comments.  So I would request that it /not/ be removed.  
>> It is very useful to put clickable links in class comments.
>> 
>>> 
>>> 
>>> I think I can propose a slice.
>>> 
>>> Regards,
>>> Martín
>>> PS: I was trying to cut dependencies of Text-Core with System-Changes and 
>>> System-Changes.
>> 
>> 
>> 
>> -- 
>> _,,,^..^,,,_
>> best, Eliot
> 


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-04 Thread Nicolai Hess
2015-09-04 21:27 GMT+02:00 Eliot Miranda :

> Hi Martin,
>
> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias  wrote:
>
>> Hi all,
>>
>> The source code of a method could be a Text, with TextAttributes. In such
>> case, it will be written down to a stream with a "]style[" suffix. Through
>> a special parsing, the system can reconstruct the original Text. I think
>> the use of Text in source code or class comments is discouraged, but I
>> understand we kept support for some backward compatibility. Now, may be
>> it's time to remove this feature.
>>
>> With Pablo, we looked for uses of ]style[ in the .sources and .changes
>> files of a new Pharo 5.0, and there are no real uses. It appears in some
>> comments only, as examples.
>>
>> We tried to find past discussions about this feature, because we're sure
>> there were, but we couldn't.
>>
>> So, the questions is:
>>
>>Can we remove support for text in source code or class comments in
>> Pharo 5.0?
>>
>
> IIUC, ]style[ also supports things like embedding URL links and method
> references in class comments.  So I would request that it /not/ be
> removed.  It is very useful to put clickable links in class comments.
>


I missed that too, why did we remove that?


>
>
>>
>> I think I can propose a slice.
>>
>> Regards,
>> Martín
>> PS: I was trying to cut dependencies of Text-Core with System-Changes and
>> System-Changes.
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>


Re: [Pharo-dev] TextAttributes in source code or class comment?

2015-09-04 Thread Ben Coman
On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda  wrote:
>
> On Sep 4, 2015, at 1:33 PM, stepharo  wrote:
>
> Nobody defines urls in method comment anymore.
>
> I do.  Several places in the Cog JIT contain irks to specification
> documents.  I don't care how its implemented (providing it's preserved in
> text, or maybe have the pretty-printer scan comments for http://.  But it is
> sad that we can't have hyperlinks in text.
>
> Look I know the implementation stinks, but it can be fixed.  But if the
> functionality is lost the system is weakened.  Instead of asking what you
> can get rid if why not ask what you can reimplement or enhance more
> elegantly.

Its a reasonable strategy to start the discussion at the extreme end
and work back from there :) But if its being used we should think
harder about it.  What alternatives/workarounds are there?

First just to clarify, the aim is to remove Text from the image for
the boot-strap?

1. Save the text internally as a string in the stream format and
up-convert to Text only when its being displayed?  But I guess these
styles aren't restricted to just occurring in comments and maybe cause
problem for compilation ??

2. As a stepping stone, introduce a TextPlaceholder class within
minimal interface required by compilation which simply strips out all
styles when Text is missing from the Image. When Text is present it
#becomes back to it.  Maybe risks loosing styles editing is done on
the raw-stream-format.  Maybe any editor would show the raw ]style[
and the compiler asks for #source which strips styles out.

3. Introduce Pillar and convert across.  What are the requirements?
   a. URLs
   b. Class/method links
   c. Would you expect that Pillar can only appear in comments? Or
in-line with code?
   d. Colouring?
   ...?

btw, I haven't come across this before. Can someone point me to some
url & styled code where I can have a look at it

cheers -ben

> Christ you're even using minis paced fonts.  It's like the dark
> ages in there ;-)
>
> In addition would prefer to have an explicit syntax as in Pillar or html to
> represent
> an hyperlink. We could have
> *Class>>#method* when pillar is not loaded and else a nicer
> representation.
> ctrl-click on a class should jump on it already and we could map it to
> *Class>>#method*
>
> In class comments we should use pillar and get a real text renderer.
>
>
> Hi Martin,
>
> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias  wrote:
>>
>> Hi all,
>>
>> The source code of a method could be a Text, with TextAttributes. In such
>> case, it will be written down to a stream with a "]style[" suffix. Through a
>> special parsing, the system can reconstruct the original Text. I think the
>> use of Text in source code or class comments is discouraged, but I
>> understand we kept support for some backward compatibility. Now, may be it's
>> time to remove this feature.
>>
>> With Pablo, we looked for uses of ]style[ in the .sources and .changes
>> files of a new Pharo 5.0, and there are no real uses. It appears in some
>> comments only, as examples.
>>
>> We tried to find past discussions about this feature, because we're sure
>> there were, but we couldn't.
>>
>> So, the questions is:
>>
>>Can we remove support for text in source code or class comments in
>> Pharo 5.0?
>
>
> IIUC, ]style[ also supports things like embedding URL links and method
> references in class comments.  So I would request that it /not/ be removed.
> It is very useful to put clickable links in class comments.
>
>>
>>
>> I think I can propose a slice.
>>
>> Regards,
>> Martín
>> PS: I was trying to cut dependencies of Text-Core with System-Changes and
>> System-Changes.
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>