August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About cr and lf

by Peter Uhnak

Hi, just to (hopefully) clarify my intention, maybe pseudocode would describe my thoughts better. Stream>>beForWindows "Use consistenly Windows line endings (CRLF) in the stream" self convertLineEndings: true lineEnding := String crlf Stream>>convertLineEndings: aBoolean "automatically convert line endings to the predefined one" convertLineEndings := aBoolean Stream>>nl self nextPutAll: lineEnding Stream>>cr convertLineEndings ifTrue: [ self deprected: 'Using #cr/#lf for generic newlines is deprected, use #nl instead". self nl. ] ifFalse: [ self nextPutAll: String cr. ] So when "convertLineEndings = true", then using anything else than #nl would warn the user that they should use #nl instead (as they explicitly requested to have the line endings consistend). And when "convertLineEndings = false", it would behave pretty much the same way as now, #cr would write #cr, etc. With such approach imho * output of existing code wouldn't be broken * when switching to new scheme (#nl) the programmer would be warned where the missed a change * it will be easier to keep the newlines consistent Peter On Sat, Aug 05, 2017 at 11:30:58AM +0200, Esteban Lorenzano wrote: > > > On 5 Aug 2017, at 11:17, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > >> I think there is a consensus we need to keep #cr and #lf as intended > > > > Is there? > > > > My argument was that there's no (obvious) reason to combine different line endings in the same document. Therefore if you were to use #cr, #lf, #crlf, you would actually mean that you just want to enter newline. > > no, sometimes you want to enforce a specific line ending. You will not mix, but you will not use the one from platform. Also, sometimes you actually can use #cr and #lf different as their immediate, common use (Iâve seen some weird exporting formats). > > > > > Similar problem arises when you would write a multiline string: > > > > stream nextPutAll: 'first line with enter > > second line'. > > > > Stored in method this will most likely contain Pharo's internal representation (#cr), even though you just want a new line, and not specifically #cr. (I've lost count how many times tests on CI failed because of this.) > > > > Considering the above, my opinion is: > > > > 1) by default #cr, #lf, #crLf, #nl (#newLine) will write whatever is globally configured for the stream (#beFor*) > > No, I strongly disagree. > #cr and #lf are ascii characters and should not be redefined. > > > 2) if one wanted to combine different line endings in the same stream, there should be an option to disable autoconversion. (Stream>>noNewLineAutoconversion) > > > > If (1) is much more common than (2), then imho autoconversion should cause no issues. > > If (1) is NOT that much more common than (2), then autoconversion wouldn't be beneficial. > > > > Autoconversion could also make transition easier because existing code will suddenly work as intended here without breaking anything (hopefully). > > Sorry, I do not see what this approach solves than the other one does not (and as I see, this one is a lot more complicated and prone to confusion). > > cheers, > Esteban > > > > > Peter > > > > > > On Sat, Aug 05, 2017 at 10:49:02AM +0200, Esteban Lorenzano wrote: > >> I think there is a consensus we need to keep #cr and #lf as intended, yet to add some kind of #newLine (which btw is different to EOL :P) vocabulary, isnât? > >> > >> In this, I favour Peter approach for define line ending convention (the way #newLine will work)â¦ and of course by default it should use the one from the current platform. > >> > >> anything agains this approach? > >> > >> Esteban > >> > >> > >>> On 4 Aug 2017, at 23:48, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> > >>> +1. > >>> > >>> We need a basic representation of those characters. Logical ones should be derived from the simple ones. > >>> > >>> Doru > >>> > >>> > >>>> On Aug 4, 2017, at 3:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>>> > >>>> > >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet(a)gmail.com> wrote: > >>>>> > >>>>> I agree with Pablo, #cr and #lf should not be clever and just be names for the carriage return and linefeed characters/codepoints. > >>>> > >>>> +1 > >>>> > >>>>> > >>>>> Making #newLine's behavior dependent on the current platform disturbs me, though. I'd rather have: > >>>>> > >>>>> Stream >> newLineFor: platform > >>>>> self nextPutAll: platform lineEnding > >>>>> > >>>>> Stream >> newLineForCurrentPlatform > >>>>> self newLineFor: OSPlatform current > >>>>> > >>>>> Stream >> newLineForWindows "convenience for the most common platforms > >>>>> Stream >> newLineForUnix > >>>>> Stream >> newLineForHistoricReasons > >>>>> > >>>>> Stream >> newLine > >>>>> "delegates to one of the above, I'd argue for unix for convenience, but windows is the technically correct combination of cr + lf, and cr only is the historic one" > >>>>> > >>>>> > >>>>> On 4 August 2017 at 14:25, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > >>>>> To me it is clear that cr and lf should be in streams. But they should put the 'cr' or 'lf' character only. And of course the platform independent newline should be also. > >>>>> > >>>>> The first (cr, lf) should be used by the code wanting to have absolute control of what is in the stream. The later (newline) when you just want a new line. > >>>>> > >>>>> The two have completely different behaviour, ones are really low level, the other is higher level. > >>>>> > >>>>> On 4 Aug 2017 14:20, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > >>>>> > >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >>>>>> > >>>>>> Well. This is not implemented like that in Pharo. > >>>>>> > >>>>>> cr is bad because it does not mean that it is independent of the platform. > >>>>>> So cr can be redefined as newLine and keep but not used inside the system. > >>>>> > >>>>> sometimes you actually want to write a cr (or a lf). So it needs to remain in the system, of course. > >>>>> now, including #newLine can be cool (most of the times you want the âplatform compatibleâ new line). Also I would consider including #nl, abbreviatedâ¦ just for convenience :P > >>>>> > >>>>> Esteban > >>>>> > >>>>>> > >>>>>> Stef > >>>>>> > >>>>>> On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >>>>>>> On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote: > >>>>>>>> Hi guys > >>>>>>>> > >>>>>>>> While writing pillar code, I ended up using "stream cr" and it > >>>>>>>> worries > >>>>>>>> me to still expand usage > >>>>>>>> of a pattern I would like to remove. > >>>>>>>> > >>>>>>>> Let us imagine that we would like to prepare the migration from cr. > >>>>>>>> I was thinking that we could replace cr invocation by newLine so that > >>>>>>>> after newLine > >>>>>>>> could be redefined as > >>>>>>>> > >>>>>>>> Stream >> newLine > >>>>>>>> self nextPutAll: OSPlatform current lineEnding > >>>>>>>> > >>>>>>>> > >>>>>>>> what do you think about this approach? > >>>>>>> > >>>>>>> Why not? But please keep #cr. > >>>>>>> > >>>>>>> Section 5.9.4.1 of ANSI reads: > >>>>>>> > >>>>>>> Message: cr > >>>>>>> > >>>>>>> Synopsis > >>>>>>> Writes an end-of-line sequence to the receiver. > >>>>>>> > >>>>>>> Definition: <puttableStream> > >>>>>>> A sequence of character objects that constitute the implementation- > >>>>>>> defined end-of-line sequence is added to the receiver in the same > >>>>>>> manner as if the message #nextPutAll: was sent to the receiver with > >>>>>>> an argument string whose elements are the sequence of characters. > >>>>>>> > >>>>>>> Return Value > >>>>>>> UNSPECIFIED > >>>>>>> Errors > >>>>>>> It is erroneous if any element of the end-of-line sequence is an > >>>>>>> object that does not conform to the receiver's sequence value type . > >>>>>>> > >>>>>>> my 2c, > >>>>>>> > >>>>>>> Jan > >>>>>>> > >>>>>>>> > >>>>>>>> Stef > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Damien Pollet > >>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet > >>>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Presenting is storytelling." > >>> > >>> > >> > >> > > > >

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Guillermo Polito

Hi all, First, we should not confuse "writing into a stream" with "writing into a text file". Not all streams are to write into a text file. This means that we cannot pretend that the basic stream implementation should always do a conversion. I think that should belong to a text writer, also managing the text encoding (utf-8 and so on). So far we have a Character writer stream that wraps a binary stream and manages encoding (see ZnCharacterWriteStream). I wrote for backwards compatibility a ZnCrPortableWriteStream (that is in pharo repo so far because but should be pushed back to Zinc's repo, hi Sven :) ) that manages crlf automatic conversion also. Moreover, for people that want "detection of line separators in a file" such as it is done in text editors, I believe we need a higher level abstraction. We need also to detect encoding and keep living during the life of the file. However, we don't have such abstraction. Guille On Sat, Aug 5, 2017 at 8:03 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On 5 August 2017 at 18:14, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > So one step at a time: > > > > - #cr and #lf just put this character in the stream. > > - #newLine put the underlying OS line ending. ( and sorry for the > > nostalgic but nl sucks and to me this is netherlands and not newline > > :). > > Beyond the nostalgic and humorous, there is actually a justification > for the shorter #nl. > > Adding a new line is a common operation, and more compact code is more > readable. So I find: > > stream > << 'Line 1 goes here'; nl; > << 'Line 2 goes here'; nl. > > better than: > > stream > nextPutAll: 'Line 1 goes here'; newLine; > nextPutAll: 'Line 2 goes here'; newLine. > > > Although this is still subjective. > > Cheers, > Alistair > > > > > Then we should revisit all the cr inside the system and use newline. > > Then we should think about the internal usage of cr by default in > > Pharo (We should change it). > > > > Does it make sense? > > Stef > > > > > > > > On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > >> On Friday 04 August 2017 07:11 PM, Damien Pollet wrote: > >>> > >>> Stream >> newLineFor: platform > >>> self nextPutAll: platform lineEnding > >>> > >> > >> EOL encoding is a property of a text file and not a platform. While > files > >> created on a certain proprietary platforms ;-) may use an encoding that > does > >> not make it a platform property. Pharo should be liberal in accepting > and > >> preserving differently encoded files. E.g. Text editor vim has a setting > >> (fileformats) for eol encoding to view or edit files with cr or crlf EOL > >> encoding. If this is not set, vim falls back to nl. > >> > >> I agree that existing messages like cr or nl should not be changed. > Instead > >> new methods (*eol) could be added to text files for decoding (read > side) and > >> encoding (write side). This should be liberal in accepting cr, nl, crnl > >> decodes while reading a text file. While writing a new stream, eol > should > >> follow this order: > >> 1. if file eol property is set (cr/nl/crnl) it should use it > >> 2. else fallback to check platform eol property. > >> 3. Else, use cr (for backward compatibility with old files) > >> E.g. > >> > >> (aStream atEOL) ifFalse: [ c := aStream next ] > >> aStream nextPutAll: 'hello world' ; writeEOL > >> record := aStream readLine. "strip eol" > >> aStream nextPutLine: 'hello world' > >> > >> This is not going to be an easy change but it would make new code > cleaner. > >> > >> Regards .. Subbu > >> > > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Alistair Grant

Hi Stef, On 5 August 2017 at 18:14, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > So one step at a time: > > - #cr and #lf just put this character in the stream. > - #newLine put the underlying OS line ending. ( and sorry for the > nostalgic but nl sucks and to me this is netherlands and not newline > :). Beyond the nostalgic and humorous, there is actually a justification for the shorter #nl. Adding a new line is a common operation, and more compact code is more readable. So I find: stream << 'Line 1 goes here'; nl; << 'Line 2 goes here'; nl. better than: stream nextPutAll: 'Line 1 goes here'; newLine; nextPutAll: 'Line 2 goes here'; newLine. Although this is still subjective. Cheers, Alistair > Then we should revisit all the cr inside the system and use newline. > Then we should think about the internal usage of cr by default in > Pharo (We should change it). > > Does it make sense? > Stef > > > > On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >> On Friday 04 August 2017 07:11 PM, Damien Pollet wrote: >>> >>> Stream >> newLineFor: platform >>> self nextPutAll: platform lineEnding >>> >> >> EOL encoding is a property of a text file and not a platform. While files >> created on a certain proprietary platforms ;-) may use an encoding that does >> not make it a platform property. Pharo should be liberal in accepting and >> preserving differently encoded files. E.g. Text editor vim has a setting >> (fileformats) for eol encoding to view or edit files with cr or crlf EOL >> encoding. If this is not set, vim falls back to nl. >> >> I agree that existing messages like cr or nl should not be changed. Instead >> new methods (*eol) could be added to text files for decoding (read side) and >> encoding (write side). This should be liberal in accepting cr, nl, crnl >> decodes while reading a text file. While writing a new stream, eol should >> follow this order: >> 1. if file eol property is set (cr/nl/crnl) it should use it >> 2. else fallback to check platform eol property. >> 3. Else, use cr (for backward compatibility with old files) >> E.g. >> >> (aStream atEOL) ifFalse: [ c := aStream next ] >> aStream nextPutAll: 'hello world' ; writeEOL >> record := aStream readLine. "strip eol" >> aStream nextPutLine: 'hello world' >> >> This is not going to be an easy change but it would make new code cleaner. >> >> Regards .. Subbu >> >

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Stephane Ducasse

:) Me too. Stef On Sat, Aug 5, 2017 at 6:32 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Sat, Aug 5, 2017 at 6:14 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> So one step at a time: >> >> - #cr and #lf just put this character in the stream. >> - #newLine put the underlying OS line ending. ( and sorry for the >> nostalgic but nl sucks and to me this is netherlands and not newline >> :). >> >> Then we should revisit all the cr inside the system and use newline. >> Then we should think about the internal usage of cr by default in >> Pharo (We should change it). >> >> Does it make sense? >> Stef >> >> > > I like that. > > For the internal usage of Pharo I would not use cr since it is used by > nobody in current systems. But that's just my opinion :) > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Cyril Ferlicot

On Sat, Aug 5, 2017 at 6:14 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > So one step at a time: > > - #cr and #lf just put this character in the stream. > - #newLine put the underlying OS line ending. ( and sorry for the > nostalgic but nl sucks and to me this is netherlands and not newline > :). > > Then we should revisit all the cr inside the system and use newline. > Then we should think about the internal usage of cr by default in > Pharo (We should change it). > > Does it make sense? > Stef > > I like that. For the internal usage of Pharo I would not use cr since it is used by nobody in current systems. But that's just my opinion :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 5, 2017

Spec menu extensibility (epicea)

by Stephane Ducasse

Hi guys I would like to know if there is a pattern to build extensible menu in Spec. For example, I extending Epicea to support pillar fileout so that I can turn a coding section into a pillar steps of action. I wanted to extend the epicea browser to get my menu in: But the code is like that: EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu aMenu addGroup: [ :aGroup | self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray | aGroup addItem: [ :anItem | anItem name: oldStyleMenuItemArray first; description: oldStyleMenuItemArray third; icon: (self iconNamed: oldStyleMenuItemArray fourth); action: [ self perform: oldStyleMenuItemArray second ] ] ] ]. aMenu addGroup: [ :aGroup | aGroup addItem: [ :anItem | anItem name: 'Filters'; icon: (self iconNamed: #smallFindIcon); subMenu: self filtersSubMenu ] ]. aMenu addGroup: [ :aGroup | aGroup addItem: [ :anItem | anItem name: 'File Out'; description: 'Write selected entries to an Ombu file'; icon: (self iconNamed: #smallSaveAsIcon); action: [ self fileOutSelection ] ] ]. EPLogBrowserModel >> menuMorphForSelectedItems | aMenu | aMenu := MenuModel new. showEntryItemMenu ifTrue: [ self addMenuItemsForSelectedItemsIn: aMenu ]. ^ aMenu buildWithSpecAsPopup So I would like to improve Epicea but I face the problem of the limits of Spec (presumably). I'm thinking to add a <specMenu: 10> pragma to handle this case. Any thought. Stef

Aug. 5, 2017

Re: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names

by Stephane Ducasse

Hi torsten Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Ben, > > reason is that for Pharo 7 currently an sha git hash is used in the file > name > instead of a (more clear) build number. > > See http://files.pharo.org/image/70/ > > This problem (which has more side effects on different sides, not only the > Launcher now) was discussed > already yesterday on Discord #iceberg channel with Esteban and Pavel. > > The current sha based image file name scheme is not only confusing but has > some downsides. > One can not easily remember the SHA or see which image is the latest, or > sort from recent > images to older in a folder. > > If I understood correctly the reason to (initially) choose sha's in the > image name has something > to do with Travis and a discussion between Pavel, Esteban and Guille. > > I would vote for using Build numbers again. > > We would have several BENEFITS when keeping/returning to build numbers for > Pharo 7: > - we do not change image file names, about box behavior, ... compared to > previous Pharo version < 7 > (as we used image build number already in the past) > - we tag each release as before and see it in Git (we can easily reproduce) > - the build number easily tells you which image is more recent (as before) > - we can easily sort when we have several images in a directory > - a build number is more readable and recognizable by a human (compared to > the shas) > - Pharo is not an "aliens" compared to the rest of the software world as > often software > follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) > - we do not change the order in Launcher (higher numbers at the top to > download more recent) > > According to the discussion with Esteban and Pavel it is technically > possible to have build numbers again - > it means to tag each commit again with a build number (we already did this > for Pharo 6, > see https://github.com/pharo-project/pharo/releases) > > The outcome from yesterday was that Pavel will discuss again with Guile on > that topic. It would be good if others > could comment on that topic too. Maybe we can return to the known build > number scheme > or (if there are problems with that) at least know the arguments why we need > to be exotic/different on > this corner in the future. > > Thanks > T. > > Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr > Von: "Ben Coman" <btc(a)openinworld.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names > > Attached is what I see for Pharo 7 images in PharoLauncher. > I presume the top one is the latest, but Its a bit hard to tell :P > Anyone else seeing this? > > Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) > and doing "ConfigurationOfPharoLauncher loadDevelopment" > which loads PharoLauncher-Core-ChristopheDemarey.116 (latest) > > This is with Pharo builds 60486 and 60510, and same VM for both... > Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker > versionString VM: 201705310241 > CoInterpreter VMMaker.oscog-eem.2231 uuid: > de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 > > (but btw, does that look strange? The 60510 image was lauched from the > original 60486-PharoLauncher which said it was downloading the matching VM, > so I kind of expect each image to have a different VM ?? ) > > cheers -ben

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Stephane Ducasse

So one step at a time: - #cr and #lf just put this character in the stream. - #newLine put the underlying OS line ending. ( and sorry for the nostalgic but nl sucks and to me this is netherlands and not newline :). Then we should revisit all the cr inside the system and use newline. Then we should think about the internal usage of cr by default in Pharo (We should change it). Does it make sense? Stef On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Friday 04 August 2017 07:11 PM, Damien Pollet wrote: >> >> Stream >> newLineFor: platform >> self nextPutAll: platform lineEnding >> > > EOL encoding is a property of a text file and not a platform. While files > created on a certain proprietary platforms ;-) may use an encoding that does > not make it a platform property. Pharo should be liberal in accepting and > preserving differently encoded files. E.g. Text editor vim has a setting > (fileformats) for eol encoding to view or edit files with cr or crlf EOL > encoding. If this is not set, vim falls back to nl. > > I agree that existing messages like cr or nl should not be changed. Instead > new methods (*eol) could be added to text files for decoding (read side) and > encoding (write side). This should be liberal in accepting cr, nl, crnl > decodes while reading a text file. While writing a new stream, eol should > follow this order: > 1. if file eol property is set (cr/nl/crnl) it should use it > 2. else fallback to check platform eol property. > 3. Else, use cr (for backward compatibility with old files) > E.g. > > (aStream atEOL) ifFalse: [ c := aStream next ] > aStream nextPutAll: 'hello world' ; writeEOL > record := aStream readLine. "strip eol" > aStream nextPutLine: 'hello world' > > This is not going to be an easy change but it would make new code cleaner. > > Regards .. Subbu >

Aug. 5, 2017

Re: [Pharo-dev] [ann] moldable brick editor - alpha

by Esteban A. Maringolo

It seems to be very snappy considering the size of the file and its amount of characters. I still don't get how Bloc and Brick plays in current Pharo, nor what this "moldability" adds to it. But performancewise it seems to be an improvement over the existing editor (Rubric?). Congratulations! Esteban A. Maringolo 2017-08-05 7:52 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > This is gorgeous! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > On Aug 4, 2017, at 6:19 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > We are very happy to announce the alpha version of a moldable editor > built in Brick (https://github.com/pharo-graphics/Brick) which is based > on Bloc (https://github.com/pharo-graphics/Bloc) This is primarily the > work of Alex Syrel. The project was initially financially sponsored by ESUG > and it is currently supported by feenk. And of course, the project is based > on the tremendous work that went into Bloc and Brick by all contributors. > > > > Take a look at this 2 min video: > > https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be > > > > The basic editor works and it is both flexible and scalable. For > example, the last example shown in the video is an editor opened on 1M > characters, which is reasonably large, and as can be seen see one can > interact with it as smoothly as with the one screen text. It actually works > just as fine with 100M characters. > > > > The functionality of the editor includes: rendering, line wrapping, > keypress and shortcut handling, navigation, selection and text styling. > Currently, the editor is 1260 lines of code including method and class > comments. This is not large for a text editor and this is possible because > most of the work is done by generic concepts that already exist in Bloc > such as layouts and text measurements. Beside the small maintenance cost, > the benefit is that we have the option to build all sorts of variations > with little effort. That is why we call this a moldable text editor. > > > > Another benefit of using elements and layouts is that we can also embed > other kinds of non-text elements with little effort (such as pictures), and > obtain a rich and live text editor. We already have basic examples for this > behavior, and we will focus more in the next period on this area. > > > > The next immediate step is to add syntax highlighting. Beside the text > attributes problem, this issue will also exercise the thread-safety the > implementation is. The underlying structure (https://en.wikipedia.org/ > wiki/Rope_(data_structure)) is theoretically thread-safe, but it still > needs to be proven in practice. > > > > We think this is a significant step because the editor was the main > piece missing in Brick and it will finally allow us to build value that can > be directly perceived by regular users on top of Brick and this, in turn, > will generate more traction. Please also note that because now Bloc is > directly embeddable in Morphic it means that we can actually start using it > right away. For example, the picture below shows the text element being > shown through a live preview in the GTInspector. > > > > <AC36A55F-405C-6147-9E0F-BA1F6F1008BA.png> > > > > This is another puzzle piece towards the final goal of engineering the > future of the Pharo user interface. There is still a long way to go to > reach that goal, but considering the work that is behind us, that goal that > looked so illusive when Alain and Stef initiated the Bloc project is now > palpable. > > > > We will continue the work on this over the next period and we expect to > announce new developments soon. > > > > If you want to play with it, you can load the code like this (works in > both Pharo 6 and 7): > > Iceberg enableMetacelloIntegration: true. > > Metacello new > > baseline: 'Brick'; > > repository: 'github://pharo-graphics/Brick/src'; > > load: #development > > > > Please let us know what you think. > > > > Cheers, > > Alex and Doru > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "What is more important: To be happy, or to make happy?" > > > > >

Aug. 5, 2017

Re: [Pharo-dev] [ann] moldable brick editor - alpha

by philippe.back＠highoctane.be

Awesome news. Maybe will we have a way to get vim style bindings with it. Will we? Phil On Aug 5, 2017 00:20, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: > Hi, > > We are very happy to announce the alpha version of a moldable editor built > in Brick (https://github.com/pharo-graphics/Brick) which is based on > Bloc (https://github.com/pharo-graphics/Bloc) This is primarily the work > of Alex Syrel. The project was initially financially sponsored by ESUG and > it is currently supported by feenk. And of course, the project is based on > the tremendous work that went into Bloc and Brick by all contributors. > > Take a look at this 2 min video: > https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be > > The basic editor works and it is both flexible and scalable. For example, > the last example shown in the video is an editor opened on 1M > characters, which is reasonably large, and as can be seen see one can > interact with it as smoothly as with the one screen text. It actually works > just as fine with 100M characters. > > The functionality of the editor includes: rendering, line wrapping, > keypress and shortcut handling, navigation, selection and text styling. > Currently, the editor is 1260 lines of code including method and class > comments. This is not large for a text editor and this is possible because > most of the work is done by generic concepts that already exist in Bloc > such as layouts and text measurements. Beside the small maintenance cost, > the benefit is that we have the option to build all sorts of variations > with little effort. That is why we call this a moldable text editor. > > Another benefit of using elements and layouts is that we can also embed > other kinds of non-text elements with little effort (such as pictures), > and obtain a rich and live text editor. We already have basic examples for > this behavior, and we will focus more in the next period on this area. > > The next immediate step is to add syntax highlighting. Beside the text > attributes problem, this issue will also exercise the thread-safety > the implementation is. The underlying structure (https://en.wikipedia.org/ > wiki/Rope_(data_structure)) is theoretically thread-safe, but it still > needs to be proven in practice. > > We think this is a significant step because the editor was the main piece > missing in Brick and it will finally allow us to build value that can be > directly perceived by regular users on top of Brick and this, in turn, will > generate more traction. Please also note that because now Bloc is directly > embeddable in Morphic it means that we can actually start using it right > away. For example, the picture below shows the text element being shown > through a live preview in the GTInspector. > > [image: Playground @ â¢ a8rEditorE1ement x Page â BrRopedText string: > Emphasizing everything text : nothing' text attributes: { > BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri > bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: > from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } > from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng > to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever > thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: > Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. > BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 > from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: > (BrTextEdi tor new text: text) .] > > This is another puzzle piece towards the final goal of engineering the > future of the Pharo user interface. There is still a long way to go to > reach that goal, but considering the work that is behind us, that goal that > looked so illusive when Alain and Stef initiated the Bloc project is now > palpable. > > We will continue the work on this over the next period and we expect to > announce new developments soon. > > If you want to play with it, you can load the code like this (works in > both Pharo 6 and 7): > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'Brick'; > repository: 'github://pharo-graphics/Brick/src'; > load: #development > > Please let us know what you think. > > Cheers, > Alex and Doru > > > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > >

Aug. 5, 2017