December 2017 - Pharo-users

Is there a way to stop arrays sorting automatically?

by Andy Burnett

I suspect I am missing something very obvious, in which case could some kind soul put me straight? I have the following code col := OrderedCollection new. (1 to: 9) permutationsDo: [ :each | col add: (each )]. I thought this would give me a collection containing all the permutations. However, what actually happens is that each of the arrays has been 'magically' sorted back into numerical order. If I change the code to read col := OrderedCollection new. (1 to: 9) permutationsDo: [ :each | col add: (each asOrderedCollection )]. Then the permutations are retained. Is this how it is supposed to work? Or, am I doing something wrong? Cheers Andy

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephane Ducasse

Check the pillar markdown parser (not fully working). This is the place to start having a working parser. Stef On Sat, Dec 30, 2017 at 3:29 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > On 30/12/17 00:08, Dimitris Chloupis wrote: > > For me Pillar has been the most underused feature of Pharo by far and it > makes me sad how little we take advantage of this great technology. > > > I have argued time and again and in length about Markdown support in Pharo, > so I will not do it again. I'll just repeat that, in order to make Pharo > less isolated, Git support for managing software source code has the > strategic importance, in the same way that Markdown support for managing > documentation source code has strategic importance. This doesn't preclude > support for native/alternative DVCS in the software front (Monticello, > Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, > t2tags, etc). > > Pillar provides a feature set far longer and more important than markdown > but I think as a community we need to not only include Pillar inside our > standard distribution but built Pharo around it because itâs the perfect > nerve center that unites so many massively popular documentation > technologies like Markdown , LaTex, PDF and the usual suspect HTML. > > The features are there. The only thing remaining is people using them. > > > Pandoc has a feature set far, far longer and more important that Pillar and > Markdown, including Yaml metadata blocks, fine grained exportation control, > ePub and a myriad of other output (an input) formats support (see graphic > below), a community that is mostly devoted to discuss extensively/mainly a > lightweight markup language for "full stack" documentation, scholarly > Markdown community for academic writing, annotated Markdown for > collaborative editing and writing, programmable templates, multilingual > scripting support, including embedded one for Lua (which came pretty handy > to import our most recently publication[1][1a]). And that just to mention > some prominent features in the greater feature set that just Pillar or > Markdown provides. As community we need to not blind ourselves to > alternatives and overcome the Not Invented Here Syndrome, to see value in > what is done outside Pharo for documentation in the same way we have done > for software management (specifically Git). > > A playground for Markdown will enhance Pandoc integration, which we already > have in Grafoscopio, but writing medium to long texts in it, using the > current plain text input objects support is cumbersome. Despite that we have > managed to have long book sized texts redone in Grafoscopio in an agile way. > The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a > single Grafoscopio notebook, stored under just a 600kb STON file (and a 500 > kb exported Markdown file). > > [1] > http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBog… > [1a] > http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigit… > [2] http://mutabit.com/repos.fossil/mapeda/ > > Several times, when I ask questions about Markdown, I'm pointed towards the > Pillar existence, and I reiterate/expand my motives for wanting to implement > *Markdown* support in Pharo. This exercise allow me to reiterate my > questions in a more precise manner and hopefully this time someone will > point me to a starting place about how to create a "playground for > Markdown". > > Cheers, > > Offray > > On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> >> Hi, >> >> Playgrounds are a really good way to write short snippets of code and I >> wonder if such experience could be extended for larger pieces of >> Markdown. What I'm thinking of is have something similar but like this: >> >> 1. Support for Markdown instead of Smalltalk, including syntax >> hightlighning and tab behavior (a tab equals two spaces). >> >> 2. Clicking on urls should load the respective web page. Clicking on >> images should show an image preview. >> >> That's it, to start with. At some point it could be using GT Documenter >> previews, font support and so on. But I would like to start by extending >> the playground to just support this two features. Any advice about where >> can I start for the first feature? >> >> Thanks, >> >> Offray >> >> >> >

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephane Ducasse

