Parser is not hardcoded (except in tests), but parserClass is sometimes sent to the wrong class.. Example is Text>>makeSelectorBold (sent from Debugger) It should be replaced with makeSelectorBoldIn: Also notice that source code files cannot be analyzed if they contain classes absent from current system that define their own parserClass. That is a problem for change lists, and possibly for MC (it would be interesting to try). Nicolas 2011/1/10 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Will it work ?
because Compiler class>>new     ^ super new parser: self parserClass new
sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too.
Nicolas
2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 9:46 AM, <pharo@googlecode.com> wrote:
Status: Accepted Owner: siguctua
New issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525
In the following:
Compiler>>parserClass
    ^parser ifNil: [self class parserClass] ifNotNil: [parser class]
Who writes this stuff ?? ;) <blush> I suggest the attached: parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser class]
'self class' should actually be 'class parserClass'
So, any class could override the default parser by own. In that way a default parser class is answered by Behavior, not by Compiler. A Compiler class>>parserClass is useless.
But even more than that, due to initializing 'parser' ivar in Compiler>>new, it never gets to that code, and evaluating 'parser class' So, a class can't specify a custom parser class to compiler.