[Cuis-dev] Making assumptions about source code without checking #compilerClass

[Phil B]

Took me a bit to find an easily reproducible example:

1. git clone https://github.com/pbella/OMeta-Cuis
2. open a Cuis5.0-3760 image
3. install the OMeta2Tests.pck.st from the directory the repo was cloned to
4. open a Message Names browser
5. search for 'form:' (without the quotes)
6. scroll down to the exact match and select it
7. right-click and select senders

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).


On Wed, May 22, 2019 at 7:15 AM Juan Vuletich <juan at jvuletich.org> wrote:

> On 5/22/2019 2:25 AM, Phil B via Cuis-dev wrote:
> > 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.
> >
> > 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.
> >
> > 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.
>
> Hi Phil,
>
> Can you please provide a specific example, with instructions detailed
> enough for someone who knows almost nothing about OMeta to see what
> annoys you?
>
> We have, for example, SmalltalkEditor and SmalltalkCompleter. All editor
> behavior that is specific for Smalltalk code should be in these or other
> Smalltalk specific classes. Then tools could use alternative objects for
> other kinds of text.
>
> I could really use a good example to understand better where and how we
> need to fix stuff.
>
> Thanks,
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190523/66fd4613/attachment-0001.html>