May be in pandoc community people helps each others. Sorry I could not resist. I want a system that we can maintain and debug. This is why we are removing make and bash scripts from pillar. Because this is not nice to fight with ugly generated bash files, believe me. stef On Sat, Dec 30, 2017 at 3:41 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > I forgot the image about Pandoc import/export formats support. Here it is: > > http://pandoc.org/diagram.jpg > > Cheers, > > Offray > > > On 30/12/17 09:29, Offray Vladimir Luna CÃ¡rdenas wrote: > > Hi, > > On 30/12/17 00:08, Dimitris Chloupis wrote: > > For me Pillar has been the most underused feature of Pharo by far and it > makes me sad how little we take advantage of this great technology. > > > I have argued time and again and in length about Markdown support in Pharo, > so I will not do it again. I'll just repeat that, in order to make Pharo > less isolated, Git support for managing software source code has the > strategic importance, in the same way that Markdown support for managing > documentation source code has strategic importance. This doesn't preclude > support for native/alternative DVCS in the software front (Monticello, > Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, > t2tags, etc). > > Pillar provides a feature set far longer and more important than markdown > but I think as a community we need to not only include Pillar inside our > standard distribution but built Pharo around it because itâs the perfect > nerve center that unites so many massively popular documentation > technologies like Markdown , LaTex, PDF and the usual suspect HTML. > > The features are there. The only thing remaining is people using them. > > > Pandoc has a feature set far, far longer and more important that Pillar and > Markdown, including Yaml metadata blocks, fine grained exportation control, > ePub and a myriad of other output (an input) formats support (see graphic > below), a community that is mostly devoted to discuss extensively/mainly a > lightweight markup language for "full stack" documentation, scholarly > Markdown community for academic writing, annotated Markdown for > collaborative editing and writing, programmable templates, multilingual > scripting support, including embedded one for Lua (which came pretty handy > to import our most recently publication[1][1a]). And that just to mention > some prominent features in the greater feature set that just Pillar or > Markdown provides. As community we need to not blind ourselves to > alternatives and overcome the Not Invented Here Syndrome, to see value in > what is done outside Pharo for documentation in the same way we have done > for software management (specifically Git). > > A playground for Markdown will enhance Pandoc integration, which we already > have in Grafoscopio, but writing medium to long texts in it, using the > current plain text input objects support is cumbersome. Despite that we have > managed to have long book sized texts redone in Grafoscopio in an agile way. > The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a > single Grafoscopio notebook, stored under just a 600kb STON file (and a 500 > kb exported Markdown file). > > [1] > http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBog… > [1a] > http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigit… > [2] http://mutabit.com/repos.fossil/mapeda/ > > Several times, when I ask questions about Markdown, I'm pointed towards the > Pillar existence, and I reiterate/expand my motives for wanting to implement > *Markdown* support in Pharo. This exercise allow me to reiterate my > questions in a more precise manner and hopefully this time someone will > point me to a starting place about how to create a "playground for > Markdown". > > Cheers, > > Offray > > On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> >> Hi, >> >> Playgrounds are a really good way to write short snippets of code and I >> wonder if such experience could be extended for larger pieces of >> Markdown. What I'm thinking of is have something similar but like this: >> >> 1. Support for Markdown instead of Smalltalk, including syntax >> hightlighning and tab behavior (a tab equals two spaces). >> >> 2. Clicking on urls should load the respective web page. Clicking on >> images should show an image preview. >> >> That's it, to start with. At some point it could be using GT Documenter >> previews, font support and so on. But I would like to start by extending >> the playground to just support this two features. Any advice about where >> can I start for the first feature? >> >> Thanks, >> >> Offray >> >> >> > >

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Stephane Ducasse

Hello blind people You confuse form and contents. May be you should try to understand. But you continue to get blind after all everybody should carry its own cross and this is perfectly ok not to try to understand. Pillar is not about syntax but about the text model and all the visitors. We are working on a release of Pillar 70 but we are slow because busy with other things. Part of the effort is to redesign and remodularised the core model since it grew too much with optional features. But for that we needed to design the production pipeline and clean a lot of problems (like relying on external bash files and external servers, and saving mustache files while we can just use stream and many more). Now where can I find a real robust parser of markdown written in Pharo (with tests of course)? I mean one that fully handles badly designed markdown? and one that I can extend to support references and missing things. Because Pillar could use multiple input formats. Now I will not spend MY time to write a parser. Why because I can write all the books I want with Pillar and this is a "Soup of Stone" in Pillar dev. Repeat after me: the domain is more important than the syntax. The proof is that pillar can generate slides, book, ascii, epub, markdown (but apparently the one of git, yes because they are multiple ones). HTML, static web sites .... I personally do not want to be tight to any external frameworks like pandoc. Stef PS: for the record, pillar syntax was invented in 2000. So please stop to bash us about not invented here because this syntax was invented before markdown was well-known. So check your sources before insulting people. On Sat, Dec 30, 2017 at 4:19 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >> As community we need to not blind ourselves to alternatives and overcome >> the Not Invented Here >> Syndrome, to see value in what is done outside Pharo for documentation in >> the same way we have >> done for software management (specifically Git). > > +1

