[Cuis-dev] Making assumptions about source code without checking #compilerClass
pbpublist at gmail.com
Thu May 23 01:35:35 PDT 2019
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
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.
> Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cuis-dev