2016-09-14 22:47 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>:
Did you commit your changes with the highlight of == code?
No, but I just saw that I misinterpreted the "==", first I thought this is
for "inline code" as it was used in some class comment like that.
But it is actually a more general formatting tag for "monospaced font" -
we actually don't need to do code highlighting for this text, just use a
monospace font resp. code font.
> On Sep 6, 2016, at 4:56 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote:
> 2016-08-29 21:41 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>:
> I updated the Pillar support in GTInspector. Some of the extensions
already exist in the default Pillar #development version. If you want to
play with the full support, you can load it like this:
> Gofer new
> smalltalkhubUser: 'Moose' project: 'PetitParser';
> package: 'PetitAnalyzer';
> package: 'PetitIndent';
> package: 'PetitIslands';
> smalltalkhubUser: 'Moose' project: 'GToolkit';
> package: 'GT-InspectorExtensions-Pillar';
> Then you can just inspect a book folder and you get this:
> I did not integrate this in the main Pillar yet because this is an older
implementation based on a limited island parser. As now Pillar has a full
parser based on PetitParser, the next step is to move the highlighting
logic to use this parser instead of the island parser. From my
measurements, the speed of the two parsers is about the same, so from a
user perspective there will be not much changes.
> It pains me that we are editing Pillar in outside tools, and now we
should no longer have to do that. Of course, this is not the most ideal
tool support for Pillar but I think it is a reasonable start.
> I just played a bit with the code to apply larger different font sizes
for the headings and
> use the code styler for inlined code ("==").
> Maybe we should use a different code styler or add a way to instruct the
styler to ignore unknown classes or uknown selectors :)
> "Problem solving should be focused on describing
> the problem in a way that makes the solution obvious."
> Moose-dev mailing list
"Obvious things are difficult to teach."