Dec. 30, 2017

Re: [Pharo-users] Problem fetching a baseline

by Vitor Medina Cruz

> > If you're looking for the source of a package that is already loaded > in your image, try: > > World Menu -> Monticello Browser > > and enter the package name in the left input box. If I enter "tonel" I > get: > > BaselineOfTonel (cypress.1) -> github://pharo-vcs/tonel:v1.0.5 Ok, thanks! In order to test locally I had to save all my packages locally using monticello, then I refer to meu local-cache in the repository message â that is odd, however. Is that the best way of doing that? I will have to use Monticello and Iceberg toghether, which I think is not right.... <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Livre de vÃrus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, Dec 30, 2017 at 1:01 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 30 December 2017 at 15:55, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > > > How do I know where to get Tonel from? It's BaselineOf don't have this > information. > > > If you're looking for the source of a package that is already loaded > in your image, try: > > World Menu -> Monticello Browser > > and enter the package name in the left input box. If I enter "tonel" I > get: > > BaselineOfTonel (cypress.1) -> github://pharo-vcs/tonel:v1.0.5 > > > Cheers, > Alistair > > > > > > > > > > > Since Tonel is in my image by default, Metacello shouldn't use the > packages from there? If that is not the case, how do I test my baseline > implementation locally, before commiting to a repository? > > > > Thanks. > > > > On Sat, Dec 30, 2017 at 3:16 AM, JuliÃ¡n Maestri <serpi90(a)gmail.com> > wrote: > >> > >> You are trying to load Tonel but not telling Metacello where to load it > from: > >> > >> Metacello new > >> repository: 'github://pharo-vcs/tonel'; > >> baseline: 'Tonel'; > >> load. > >> > >> Tells Metacello to load the packages in BaselineOfTonel from > https://github.com/pharo-vcs/tonel > >> > >> On 29 December 2017 at 09:53, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >>> > >>> Hello, > >>> > >>> I am experimenting with Metacello but I am having problems to test my > configuration. First I thought the problem was with my configuration, but > after serveral atemps I tried to fetch an arbitrary Baseline from default > image: > >>> > >>> Metacello new > >>> className: 'BaselineOfTonel'; > >>> baseline: 'Tonel'; > >>> fetch. > >>> > >>> And I got the following error: > >>> > >>> "Could not resolve: BaselineOfTonel [BaselineOfTonel] in > C:\Users\Vitor\Documents\Pharo\images\Pharo 6.1 > (stable)\pharo-local\package-cache http://smalltalkhub.com/mc/ > Pharo/MetaRepoForPharo30/main/" > >>> > >>> Which is the same I got with my own project. I tried using > 'repository:' also, but got the same error. > >>> > >>> Am I doing something wrong? > >>> > >>> cheers, > >>> Vitor. > >>> > >>> Livre de vÃrus. www.avg.com. > >> > >> > > > >

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Kjell Godo

> As community we need to not blind ourselves to alternatives and overcome the Not Invented Here > Syndrome, to see value in what is done outside Pharo for documentation in the same way we have > done for software management (specifically Git). +1

Dec. 30, 2017

Re: [Pharo-users] Problem fetching a baseline

by Alistair Grant

On 30 December 2017 at 15:55, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > How do I know where to get Tonel from? It's BaselineOf don't have this information. If you're looking for the source of a package that is already loaded in your image, try: World Menu -> Monticello Browser and enter the package name in the left input box. If I enter "tonel" I get: BaselineOfTonel (cypress.1) -> github://pharo-vcs/tonel:v1.0.5 Cheers, Alistair > > > Since Tonel is in my image by default, Metacello shouldn't use the packages from there? If that is not the case, how do I test my baseline implementation locally, before commiting to a repository? > > Thanks. > > On Sat, Dec 30, 2017 at 3:16 AM, JuliÃ¡n Maestri <serpi90(a)gmail.com> wrote: >> >> You are trying to load Tonel but not telling Metacello where to load it from: >> >> Metacello new >> repository: 'github://pharo-vcs/tonel'; >> baseline: 'Tonel'; >> load. >> >> Tells Metacello to load the packages in BaselineOfTonel from https://github.com/pharo-vcs/tonel >> >> On 29 December 2017 at 09:53, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >>> >>> Hello, >>> >>> I am experimenting with Metacello but I am having problems to test my configuration. First I thought the problem was with my configuration, but after serveral atemps I tried to fetch an arbitrary Baseline from default image: >>> >>> Metacello new >>> className: 'BaselineOfTonel'; >>> baseline: 'Tonel'; >>> fetch. >>> >>> And I got the following error: >>> >>> "Could not resolve: BaselineOfTonel [BaselineOfTonel] in C:\Users\Vitor\Documents\Pharo\images\Pharo 6.1 (stable)\pharo-local\package-cache http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main/" >>> >>> Which is the same I got with my own project. I tried using 'repository:' also, but got the same error. >>> >>> Am I doing something wrong? >>> >>> cheers, >>> Vitor. >>> >>> Livre de vÃrus. www.avg.com. >> >> >

