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

Thu May 23 07:02:14 PDT 2019

Thanks!

Hernán, Phil, please review #3764 attached. The idea is simply to make 
senders aware of the fact that maybe source range for some parse node 
may be unavailable. This could be because it is OMeta, but in the future 
it could be because of being in some DSL or another language. I think it 
is generally a good idea to make the system robust against this. I'd try 
this approach with other possible tool breakage due to incompatibilities 
with OMeta.

On a completely different node, UnsavedChangesTo−OMeta2−jmv.1.cs.st and 
#3764 avoid the need to override a method in OMeta2Preload.st . 
Hopefully, OMeta2Preload.st could be made a .pck.st.

Finally, Phil, I think having both https://github.com/pbella/OMeta-Cuis  
and https://github.com/Cuis-Smalltalk/Parsers/tree/master/OMeta is 
confusing. If you'd like to host it in the Cuis-Smalltalk org, I can 
give you any permissions needed. If you prefer to host it at 
https://github.com/pbella then in the Cuis-Smalltalk org I'd just 
include an .md pointing to it.

HTH.

Cheers,

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

On 5/23/2019 5:35 AM, Phil B wrote:
> 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 <http://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 
> <mailto: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 <http://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/e0b0fc97/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 3763-missingSourceRanges-forSupportingOMeta-JuanVuletich-2019May23-09h49m-jmv.1.cs.st
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190523/e0b0fc97/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: UnsavedChangesTo-OMeta2-jmv.1.cs.st
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190523/e0b0fc97/attachment-0004.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 3764-HelpOMeta2-JuanVuletich-2019May23-10h40m-jmv.1.cs.st
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190523/e0b0fc97/attachment-0005.ksh>