<div dir="ltr">Took me a bit to find an easily reproducible example:<div><br></div><div>1. git clone <a href="https://github.com/pbella/OMeta-Cuis">https://github.com/pbella/OMeta-Cuis</a><br>2. open a Cuis5.0-3760 image<br>3. install the <a href="http://OMeta2Tests.pck.st">OMeta2Tests.pck.st</a> from the directory the repo was cloned to<br>4. open a Message Names browser<br></div><div>5. search for 'form:' (without the quotes)</div><div>6. scroll down to the exact match and select it</div><div>7. right-click and select senders</div><div><br></div><div>At this point you should be looking at a 'key not found' error.  This isn't the only error I'm running into, just the easiest one to reproduce so far.   It happens whenever some bit of code-walking stuff for highlighting etc. gets triggered since the OMeta extensions are largely just a facade.  If editor code assumes that it's always parse-able and/or pokes at OMeta methods too deeply, expected behaviors will fail.  Hence my suggestion that we push that sort of functionality to something tied to #compilerClass that I can either adapt for OMeta (where it translates) or disable (where it doesn't).</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 22, 2019 at 7:15 AM Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/22/2019 2:25 AM, Phil B via Cuis-dev wrote:<br>
> A lot of the recent 'quality of life' improvements due to recent <br>
> changes have been great... when working with Smalltalk code.   On the <br>
> other hand, I'm working through some new issues re: OMeta as a result <br>
> of some of the recent updates and was wondering how to best handle them.<br>
><br>
> One specific example appears to be recent autoselect enhancements <br>
> which hard-codes the assumption that the AST will match what the user <br>
> is seeing on screen... often not the case with OMeta code.  (usually, <br>
> it's not even valid Smalltalk code when in source view)  The way we've <br>
> handled this sort of issue previously is to always check <br>
> #compilerClass and have hooks on it for things like #textStylerClass.  <br>
> I'm not sure if we could/should wedge the autoselect code into <br>
> #textStylerClass or if a #codeWalkerClass type of solution might be <br>
> more appropriate.  But if we could do something that works via <br>
> #compilerClass, as opposed to hard coding the assumptions in the <br>
> editor, it would be greatly appreciated.   That way I can either <br>
> override or disable as appropriate for OMeta.<br>
><br>
> While my immediate concern is OMeta code, it also seems worth <br>
> providing a more general solution as it makes the text editing code <br>
> more flexible for everyone should someone else want to do the same <br>
> sort of thing for text/HTML/whatever editors.<br>
<br>
Hi Phil,<br>
<br>
Can you please provide a specific example, with instructions detailed <br>
enough for someone who knows almost nothing about OMeta to see what <br>
annoys you?<br>
<br>
We have, for example, SmalltalkEditor and SmalltalkCompleter. All editor <br>
behavior that is specific for Smalltalk code should be in these or other <br>
Smalltalk specific classes. Then tools could use alternative objects for <br>
other kinds of text.<br>
<br>
I could really use a good example to understand better where and how we <br>
need to fix stuff.<br>
<br>
Thanks,<br>
<br>
-- <br>
Juan Vuletich<br>
<a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
<a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a><br>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
@JuanVuletich<br>
<br>
</blockquote></div>