Dec. 30, 2017

Re: [Pharo-users] Problem fetching a baseline

by Vitor Medina Cruz

How do I know where to get Tonel from? It's BaselineOf don't have this information. Since Tonel is in my image by default, Metacello shouldn't use the packages from there? If that is not the case, how do I test my baseline implementation locally, before commiting to a repository? Thanks. On Sat, Dec 30, 2017 at 3:16 AM, JuliÃ¡n Maestri <serpi90(a)gmail.com> wrote: > You are trying to load Tonel but not telling Metacello where to load it > from: > > Metacello new > repository: 'github://pharo-vcs/tonel'; > baseline: 'Tonel'; > load. > > Tells Metacello to load the packages in BaselineOfTonel from > https://github.com/pharo-vcs/tonel > > On 29 December 2017 at 09:53, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> Hello, >> >> I am experimenting with Metacello but I am having problems to test my >> configuration. First I thought the problem was with my configuration, but >> after serveral atemps I tried to fetch an arbitrary Baseline from default >> image: >> >> Metacello new >> className: 'BaselineOfTonel'; >> baseline: 'Tonel'; >> fetch. >> >> And I got the following error: >> >> "Could not resolve: BaselineOfTonel [BaselineOfTonel] in >> C:\Users\Vitor\Documents\Pharo\images\Pharo 6.1 >> (stable)\pharo-local\package-cache http://smalltalkhub.com/mc/Pha >> ro/MetaRepoForPharo30/main/" >> >> Which is the same I got with my own project. I tried using 'repository:' >> also, but got the same error. >> >> Am I doing something wrong? >> >> cheers, >> Vitor. >> >> >> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Livre >> de vÃrus. www.avg.com >> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>. >> >> <#m_3398382512267223847_m_1552980269475238850_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > >

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

I forgot the image about Pandoc import/export formats support. Here it is: http://pandoc.org/diagram.jpg Cheers, Offray On 30/12/17 09:29, Offray Vladimir Luna CÃ¡rdenas wrote: > > Hi, > > On 30/12/17 00:08, Dimitris Chloupis wrote: >> For me Pillar has been the most underused feature of Pharo by far and >> it makes me sad how little we take advantage of this great technology. >> > > I have argued time and again and in length about Markdown support in > Pharo, so I will not do it again. I'll just repeat that, in order to > make Pharo less isolated, Git support for managing software source > code has the strategic importance, in the same way that Markdown > support for managing documentation source code has strategic > importance. This doesn't preclude support for native/alternative DVCS > in the software front (Monticello, Fossil, etc) or markup languages in > the documentation one (Pillar, Dokuwiki, t2tags, etc). > >> Pillar provides a feature set far longer and more important than >> markdown but I think as a community we need to not only include >> Pillar inside our standard distribution but built Pharo around it >> because itâs the perfect nerve center that unites so many massively >> popular documentation technologies like Markdown , LaTex, PDF and the >> usual suspect HTML. >> >> The features are there. The only thing remaining is people using them. > > Pandoc has a feature set far, far longer and more important that > Pillar and Markdown, including Yaml metadata blocks, fine grained > exportation control, ePub and a myriad of other output (an input) > formats support (see graphic below), a community that is mostly > devoted to discuss extensively/mainly a lightweight markup language > for "full stack" documentation, scholarly Markdown community for > academic writing, annotated Markdown for collaborative editing and > writing, programmable templates, multilingual scripting support, > including embedded one for Lua (which came pretty handy to import our > most recently publication[1][1a]). And thatÂ just to mention some > prominent features in the greater feature set that just Pillar or > Markdown provides. As community we need to not blind ourselves to > alternatives and overcome the Not Invented Here Syndrome, to see value > in what is done outside Pharo for documentation in the same way we > have done for software management (specifically Git). > > A playground for Markdown will enhance Pandoc integration, which we > already have in Grafoscopio, but writing medium to long texts in it, > using the current plain text input objects support is cumbersome. > Despite that we have managed to have long book sized texts redone in > Grafoscopio in an agile way. The Data Driven Journalism Handbook [2] > has 300+ pages (13 Mb PDF) in a single Grafoscopio notebook, stored > under just a 600kb STON file (and a 500 kb exported Markdown file). > > [1] > http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBog… > [1a] > http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigit… > > [2] http://mutabit.com/repos.fossil/mapeda/ > > Several times, when I ask questions about Markdown, I'm pointed > towards the Pillar existence, and I reiterate/expand my motives for > wanting to implement *Markdown* support in Pharo. This exercise allow > me to reiterate my questions in a more precise manner and hopefully > this time someone will point me to a starting place about how to > create a "playground for Markdown". > > Cheers, > > Offray > >> On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >> >> Hi, >> >> Playgrounds are a really good way to write short snippets of code >> and I >> wonder if such experience could be extended for larger pieces of >> Markdown. What I'm thinking of is have something similar butÂ >> like this: >> >> 1. Support for Markdown instead of Smalltalk, including syntax >> hightlighning and tab behavior (a tab equals two spaces). >> >> 2. Clicking on urls should load the respective web page. Clicking on >> images shouldÂ show an image preview. >> >> That's it, to start with. At some point it could be using GT >> Documenter >> previews, font support and so on. But I would like to start by >> extending >> the playground to just support this two features. Any advice >> about where >> can I start for the first feature? >> >> Thanks, >> >> Offray >> >> >> >

