Something along the lines of:
Proc register pattern: 'open {parm}' action: [ :parm | <do something with
parm> ].
and we register a couple snippets who get recognized.
Or we can go the full interpreter route. Ah, we're back to Tcl!
http://wiki.tcl.tk/463
Phil
On Wed, Sep 10, 2014 at 11:29 PM, kilon alios <[email protected]> wrote:
> no my idea is to not affect Pharo internals at all, and instead the parser
> maps to regular existing pharo messages of existing pharo classes. No need
> to create new classes and new method just create your pharo shortcut and
> map it to a specific method. I am also interested to mapping several
> shortcuts to a single method so you can send the message different ways.
> Probably they end up inside a dictionary or something.
>
> The same way you have shortcuts for files. You dont need to create a new
> folder for them you just create the shortcut directly and like shortcuts
> can mix with other files, so pharo shortcuts should mix with pharo code
> without having to switch syntax. Let the secondary parser parse the
> shortucts to pharo syntax and then let pharo do its own thing.
>
> By the way the idea of petitparser is probably one of the best, I have
> only played with regular expression but this will need something as
> powerful as pettitparser. I have read the chapter in Deep Into Pharo , its
> time to put it to good use :)
>
> On Wed, Sep 10, 2014 at 6:42 PM, [email protected] <[email protected]>
> wrote:
>
>> Alternative would be that each open, print etc is an object of class
>> Command with some methods.
>> Le 10 sept. 2014 17:32, "[email protected]" <[email protected]> a
>> écrit :
>>
>> A
>>> Le 10 sept. 2014 17:21, "kilon alios" <[email protected]> a écrit :
>>> >
>>> > how about introducing a secondary parser on top of the code editor
>>> that you can enable disable at will and can create "code shortcuts" using
>>> such symbols ? it will then store them as regular pharo syntax without
>>> affecting the pharo system. Its an idea I am thinking playing with but not
>>> so much for special class names but rather omitting the class names
>>> altogether and create shorter version of calling a method that is more
>>> English like, like :
>>> >
>>> > open "mydoc.pdf" in documents.
>>> > display pdf.
>>> > go to page 4.
>>> > print page
>>>
>>> I would do that with a dedicated petit parser grammar.
>>>
>>> As for highlighthing the styler stuff is unknown territory for me.
>>>
>>> In the GT doc / pillar stuff, I saw Interesting stuff going on on Doru's
>>> blog.
>>>
>>> Phil
>>> >
>>> >
>>> > On Wed, Sep 10, 2014 at 6:13 PM, [email protected] <
>>> [email protected]> wrote:
>>> >>
>>> >> Of course. But there are some other things that are available.
>>> >>
>>> >> §, `, ? comes to mind.
>>> >>
>>> >> Phil
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Sep 10, 2014 at 4:59 PM, Marcus Denker <
>>> [email protected]> wrote:
>>> >>>
>>> >>>
>>> >>> On 10 Sep 2014, at 16:38, [email protected] wrote:
>>> >>>
>>> >>> > I was playing around with the idea of using stuff like in jQuery,
>>> where we do have the '$' function that would do a lot of things.
>>> >>> >
>>> >>> > But one cannot create such elements as
>>> >>> >
>>> >>> > SlotClassBuilder>>validateClassName
>>> >>> > "Validate the new class name. Raise warning if invalid."
>>> >>> >
>>> >>> > name
>>> >>> > detect: [ :c | (c isAlphaNumeric or: [ c = $_ ]) not
>>> ]
>>> >>> > ifFound: [ :c | InvalidGlobalName signal: 'Invalid
>>> character: ''' , c printString , '''' for: name ].
>>> >>> > name first canBeGlobalVarInitial
>>> >>> > ifFalse: [ InvalidGlobalName signal: 'Class name
>>> does not start with a valid Global Var Initial' for: name ]
>>> >>> >
>>> >>> > doesn't let us.
>>> >>> >
>>> >>> > Is there a reason for that (ok, we have $ for chars, and #, ...
>>> and other things but still).
>>> >>> >
>>> >>>
>>> >>> The problem is that $ is part of the smalltalk grammar for symbols,
>>> $ can not be a variable name.
>>> >>>
>>> >>> $asdasd
>>> >>>
>>> >>> is parsed as a message send to the character a, for example.
>>> >>>
>>> >>> Marcus
>>> >>
>>> >>
>>> >
>>>
>>
>
