My 2 cents: we need a diff model. Because for now there is TextDiffBuilder which “diffs” text by lines i.e. bad granularity, and there is a DiffMorph that produces nice diffs but it’s hard to reuse it in other contexts.
Uko > On 22 Jun 2015, at 15:18, Martin Dias <tinchod...@gmail.com> wrote: > > After debugging a bit and discovering the mess around... I think the best > decision is to first migrate the DiffMorph to the new text widget, and then > see... > > Martín > > > > > On Mon, Jun 22, 2015 at 9:53 AM, Thierry Goubier <thierry.goub...@gmail.com > <mailto:thierry.goub...@gmail.com>> wrote: > > > 2015-06-22 9:11 GMT+02:00 Marcus Denker <marcus.den...@inria.fr > <mailto:marcus.den...@inria.fr>>: > > > On 17 Jun 2015, at 18:54, Martin Dias <tinchod...@gmail.com > > <mailto:tinchod...@gmail.com>> wrote: > > > > Hello, > > > > Suppose that you want to show the diff between the source code of two > > methods. In the case that both methods are in the same class, and that such > > class is present in the system, then no problem: In a DiffModel, one can > > set a context to the smalltalk syntax styler and get a nice output. > > > > DiffModel new > > leftText: (Point >> #x) sourceCode; > > rightText: (Point >> #y) sourceCode; > > contextClass: Point; > > openWithSpec. > > > > <Screen Shot 2015-06-17 at 18.33.22.png> > > > > But what happens in the case that the class does not exist in the system? > > > > If one doesn't set any context to the styler, then the string will be shown > > all in black, which is not nice. A partial solution could be to set Object > > as a context, then the styler will color the code, but instance variables > > are in red: > > > > DiffModel new > > leftText: (Point >> #x) sourceCode; > > rightText: (Point >> #y) sourceCode; > > contextClass: Object; > > openWithSpec. > > > > <Screen Shot 2015-06-17 at 18.33.27.png> > > > > Which is also not nice. In my opinion, there should be a styler that just > > colors the code following the syntax, without checking if the variables or > > classes are present in the system. It would be an environment-independent > > styler. > > > > What do you recommend to implement this? I guess it should be easy to > > subclass SHTextStylerST80 and override some methods to do not check > > anything in the environment. > > > > What's your opinion? > > > > Right now we have the problem that we have 3 Stylers… (for the old text model > one based on Shout, one AST, and one for TxText based on the AST. Ah, and > Rubric subclasses the > shout one, too. Which means 4. > > One question is: could a styler fall back onto a being environment > independent as soon as the environment is not set? > > Yes. With a bit of ternary logic which says that symbols are in three states: > defined, undefined and unknown. First two require a context; third one > applies if you don't have a context. > > Thierry >