Dec. 30, 2017

Re: [Pharo-users] A playground for Markdown?

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 30/12/17 00:08, Dimitris Chloupis wrote: > For me Pillar has been the most underused feature of Pharo by far and > it makes me sad how little we take advantage of this great technology. > I have argued time and again and in length about Markdown support in Pharo, so I will not do it again. I'll just repeat that, in order to make Pharo less isolated, Git support for managing software source code has the strategic importance, in the same way that Markdown support for managing documentation source code has strategic importance. This doesn't preclude support for native/alternative DVCS in the software front (Monticello, Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, t2tags, etc). > Pillar provides a feature set far longer and more important than > markdown but I think as a community we need to not only include Pillar > inside our standard distribution but built Pharo around it because > itâs the perfect nerve center that unites so many massively popular > documentation technologies like Markdown , LaTex, PDF and the usual > suspect HTML. > > The features are there. The only thing remaining is people using them. Pandoc has a feature set far, far longer and more important that Pillar and Markdown, including Yaml metadata blocks, fine grained exportation control, ePub and a myriad of other output (an input) formats support (see graphic below), a community that is mostly devoted to discuss extensively/mainly a lightweight markup language for "full stack" documentation, scholarly Markdown community for academic writing, annotated Markdown for collaborative editing and writing, programmable templates, multilingual scripting support, including embedded one for Lua (which came pretty handy to import our most recently publication[1][1a]). And thatÂ just to mention some prominent features in the greater feature set that just Pillar or Markdown provides. As community we need to not blind ourselves to alternatives and overcome the Not Invented Here Syndrome, to see value in what is done outside Pharo for documentation in the same way we have done for software management (specifically Git). A playground for Markdown will enhance Pandoc integration, which we already have in Grafoscopio, but writing medium to long texts in it, using the current plain text input objects support is cumbersome. Despite that we have managed to have long book sized texts redone in Grafoscopio in an agile way. The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a single Grafoscopio notebook, stored under just a 600kb STON file (and a 500 kb exported Markdown file). [1] http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBog… [1a] http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigit… [2] http://mutabit.com/repos.fossil/mapeda/ Several times, when I ask questions about Markdown, I'm pointed towards the Pillar existence, and I reiterate/expand my motives for wanting to implement *Markdown* support in Pharo. This exercise allow me to reiterate my questions in a more precise manner and hopefully this time someone will point me to a starting place about how to create a "playground for Markdown". Cheers, Offray > On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi, > > Playgrounds are a really good way to write short snippets of code > and I > wonder if such experience could be extended for larger pieces of > Markdown. What I'm thinking of is have something similar butÂ like > this: > > 1. Support for Markdown instead of Smalltalk, including syntax > hightlighning and tab behavior (a tab equals two spaces). > > 2. Clicking on urls should load the respective web page. Clicking on > images shouldÂ show an image preview. > > That's it, to start with. At some point it could be using GT > Documenter > previews, font support and so on. But I would like to start by > extending > the playground to just support this two features. Any advice about > where > can I start for the first feature? > > Thanks, > > Offray > > >

Dec. 30, 2017