<div dir="ltr">A lot of the recent 'quality of life' improvements due to recent changes have been great... when working with Smalltalk code.   On the other hand, I'm working through some new issues re: OMeta as a result of some of the recent updates and was wondering how to best handle them.<div><br></div><div>One specific example appears to be recent autoselect enhancements which hard-codes the assumption that the AST will match what the user is seeing on screen... often not the case with OMeta code.  (usually, it's not even valid Smalltalk code when in source view)  The way we've handled this sort of issue previously is to always check #compilerClass and have hooks on it for things like #textStylerClass.  I'm not sure if we could/should wedge the autoselect code into #textStylerClass or if a #codeWalkerClass type of solution might be more appropriate.  But if we could do something that works via #compilerClass, as opposed to hard coding the assumptions in the editor, it would be greatly appreciated.   That way I can either override or disable as appropriate for OMeta.</div><div><br></div><div>While my immediate concern is OMeta code, it also seems worth providing a more general solution as it makes the text editing code more flexible for everyone should someone else want to do the same sort of thing for text/HTML/whatever editors.</div></div>