regex deconstructor

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

regex deconstructor

Matthias Rebbe via use-livecode
Does anyone know of a regex deconstructor?  I've looked but haven't found
one.
I've found lots of evaluators and ones that will throw sample text at a
regex but not one that breaks one down and sort-of explains what it does.

Similarly, going the other way, a regex builder would also be nice, but I
can't seem to find one of those, either

--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
Hi Richard.

I found this site https://regexr.com when I was trying to make a regex
expression that I could use to find GLX calls I used in my stacks excluding
ones that I had already knew I used like glxAppSetProp, glxAppGetProp,
glxAppSetPref, glxAppGetPref.  This was to gauge what I would need to do to
transfer to Levure.


I think this may do some of the things need. As you mouse over parts of the
expression it will explain what it does.  You can also paste sample text to
test your expression on.

BTW Through several rounds of trial and error I came up with this.

(?!glx[Aa]pp_[Gg]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Gg]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Ss]etPref\b)(\bglx)

This found the the only other GLX handlers I was using were

  glxapp_savePrefs
  glxApp_updateAvailable

Now I have to figure out how to get change these to calls to Levure
equivalents.

Martin





--
Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
You could cut it down a bit more...
[GgSs] would replace 2 lines

Could also probably use...
r(ef|op)

(?!glx[Aa]pp_[GgSs]et[Pp]r(ef|op)\(.*\))


On Tue, Jan 23, 2018 at 5:13 PM Martin Koob via use-livecode <
[hidden email]> wrote:

> Hi Richard.
>
> I found this site https://regexr.com when I was trying to make a regex
> expression that I could use to find GLX calls I used in my stacks excluding
> ones that I had already knew I used like glxAppSetProp, glxAppGetProp,
> glxAppSetPref, glxAppGetPref.  This was to gauge what I would need to do to
> transfer to Levure.
>
>
> I think this may do some of the things need. As you mouse over parts of the
> expression it will explain what it does.  You can also paste sample text to
> test your expression on.
>
> BTW Through several rounds of trial and error I came up with this.
>
>
> (?!glx[Aa]pp_[Gg]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Gg]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Ss]etPref\b)(\bglx)
>
> This found the the only other GLX handlers I was using were
>
>   glxapp_savePrefs
>   glxApp_updateAvailable
>
> Now I have to figure out how to get change these to calls to Levure
> equivalents.
>
> Martin
>
>
>
>
>
> --
> Sent from:
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
In reply to this post by Matthias Rebbe via use-livecode
well that might do it.
And don't call me "Richard".

On Tue, Jan 23, 2018 at 6:12 PM, Martin Koob via use-livecode <
[hidden email]> wrote:

> Hi Richard.
>
> I found this site https://regexr.com when I was trying to make a regex
> expression that I could use to find GLX calls I used in my stacks excluding
> ones that I had already knew I used like glxAppSetProp, glxAppGetProp,
> glxAppSetPref, glxAppGetPref.  This was to gauge what I would need to do to
> transfer to Levure.
>
>
> I think this may do some of the things need. As you mouse over parts of the
> expression it will explain what it does.  You can also paste sample text to
> test your expression on.
>
> BTW Through several rounds of trial and error I came up with this.
>
> (?!glx[Aa]pp_[Gg]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]ref\
> (.*\))(?!glx[Aa]pp_[Ss]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Gg]et[
> Pp]rop\(.*\))(?!glx[Aa]pp_[Ss]etPref\b)(\bglx)
>
> This found the the only other GLX handlers I was using were
>
>   glxapp_savePrefs
>   glxApp_updateAvailable
>
> Now I have to figure out how to get change these to calls to Levure
> equivalents.
>
> Martin
>
>
>
>
>
> --
> Sent from: http://runtime-revolution.278305.n4.nabble.com/
> Revolution-User-f278306.html
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
Sorry Mike.  

To reply to the list I use the Nabble site

http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

It displays the wrong author for the posts (the most recent author who
posted to the list for all the posts) so I just looked at who Nabble
indicated the author was rather than check with the list on the runrev.com
site that show the correct author but which don't allow you to reply to the
list.

http://lists.runrev.com/pipermail/use-livecode/

I need to be more careful in future.

Martin.











--
Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
In reply to this post by Matthias Rebbe via use-livecode
Hi Mike (Shirley? ;-))

I bought this years ago - it's brilliant and it builds a tree of what
everything does

https://www.regexbuddy.com/benefits.html

click on the iamge on the right

Kindest Regards Lagi

On 24 January 2018 at 02:00, Mike Kerner via use-livecode <
[hidden email]> wrote:

> well that might do it.
> And don't call me "Richard".
>
> On Tue, Jan 23, 2018 at 6:12 PM, Martin Koob via use-livecode <
> [hidden email]> wrote:
>
> > Hi Richard.
> >
> > I found this site https://regexr.com when I was trying to make a regex
> > expression that I could use to find GLX calls I used in my stacks
> excluding
> > ones that I had already knew I used like glxAppSetProp, glxAppGetProp,
> > glxAppSetPref, glxAppGetPref.  This was to gauge what I would need to do
> to
> > transfer to Levure.
> >
> >
> > I think this may do some of the things need. As you mouse over parts of
> the
> > expression it will explain what it does.  You can also paste sample text
> to
> > test your expression on.
> >
> > BTW Through several rounds of trial and error I came up with this.
> >
> > (?!glx[Aa]pp_[Gg]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]ref\
> > (.*\))(?!glx[Aa]pp_[Ss]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Gg]et[
> > Pp]rop\(.*\))(?!glx[Aa]pp_[Ss]etPref\b)(\bglx)
> >
> > This found the the only other GLX handlers I was using were
> >
> >   glxapp_savePrefs
> >   glxApp_updateAvailable
> >
> > Now I have to figure out how to get change these to calls to Levure
> > equivalents.
> >
> > Martin
> >
> >
> >
> >
> >
> > --
> > Sent from: http://runtime-revolution.278305.n4.nabble.com/
> > Revolution-User-f278306.html
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
@Lagi, yes, exactly.
I found another one last night: regex101.com/  That one is interesting
because it seems to support some expressions that the others do not.

On Wed, Jan 24, 2018 at 8:36 AM, Lagi Pittas via use-livecode <
[hidden email]> wrote:

> Hi Mike (Shirley? ;-))
>
> I bought this years ago - it's brilliant and it builds a tree of what
> everything does
>
> https://www.regexbuddy.com/benefits.html
>
> click on the iamge on the right
>
> Kindest Regards Lagi
>
> On 24 January 2018 at 02:00, Mike Kerner via use-livecode <
> [hidden email]> wrote:
>
> > well that might do it.
> > And don't call me "Richard".
> >
> > On Tue, Jan 23, 2018 at 6:12 PM, Martin Koob via use-livecode <
> > [hidden email]> wrote:
> >
> > > Hi Richard.
> > >
> > > I found this site https://regexr.com when I was trying to make a regex
> > > expression that I could use to find GLX calls I used in my stacks
> > excluding
> > > ones that I had already knew I used like glxAppSetProp, glxAppGetProp,
> > > glxAppSetPref, glxAppGetPref.  This was to gauge what I would need to
> do
> > to
> > > transfer to Levure.
> > >
> > >
> > > I think this may do some of the things need. As you mouse over parts of
> > the
> > > expression it will explain what it does.  You can also paste sample
> text
> > to
> > > test your expression on.
> > >
> > > BTW Through several rounds of trial and error I came up with this.
> > >
> > > (?!glx[Aa]pp_[Gg]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]ref\
> > > (.*\))(?!glx[Aa]pp_[Ss]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Gg]et[
> > > Pp]rop\(.*\))(?!glx[Aa]pp_[Ss]etPref\b)(\bglx)
> > >
> > > This found the the only other GLX handlers I was using were
> > >
> > >   glxapp_savePrefs
> > >   glxApp_updateAvailable
> > >
> > > Now I have to figure out how to get change these to calls to Levure
> > > equivalents.
> > >
> > > Martin
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Sent from: http://runtime-revolution.278305.n4.nabble.com/
> > > Revolution-User-f278306.html
> > >
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> >
> >
> >
> > --
> > On the first day, God created the heavens and the Earth
> > On the second day, God created the oceans.
> > On the third day, God put the animals on hold for a few hours,
> >    and did a little diving.
> > And God said, "This is good."
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
It's amazing how much work it takes to learn enough about this topic to do
something moderately dangerous.  This is my nth attempt to fix the
indenting of LC in Atom and ST.  This time I got some help from King Keith
at ST, but trying to make heads or tails of what he offered (that works
better but not perfectly) is...challenging.

On Wed, Jan 24, 2018 at 8:48 AM, Mike Kerner <[hidden email]>
wrote:

> @Lagi, yes, exactly.
> I found another one last night: regex101.com/  That one is interesting
> because it seems to support some expressions that the others do not.
>
> On Wed, Jan 24, 2018 at 8:36 AM, Lagi Pittas via use-livecode <
> [hidden email]> wrote:
>
>> Hi Mike (Shirley? ;-))
>>
>> I bought this years ago - it's brilliant and it builds a tree of what
>> everything does
>>
>> https://www.regexbuddy.com/benefits.html
>>
>> click on the iamge on the right
>>
>> Kindest Regards Lagi
>>
>> On 24 January 2018 at 02:00, Mike Kerner via use-livecode <
>> [hidden email]> wrote:
>>
>> > well that might do it.
>> > And don't call me "Richard".
>> >
>> > On Tue, Jan 23, 2018 at 6:12 PM, Martin Koob via use-livecode <
>> > [hidden email]> wrote:
>> >
>> > > Hi Richard.
>> > >
>> > > I found this site https://regexr.com when I was trying to make a
>> regex
>> > > expression that I could use to find GLX calls I used in my stacks
>> > excluding
>> > > ones that I had already knew I used like glxAppSetProp, glxAppGetProp,
>> > > glxAppSetPref, glxAppGetPref.  This was to gauge what I would need to
>> do
>> > to
>> > > transfer to Levure.
>> > >
>> > >
>> > > I think this may do some of the things need. As you mouse over parts
>> of
>> > the
>> > > expression it will explain what it does.  You can also paste sample
>> text
>> > to
>> > > test your expression on.
>> > >
>> > > BTW Through several rounds of trial and error I came up with this.
>> > >
>> > > (?!glx[Aa]pp_[Gg]et[Pp]ref\(.*\))(?!glx[Aa]pp_[Ss]et[Pp]ref\
>> > > (.*\))(?!glx[Aa]pp_[Ss]et[Pp]rop\(.*\))(?!glx[Aa]pp_[Gg]et[
>> > > Pp]rop\(.*\))(?!glx[Aa]pp_[Ss]etPref\b)(\bglx)
>> > >
>> > > This found the the only other GLX handlers I was using were
>> > >
>> > >   glxapp_savePrefs
>> > >   glxApp_updateAvailable
>> > >
>> > > Now I have to figure out how to get change these to calls to Levure
>> > > equivalents.
>> > >
>> > > Martin
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Sent from: http://runtime-revolution.278305.n4.nabble.com/
>> > > Revolution-User-f278306.html
>> > >
>> > > _______________________________________________
>> > > use-livecode mailing list
>> > > [hidden email]
>> > > Please visit this url to subscribe, unsubscribe and manage your
>> > > subscription preferences:
>> > > http://lists.runrev.com/mailman/listinfo/use-livecode
>> > >
>> >
>> >
>> >
>> > --
>> > On the first day, God created the heavens and the Earth
>> > On the second day, God created the oceans.
>> > On the third day, God put the animals on hold for a few hours,
>> >    and did a little diving.
>> > And God said, "This is good."
>> > _______________________________________________
>> > use-livecode mailing list
>> > [hidden email]
>> > Please visit this url to subscribe, unsubscribe and manage your
>> > subscription preferences:
>> > http://lists.runrev.com/mailman/listinfo/use-livecode
>> >
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
In reply to this post by Matthias Rebbe via use-livecode
That's because there are several flavors of RegEx. Nice huh?

RegEx is in my opinion the top choice for inducing insanity. I have a utility where you type in what you start with and what you want to end up with and it tries to figure out the regex for it. It's less than perfect as you can imagine.

While RegEx is really handy when you need it, my feeling is to avoid it if at all possible.

Bob S


> On Jan 24, 2018, at 05:48 , Mike Kerner via use-livecode <[hidden email]> wrote:
>
> @Lagi, yes, exactly.
> I found another one last night: regex101.com/  That one is interesting
> because it seems to support some expressions that the others do not.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
Unfortunately I'm trying to fix the indenting in ST, so I'm stuck with it.
Then I asked for help.  The help is definitely better than what I came up
with, but I have a couple of things I want to fix.  The help disappeared,
and I'm having a hell of a time reading this because it uses some advanced
magic.

On Wed, Jan 24, 2018 at 4:04 PM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> That's because there are several flavors of RegEx. Nice huh?
>
> RegEx is in my opinion the top choice for inducing insanity. I have a
> utility where you type in what you start with and what you want to end up
> with and it tries to figure out the regex for it. It's less than perfect as
> you can imagine.
>
> While RegEx is really handy when you need it, my feeling is to avoid it if
> at all possible.
>
> Bob S
>
>
> > On Jan 24, 2018, at 05:48 , Mike Kerner via use-livecode <
> [hidden email]> wrote:
> >
> > @Lagi, yes, exactly.
> > I found another one last night: regex101.com/  That one is interesting
> > because it seems to support some expressions that the others do not.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
Is that the same stuff that Atom uses? I’m not that good at writing RegEx
from scratch, but wouldn’t mind taking a look. I don’t have ST, so I
wouldn’t be able to test there.
On Thu, Jan 25, 2018 at 1:04 PM Mike Kerner via use-livecode <
[hidden email]> wrote:

> Unfortunately I'm trying to fix the indenting in ST, so I'm stuck with it.
> Then I asked for help.  The help is definitely better than what I came up
> with, but I have a couple of things I want to fix.  The help disappeared,
> and I'm having a hell of a time reading this because it uses some advanced
> magic.
>
> On Wed, Jan 24, 2018 at 4:04 PM, Bob Sneidar via use-livecode <
> [hidden email]> wrote:
>
> > That's because there are several flavors of RegEx. Nice huh?
> >
> > RegEx is in my opinion the top choice for inducing insanity. I have a
> > utility where you type in what you start with and what you want to end up
> > with and it tries to figure out the regex for it. It's less than perfect
> as
> > you can imagine.
> >
> > While RegEx is really handy when you need it, my feeling is to avoid it
> if
> > at all possible.
> >
> > Bob S
> >
> >
> > > On Jan 24, 2018, at 05:48 , Mike Kerner via use-livecode <
> > [hidden email]> wrote:
> > >
> > > @Lagi, yes, exactly.
> > > I found another one last night: regex101.com/  That one is interesting
> > > because it seems to support some expressions that the others do not.
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
It's similar.  It takes a bit of massaging to get one into the other,
especially once you get into the more advanced regex because there are
features that one supports and the other doesn't.  ST's regex engine is
customized more than Atom's is.

Here's the proposed not-quite-final indent rules file:


<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>name</key>
<string>LiveCode Script Indentation</string>
<key>scope</key>
<string>source.livecode</string>
<key>settings</key>
<!-- documenation found at
http://docs.sublimetext.info/en/latest/reference/metadata.html?highlight=indentation
-->
<dict>
<key>increaseIndentPattern</key>
<string><![CDATA[(?x)
(?<comment>\s*(?:\#|--|/\*)){0}
(?<eol_or_comment>\g<comment>|\s*\\?$){0}
^\s*
(
(on\s)
| (private\s+)?(command|function)\s+
| (else\g<eol_or_comment>)
| (else\s+)?
(if\s+.+?)?
\bthen\g<eol_or_comment>
| repeat\s
| switch\s
| case\s
| default\b
| try\b
| catch\b
| finally\b
)
]]></string>
<key>decreaseIndentPattern</key>
<string>(?x)
^\s*
(
end\s+.
| case\s+.
| default\b
| catch\b
| finally\b
)
</string>
<key>unIndentedLinePattern</key>
<!-- ignore any lines matching this pattern when computing the next line's
indent level -->
<string>^\s*(?:#|--|/\*)</string><!-- i.e. any comments -->
</dict>
</dict>
</plist>

On Thu, Jan 25, 2018 at 7:16 PM, Brian Milby via use-livecode <
[hidden email]> wrote:

> Is that the same stuff that Atom uses? I’m not that good at writing RegEx
> from scratch, but wouldn’t mind taking a look. I don’t have ST, so I
> wouldn’t be able to test there.
> On Thu, Jan 25, 2018 at 1:04 PM Mike Kerner via use-livecode <
> [hidden email]> wrote:
>
> > Unfortunately I'm trying to fix the indenting in ST, so I'm stuck with
> it.
> > Then I asked for help.  The help is definitely better than what I came up
> > with, but I have a couple of things I want to fix.  The help disappeared,
> > and I'm having a hell of a time reading this because it uses some
> advanced
> > magic.
> >
> > On Wed, Jan 24, 2018 at 4:04 PM, Bob Sneidar via use-livecode <
> > [hidden email]> wrote:
> >
> > > That's because there are several flavors of RegEx. Nice huh?
> > >
> > > RegEx is in my opinion the top choice for inducing insanity. I have a
> > > utility where you type in what you start with and what you want to end
> up
> > > with and it tries to figure out the regex for it. It's less than
> perfect
> > as
> > > you can imagine.
> > >
> > > While RegEx is really handy when you need it, my feeling is to avoid it
> > if
> > > at all possible.
> > >
> > > Bob S
> > >
> > >
> > > > On Jan 24, 2018, at 05:48 , Mike Kerner via use-livecode <
> > > [hidden email]> wrote:
> > > >
> > > > @Lagi, yes, exactly.
> > > > I found another one last night: regex101.com/  That one is
> interesting
> > > > because it seems to support some expressions that the others do not.
> > >
> > >
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> >
> >
> >
> > --
> > On the first day, God created the heavens and the Earth
> > On the second day, God created the oceans.
> > On the third day, God put the animals on hold for a few hours,
> >    and did a little diving.
> > And God said, "This is good."
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
On first look, I see the same terms in the increase and decrease RegEx.
I’ll need to figure out where the Atom data is and look at it in my seat.

Do you have any specific recipes that are not acting correctly that I could
walk through?
On Thu, Jan 25, 2018 at 6:44 PM Mike Kerner via use-livecode <
[hidden email]> wrote:

> It's similar.  It takes a bit of massaging to get one into the other,
> especially once you get into the more advanced regex because there are
> features that one supports and the other doesn't.  ST's regex engine is
> customized more than Atom's is.
>
> Here's the proposed not-quite-final indent rules file:
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <plist version="1.0">
> <dict>
> <key>name</key>
> <string>LiveCode Script Indentation</string>
> <key>scope</key>
> <string>source.livecode</string>
> <key>settings</key>
> <!-- documenation found at
>
> http://docs.sublimetext.info/en/latest/reference/metadata.html?highlight=indentation
> -->
> <dict>
> <key>increaseIndentPattern</key>
> <string><![CDATA[(?x)
> (?<comment>\s*(?:\#|--|/\*)){0}
> (?<eol_or_comment>\g<comment>|\s*\\?$){0}
> ^\s*
> (
> (on\s)
> | (private\s+)?(command|function)\s+
> | (else\g<eol_or_comment>)
> | (else\s+)?
> (if\s+.+?)?
> \bthen\g<eol_or_comment>
> | repeat\s
> | switch\s
> | case\s
> | default\b
> | try\b
> | catch\b
> | finally\b
> )
> ]]></string>
> <key>decreaseIndentPattern</key>
> <string>(?x)
> ^\s*
> (
> end\s+.
> | case\s+.
> | default\b
> | catch\b
> | finally\b
> )
> </string>
> <key>unIndentedLinePattern</key>
> <!-- ignore any lines matching this pattern when computing the next line's
> indent level -->
> <string>^\s*(?:#|--|/\*)</string><!-- i.e. any comments -->
> </dict>
> </dict>
> </plist>
>
> On Thu, Jan 25, 2018 at 7:16 PM, Brian Milby via use-livecode <
> [hidden email]> wrote:
>
> > Is that the same stuff that Atom uses? I’m not that good at writing RegEx
> > from scratch, but wouldn’t mind taking a look. I don’t have ST, so I
> > wouldn’t be able to test there.
> > On Thu, Jan 25, 2018 at 1:04 PM Mike Kerner via use-livecode <
> > [hidden email]> wrote:
> >
> > > Unfortunately I'm trying to fix the indenting in ST, so I'm stuck with
> > it.
> > > Then I asked for help.  The help is definitely better than what I came
> up
> > > with, but I have a couple of things I want to fix.  The help
> disappeared,
> > > and I'm having a hell of a time reading this because it uses some
> > advanced
> > > magic.
> > >
> > > On Wed, Jan 24, 2018 at 4:04 PM, Bob Sneidar via use-livecode <
> > > [hidden email]> wrote:
> > >
> > > > That's because there are several flavors of RegEx. Nice huh?
> > > >
> > > > RegEx is in my opinion the top choice for inducing insanity. I have a
> > > > utility where you type in what you start with and what you want to
> end
> > up
> > > > with and it tries to figure out the regex for it. It's less than
> > perfect
> > > as
> > > > you can imagine.
> > > >
> > > > While RegEx is really handy when you need it, my feeling is to avoid
> it
> > > if
> > > > at all possible.
> > > >
> > > > Bob S
> > > >
> > > >
> > > > > On Jan 24, 2018, at 05:48 , Mike Kerner via use-livecode <
> > > > [hidden email]> wrote:
> > > > >
> > > > > @Lagi, yes, exactly.
> > > > > I found another one last night: regex101.com/  That one is
> > interesting
> > > > > because it seems to support some expressions that the others do
> not.
> > > >
> > > >
> > > > _______________________________________________
> > > > use-livecode mailing list
> > > > [hidden email]
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > >
> > >
> > >
> > >
> > > --
> > > On the first day, God created the heavens and the Earth
> > > On the second day, God created the oceans.
> > > On the third day, God put the animals on hold for a few hours,
> > >    and did a little diving.
> > > And God said, "This is good."
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
I did take a look at Atom and is also has some duplicates in the
increase/decrease sections.  It seems to work to out dent the line.  For
example, if you type “switch” the next line will start indented one level.
When you type “case” it moves that line out and the next one is indented.
This actually works fine in normal use.  In the middle of the case block
you are already indented.  Starting a new case will push that line out.
The down side is that you have to manually indent the first case after it
gets pushed out.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
@Brian,
Which attempt are you talking about?  We have two:  The one I posted a
couple of days ago is the proposed new one from King Keith at the ST
newsgroup.  The other is the one I wrote back in March and is in the
livecode-sublimetext repo.

The one for Atom is also one that I wrote after I finished the one for ST.

Both the new and old ST ones have issues.

On Sat, Jan 27, 2018 at 6:49 PM, Brian Milby via use-livecode <
[hidden email]> wrote:

> I did take a look at Atom and is also has some duplicates in the
> increase/decrease sections.  It seems to work to out dent the line.  For
> example, if you type “switch” the next line will start indented one level.
> When you type “case” it moves that line out and the next one is indented.
> This actually works fine in normal use.  In the middle of the case block
> you are already indented.  Starting a new case will push that line out.
> The down side is that you have to manually indent the first case after it
> gets pushed out.
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
I’ve only looked at the ST in this thread and the Atom version that is
available inside the app.

I’ve tried a little but have not seen clear documentation on how the
various indent rules are handled. From how it works, if a RegEx is in both
indent and unindent then the current line is pushed left and next line is
indented.

What issues are you trying to fix? It is somewhat complicated since it only
looks at one line at a time.
On Sun, Jan 28, 2018 at 4:25 PM Mike Kerner via use-livecode <
[hidden email]> wrote:

> @Brian,
> Which attempt are you talking about?  We have two:  The one I posted a
> couple of days ago is the proposed new one from King Keith at the ST
> newsgroup.  The other is the one I wrote back in March and is in the
> livecode-sublimetext repo.
>
> The one for Atom is also one that I wrote after I finished the one for ST.
>
> Both the new and old ST ones have issues.
>
> On Sat, Jan 27, 2018 at 6:49 PM, Brian Milby via use-livecode <
> [hidden email]> wrote:
>
> > I did take a look at Atom and is also has some duplicates in the
> > increase/decrease sections.  It seems to work to out dent the line.  For
> > example, if you type “switch” the next line will start indented one
> level.
> > When you type “case” it moves that line out and the next one is indented.
> > This actually works fine in normal use.  In the middle of the case block
> > you are already indented.  Starting a new case will push that line out.
> > The down side is that you have to manually indent the first case after it
> > gets pushed out.
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
There are nice tests for indentation on Git for Livecode

https://github.com/livecode/livecode-ide/tree/develop/tests/scripteditor/_indentation_tests

especially the if variants are mind boggling

Kind regards

Bernd



--
Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
I'm not sure why they have some of those the way they have them.  The
indent regex in ST is not well documented (that I can find).  For example,
I don't think "<" is a reserved character in regex, but ST requires you to
treat it as you would in html, i.e. "&lt;"

The first thing that I'm trying to do with this new set of indent rules is
add a "block", so that we can do code folding using arbitrary structures.
I have been using a commented HTML-type tag to designate a block.
For example
#<populate db>
...
#</populate db>

The contents of the commented tag are not important to the indenting, nor
is ensuring that the comment at the top and the bottom are the same.  What
I am trying to get is an indent following #<...> and an unindent at
#</...>.  Also, I don't really care if the comment begins with #.  It could
also begin with -- or // since other folks might like those comment
delimiters better than #.



FWIW, the (buggy) one that I came up with looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>name</key>
<string>LiveCode Script Indentation</string>
<key>scope</key>
<string>source.livecode</string>
<key>settings</key>
<!-- documenation found at
http://docs.sublimetext.info/en/latest/reference/metadata.html?highlight=indentation
-->
<dict>
<key>increaseIndentPattern</key>
<string>^\s*?((on\s+?.+)|((private\s)?((command|function)\s+?.+))|((else?\s*)?(if\s+?.+then\s*?)((#|--).*?)?$)|(else\s*?((#|--).*?)?$)|(repeat\s+?.+)|(switch\s?.+)|(case\s+?.+)|(default.*)|(try\s*?.*)|(catch\s+?.+)|(finally\s?.*)|((#|--|)\s*?&lt;\s*?[^/].*?&gt;))</string>
<key>decreaseIndentPattern</key>
<string>^\s*((end\s+?.+)|(case\s+?.+)|(default\s*?.*)|(else.*)|(catch\s+?.+)|(finally\s*?.*)|((#|--|)\s*?&lt;/.*?&gt;))</string>
<key>disableIndentNextLinePattern</key>
<!-- rules for when then next line would not be indented further -->
<string>^\s*?(if\s+?.+?then\s+?.+)</string>
<key>bracketIndentNextLinePattern</key>
<!-- if current line matches then next line (and only next line) indented 1
level further -->
<string></string>
<key>unIndentedLinePattern</key>
<!-- ignore any lines matching this pattern when computing the next line's
indent level -->
<string></string>
</dict>
</dict>
</plist>


And the rationale file that I wrote so I could figure out wth I was
thinking is:
RegEx can be complicated, so here is the rationale for the regex for the
various sections in the tab settings:

increaseIndentPattern:
^\s*? Begin the line with 0..n whitespace characters due to indents or
other things
(
(on\s+?.+) "on", followed by at least one space, then a handler name - e.g.
"on myHandler"

|((private\s)?((command|function)\s+?.+)) Either "private" and a space or
neither, then either "command" or "function",
then a space, a function name and perhaps parameters, e.g. "private
function myFunction a, b" or "function myFunction a, b"
|((else?\s*?)?(if\s+?.+then\s*?)((#|--).*?)?$) Either "else" and a space or
neither, then "if", a space, some condition,
"then", and possibly some spaces (but nothing else, i.e. no other
commands/functions) following.  The line can end with a comment, either
beginning with "#" or "--".  e.g. "if x then", or "if x then #this is why",
or "else if x then --perhaps nothing".  The goal is to distinguish between
if-then{-else} blocks and single-line if-then{-else} statements - the
latter do not get indented.

|(else\s*?((#|--).*?)?$) "else", then spaces (or not), but no other
statements.  The line can end with a
comment, either beginning with "#" or "--".  e.g. "else", or "else #we have
work to do" or "else -- i forget".

|(repeat\s+?.+) "repeat", then at least one space, and the rest of the
statement, e.g. "repeat
100 times" or "repeat with i = 1 to 10" or "repeat for each x in y"

|(switch\s+?.+) "switch", then at least 1 space, and the rest of the
expression, e.g. "switch x"
See below for a note on the indenting of switch/case/default.

|(case\s+?.+) "case", then at least one space, then the value or condition,
e.g. "case 1".
See below for a note on the indenting of switch/case/default

|(default\s*?.+) "default" and whatever after it.  I didn't bother to use
the indent rules to
enforce default syntax, because I can't think of any time other than in a
"switch" where "default" would be used, and if the user screws up the
syntax, the linter should complain.  At any rate, the line could still end
with a comment, legitimately.  e.g. "default", "default -- something", or
"default #nothing else matters".
See below for a note on the indenting of switch/case/default

|(try\s*?.+) "try" and whatever follows.  Linter can enforce syntax, but I
want to make sure
we allow the user to put a comment at the end of the line, thus adding the
".+"
e.g. "try" or "try #something"

|(catch\s+?.+) "catch", then a space, and the error variable, e.g. "catch a"

|(finally\s*?.*) "finally", and if desired, some whitespace, and maybe a
comment, e.g.
"finally", or "finally #we're done".  Let the linter catch if something
else was put at the end of the line, where I am recognizing that there
might be a comment, instead.

|((#|--|)\s*?&lt;\s*?[^/].*&gt;)) Mikey's favorite custom construct, the
block.  The block is not something that
LC handles any differently than any other bit of code, but we can have ST
indent it, which means I can fold it.  Heh.  Heh.  Heh.  It's a comment
with a tag that I use to mark a section of code without having to write a
handler and deal with variable scope issues.
"#" or "--" then perhaps one or more spaces, then "<", then perhaps more
spaces, then anything that isn't a slash "/", then more text, then ">".
e.g. "#<v. 3.0>", or "# <loads the documents>".  The reason for excluding
the "/" is because that is an end tag - it will mark the end of the block,
and we will unindent at that point.
)

NOTE:  Switch and case are set to indent and unindent the way they are b/c
you cannot force a double-back indent.  Consider
switch x
case 1
beep
case 2
beep
default
beep
At this point we are two tab levels in.  There is no way to get "end case"
to move us back two levels, only one.  Therefore, in the
decreaseIndentPattern, we have "case" and "default", to get the indent to
be at the same level as "switch".
switch x
case 1
beep
case 2
beep
default
beep
end case



decreaseIndentPattern
^\s* Line may or may not begin with whitespace
(
(end\s+?.+) "end", then whitespace, then the handler name, e.g. "end
mouseUp"
|(case\s+?.+) "case", then at least one space, then the value or condition,
e.g. "case 1".
See above for a note on the indenting of switch/case/default
|(default\s*?.*) "default" and whatever after it.  I didn't bother to use
the indent rules to
enforce default syntax, because I can't think of any time other than in a
"switch" where "default" would be used, and if the user screws up the
syntax, the linter should complain.  At any rate, the line could still end
with a comment, legitimately.  e.g. "default", "default -- something", or
"default #nothing else matter".
See above for a note on the indenting of switch/case/default
|(else.*) "else" and then whatever.  Every "else" line needs to pull back
one indent,
whether it is a straight "else", or "else if x=y then"
|(catch\s+?.+) "catch", then a space, and the error variable, e.g. "catch a"
|(finally\s*?.*) "finally", and if desired, some whitespace, and maybe a
comment, e.g.
"finally", or "finally #we're done".  Let the linter catch if something
else was put at the end of the line, where I am recognizing that there
might be a comment, instead.
|((#|--|)\s*?&lt;/.*&gt;.*) End of a block (see above for discussion of a
block)
"#" or "--" then perhaps one or more spaces, then "<", then perhaps more
spaces, then a slash "/", then more text, then ">".
e.g. "#</v. 3.0>", or "# </loads the documents>".
)



disableIndentNextLinePattern
^\s*?(if\s+?.+?then\s+?.+) whitespace, perhaps, then "if", then whitespace,
then the condition, "then",
at least one space, and more text.  e.g. "if x=y then beep".
I'm trying to make sure we catch single-line if-then and if-then-else
statements, as those are NOT going to have indented code below them.  Note
that this regex will also match the if/then that has a comment on the end
(e.g. "if x=y then #make sure we notify the user"), BUT, in that case, the
indent will override the "do nothing" rule.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
It's also not clear from the documentation what triggers the current line
to unindent.  If you are typing "end repeat" for instance, the line will
unindent, but the documentation states that the _next_ line will unindent.

On Mon, Jan 29, 2018 at 9:20 AM, Mike Kerner <[hidden email]>
wrote:

> I'm not sure why they have some of those the way they have them.  The
> indent regex in ST is not well documented (that I can find).  For example,
> I don't think "<" is a reserved character in regex, but ST requires you to
> treat it as you would in html, i.e. "&lt;"
>
> The first thing that I'm trying to do with this new set of indent rules is
> add a "block", so that we can do code folding using arbitrary structures.
> I have been using a commented HTML-type tag to designate a block.
> For example
> #<populate db>
> ...
> #</populate db>
>
> The contents of the commented tag are not important to the indenting, nor
> is ensuring that the comment at the top and the bottom are the same.  What
> I am trying to get is an indent following #<...> and an unindent at
> #</...>.  Also, I don't really care if the comment begins with #.  It could
> also begin with -- or // since other folks might like those comment
> delimiters better than #.
>
>
>
> FWIW, the (buggy) one that I came up with looks like this:
> <?xml version="1.0" encoding="UTF-8"?>
> <plist version="1.0">
> <dict>
> <key>name</key>
> <string>LiveCode Script Indentation</string>
> <key>scope</key>
> <string>source.livecode</string>
> <key>settings</key>
> <!-- documenation found at http://docs.sublimetext.info/
> en/latest/reference/metadata.html?highlight=indentation -->
> <dict>
> <key>increaseIndentPattern</key>
> <string>^\s*?((on\s+?.+)|((private\s)?((command|function)
> \s+?.+))|((else?\s*)?(if\s+?.+then\s*?)((#|--).*?)?$)|(else\
> s*?((#|--).*?)?$)|(repeat\s+?.+)|(switch\s?.+)|(case\s+?.+)|
> (default.*)|(try\s*?.*)|(catch\s+?.+)|(finally\s?.*)|((
> #|--|)\s*?&lt;\s*?[^/].*?&gt;))</string>
> <key>decreaseIndentPattern</key>
> <string>^\s*((end\s+?.+)|(case\s+?.+)|(default\s*?.*)|(
> else.*)|(catch\s+?.+)|(finally\s*?.*)|((#|--|)\s*?&lt;/.*?&gt;))</string>
> <key>disableIndentNextLinePattern</key>
> <!-- rules for when then next line would not be indented further -->
> <string>^\s*?(if\s+?.+?then\s+?.+)</string>
> <key>bracketIndentNextLinePattern</key>
> <!-- if current line matches then next line (and only next line) indented
> 1 level further -->
> <string></string>
> <key>unIndentedLinePattern</key>
> <!-- ignore any lines matching this pattern when computing the next line's
> indent level -->
> <string></string>
> </dict>
> </dict>
> </plist>
>
>
> And the rationale file that I wrote so I could figure out wth I was
> thinking is:
> RegEx can be complicated, so here is the rationale for the regex for the
> various sections in the tab settings:
>
> increaseIndentPattern:
> ^\s*? Begin the line with 0..n whitespace characters due to indents or
> other things
> (
> (on\s+?.+) "on", followed by at least one space, then a handler name -
> e.g. "on myHandler"
>
> |((private\s)?((command|function)\s+?.+)) Either "private" and a space or
> neither, then either "command" or "function",
> then a space, a function name and perhaps parameters, e.g. "private
> function myFunction a, b" or "function myFunction a, b"
> |((else?\s*?)?(if\s+?.+then\s*?)((#|--).*?)?$) Either "else" and a space
> or neither, then "if", a space, some condition,
> "then", and possibly some spaces (but nothing else, i.e. no other
> commands/functions) following.  The line can end with a comment, either
> beginning with "#" or "--".  e.g. "if x then", or "if x then #this is why",
> or "else if x then --perhaps nothing".  The goal is to distinguish between
> if-then{-else} blocks and single-line if-then{-else} statements - the
> latter do not get indented.
>
> |(else\s*?((#|--).*?)?$) "else", then spaces (or not), but no other
> statements.  The line can end with a
> comment, either beginning with "#" or "--".  e.g. "else", or "else #we
> have work to do" or "else -- i forget".
>
> |(repeat\s+?.+) "repeat", then at least one space, and the rest of the
> statement, e.g. "repeat
> 100 times" or "repeat with i = 1 to 10" or "repeat for each x in y"
>
> |(switch\s+?.+) "switch", then at least 1 space, and the rest of the
> expression, e.g. "switch x"
> See below for a note on the indenting of switch/case/default.
>
> |(case\s+?.+) "case", then at least one space, then the value or
> condition, e.g. "case 1".
> See below for a note on the indenting of switch/case/default
>
> |(default\s*?.+) "default" and whatever after it.  I didn't bother to use
> the indent rules to
> enforce default syntax, because I can't think of any time other than in a
> "switch" where "default" would be used, and if the user screws up the
> syntax, the linter should complain.  At any rate, the line could still end
> with a comment, legitimately.  e.g. "default", "default -- something", or
> "default #nothing else matters".
> See below for a note on the indenting of switch/case/default
>
> |(try\s*?.+) "try" and whatever follows.  Linter can enforce syntax, but
> I want to make sure
> we allow the user to put a comment at the end of the line, thus adding the
> ".+"
> e.g. "try" or "try #something"
>
> |(catch\s+?.+) "catch", then a space, and the error variable, e.g. "catch
> a"
>
> |(finally\s*?.*) "finally", and if desired, some whitespace, and maybe a
> comment, e.g.
> "finally", or "finally #we're done".  Let the linter catch if something
> else was put at the end of the line, where I am recognizing that there
> might be a comment, instead.
>
> |((#|--|)\s*?&lt;\s*?[^/].*&gt;)) Mikey's favorite custom construct, the
> block.  The block is not something that
> LC handles any differently than any other bit of code, but we can have ST
> indent it, which means I can fold it.  Heh.  Heh.  Heh.  It's a comment
> with a tag that I use to mark a section of code without having to write a
> handler and deal with variable scope issues.
> "#" or "--" then perhaps one or more spaces, then "<", then perhaps more
> spaces, then anything that isn't a slash "/", then more text, then ">".
> e.g. "#<v. 3.0>", or "# <loads the documents>".  The reason for excluding
> the "/" is because that is an end tag - it will mark the end of the block,
> and we will unindent at that point.
> )
>
> NOTE:  Switch and case are set to indent and unindent the way they are b/c
> you cannot force a double-back indent.  Consider
> switch x
> case 1
> beep
> case 2
> beep
> default
> beep
> At this point we are two tab levels in.  There is no way to get "end case"
> to move us back two levels, only one.  Therefore, in the
> decreaseIndentPattern, we have "case" and "default", to get the indent to
> be at the same level as "switch".
> switch x
> case 1
> beep
> case 2
> beep
> default
> beep
> end case
>
>
>
> decreaseIndentPattern
> ^\s* Line may or may not begin with whitespace
> (
> (end\s+?.+) "end", then whitespace, then the handler name, e.g. "end
> mouseUp"
> |(case\s+?.+) "case", then at least one space, then the value or
> condition, e.g. "case 1".
> See above for a note on the indenting of switch/case/default
> |(default\s*?.*) "default" and whatever after it.  I didn't bother to use
> the indent rules to
> enforce default syntax, because I can't think of any time other than in a
> "switch" where "default" would be used, and if the user screws up the
> syntax, the linter should complain.  At any rate, the line could still end
> with a comment, legitimately.  e.g. "default", "default -- something", or
> "default #nothing else matter".
> See above for a note on the indenting of switch/case/default
> |(else.*) "else" and then whatever.  Every "else" line needs to pull back
> one indent,
> whether it is a straight "else", or "else if x=y then"
> |(catch\s+?.+) "catch", then a space, and the error variable, e.g. "catch
> a"
> |(finally\s*?.*) "finally", and if desired, some whitespace, and maybe a
> comment, e.g.
> "finally", or "finally #we're done".  Let the linter catch if something
> else was put at the end of the line, where I am recognizing that there
> might be a comment, instead.
> |((#|--|)\s*?&lt;/.*&gt;.*) End of a block (see above for discussion of a
> block)
> "#" or "--" then perhaps one or more spaces, then "<", then perhaps more
> spaces, then a slash "/", then more text, then ">".
> e.g. "#</v. 3.0>", or "# </loads the documents>".
> )
>
>
>
> disableIndentNextLinePattern
> ^\s*?(if\s+?.+?then\s+?.+) whitespace, perhaps, then "if", then
> whitespace, then the condition, "then",
> at least one space, and more text.  e.g. "if x=y then beep".
> I'm trying to make sure we catch single-line if-then and if-then-else
> statements, as those are NOT going to have indented code below them.  Note
> that this regex will also match the if/then that has a comment on the end
> (e.g. "if x=y then #make sure we notify the user"), BUT, in that case, the
> indent will override the "do nothing" rule.
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: regex deconstructor

Matthias Rebbe via use-livecode
It kind of makes sense for the unindent to apply to the current line.
Usually I think of the end of a block being at the same level as the start.

I’ll take a look at the RegEx you provided. I read through it over the
weekend and understand most of it. Stuff that is missing is the double
indent for line continuation, but I’m not sure that is possible with this.
On Mon, Jan 29, 2018 at 8:48 AM Mike Kerner via use-livecode <
[hidden email]> wrote:

> It's also not clear from the documentation what triggers the current line
> to unindent.  If you are typing "end repeat" for instance, the line will
> unindent, but the documentation states that the _next_ line will unindent.
>
> On Mon, Jan 29, 2018 at 9:20 AM, Mike Kerner <[hidden email]>
> wrote:
>
> > I'm not sure why they have some of those the way they have them.  The
> > indent regex in ST is not well documented (that I can find).  For
> example,
> > I don't think "<" is a reserved character in regex, but ST requires you
> to
> > treat it as you would in html, i.e. "&lt;"
> >
> > The first thing that I'm trying to do with this new set of indent rules
> is
> > add a "block", so that we can do code folding using arbitrary structures.
> > I have been using a commented HTML-type tag to designate a block.
> > For example
> > #<populate db>
> > ...
> > #</populate db>
> >
> > The contents of the commented tag are not important to the indenting, nor
> > is ensuring that the comment at the top and the bottom are the same.
> What
> > I am trying to get is an indent following #<...> and an unindent at
> > #</...>.  Also, I don't really care if the comment begins with #.  It
> could
> > also begin with -- or // since other folks might like those comment
> > delimiters better than #.
> >
> >
> >
> > FWIW, the (buggy) one that I came up with looks like this:
> > <?xml version="1.0" encoding="UTF-8"?>
> > <plist version="1.0">
> > <dict>
> > <key>name</key>
> > <string>LiveCode Script Indentation</string>
> > <key>scope</key>
> > <string>source.livecode</string>
> > <key>settings</key>
> > <!-- documenation found at http://docs.sublimetext.info/
> > en/latest/reference/metadata.html?highlight=indentation -->
> > <dict>
> > <key>increaseIndentPattern</key>
> > <string>^\s*?((on\s+?.+)|((private\s)?((command|function)
> > \s+?.+))|((else?\s*)?(if\s+?.+then\s*?)((#|--).*?)?$)|(else\
> > s*?((#|--).*?)?$)|(repeat\s+?.+)|(switch\s?.+)|(case\s+?.+)|
> > (default.*)|(try\s*?.*)|(catch\s+?.+)|(finally\s?.*)|((
> > #|--|)\s*?&lt;\s*?[^/].*?&gt;))</string>
> > <key>decreaseIndentPattern</key>
> > <string>^\s*((end\s+?.+)|(case\s+?.+)|(default\s*?.*)|(
> > else.*)|(catch\s+?.+)|(finally\s*?.*)|((#|--|)\s*?&lt;/.*?&gt;))</string>
> > <key>disableIndentNextLinePattern</key>
> > <!-- rules for when then next line would not be indented further -->
> > <string>^\s*?(if\s+?.+?then\s+?.+)</string>
> > <key>bracketIndentNextLinePattern</key>
> > <!-- if current line matches then next line (and only next line) indented
> > 1 level further -->
> > <string></string>
> > <key>unIndentedLinePattern</key>
> > <!-- ignore any lines matching this pattern when computing the next
> line's
> > indent level -->
> > <string></string>
> > </dict>
> > </dict>
> > </plist>
> >
> >
> > And the rationale file that I wrote so I could figure out wth I was
> > thinking is:
> > RegEx can be complicated, so here is the rationale for the regex for the
> > various sections in the tab settings:
> >
> > increaseIndentPattern:
> > ^\s*? Begin the line with 0..n whitespace characters due to indents or
> > other things
> > (
> > (on\s+?.+) "on", followed by at least one space, then a handler name -
> > e.g. "on myHandler"
> >
> > |((private\s)?((command|function)\s+?.+)) Either "private" and a space or
> > neither, then either "command" or "function",
> > then a space, a function name and perhaps parameters, e.g. "private
> > function myFunction a, b" or "function myFunction a, b"
> > |((else?\s*?)?(if\s+?.+then\s*?)((#|--).*?)?$) Either "else" and a space
> > or neither, then "if", a space, some condition,
> > "then", and possibly some spaces (but nothing else, i.e. no other
> > commands/functions) following.  The line can end with a comment, either
> > beginning with "#" or "--".  e.g. "if x then", or "if x then #this is
> why",
> > or "else if x then --perhaps nothing".  The goal is to distinguish
> between
> > if-then{-else} blocks and single-line if-then{-else} statements - the
> > latter do not get indented.
> >
> > |(else\s*?((#|--).*?)?$) "else", then spaces (or not), but no other
> > statements.  The line can end with a
> > comment, either beginning with "#" or "--".  e.g. "else", or "else #we
> > have work to do" or "else -- i forget".
> >
> > |(repeat\s+?.+) "repeat", then at least one space, and the rest of the
> > statement, e.g. "repeat
> > 100 times" or "repeat with i = 1 to 10" or "repeat for each x in y"
> >
> > |(switch\s+?.+) "switch", then at least 1 space, and the rest of the
> > expression, e.g. "switch x"
> > See below for a note on the indenting of switch/case/default.
> >
> > |(case\s+?.+) "case", then at least one space, then the value or
> > condition, e.g. "case 1".
> > See below for a note on the indenting of switch/case/default
> >
> > |(default\s*?.+) "default" and whatever after it.  I didn't bother to use
> > the indent rules to
> > enforce default syntax, because I can't think of any time other than in a
> > "switch" where "default" would be used, and if the user screws up the
> > syntax, the linter should complain.  At any rate, the line could still
> end
> > with a comment, legitimately.  e.g. "default", "default -- something", or
> > "default #nothing else matters".
> > See below for a note on the indenting of switch/case/default
> >
> > |(try\s*?.+) "try" and whatever follows.  Linter can enforce syntax, but
> > I want to make sure
> > we allow the user to put a comment at the end of the line, thus adding
> the
> > ".+"
> > e.g. "try" or "try #something"
> >
> > |(catch\s+?.+) "catch", then a space, and the error variable, e.g. "catch
> > a"
> >
> > |(finally\s*?.*) "finally", and if desired, some whitespace, and maybe a
> > comment, e.g.
> > "finally", or "finally #we're done".  Let the linter catch if something
> > else was put at the end of the line, where I am recognizing that there
> > might be a comment, instead.
> >
> > |((#|--|)\s*?&lt;\s*?[^/].*&gt;)) Mikey's favorite custom construct, the
> > block.  The block is not something that
> > LC handles any differently than any other bit of code, but we can have ST
> > indent it, which means I can fold it.  Heh.  Heh.  Heh.  It's a comment
> > with a tag that I use to mark a section of code without having to write a
> > handler and deal with variable scope issues.
> > "#" or "--" then perhaps one or more spaces, then "<", then perhaps more
> > spaces, then anything that isn't a slash "/", then more text, then ">".
> > e.g. "#<v. 3.0>", or "# <loads the documents>".  The reason for excluding
> > the "/" is because that is an end tag - it will mark the end of the
> block,
> > and we will unindent at that point.
> > )
> >
> > NOTE:  Switch and case are set to indent and unindent the way they are
> b/c
> > you cannot force a double-back indent.  Consider
> > switch x
> > case 1
> > beep
> > case 2
> > beep
> > default
> > beep
> > At this point we are two tab levels in.  There is no way to get "end
> case"
> > to move us back two levels, only one.  Therefore, in the
> > decreaseIndentPattern, we have "case" and "default", to get the indent to
> > be at the same level as "switch".
> > switch x
> > case 1
> > beep
> > case 2
> > beep
> > default
> > beep
> > end case
> >
> >
> >
> > decreaseIndentPattern
> > ^\s* Line may or may not begin with whitespace
> > (
> > (end\s+?.+) "end", then whitespace, then the handler name, e.g. "end
> > mouseUp"
> > |(case\s+?.+) "case", then at least one space, then the value or
> > condition, e.g. "case 1".
> > See above for a note on the indenting of switch/case/default
> > |(default\s*?.*) "default" and whatever after it.  I didn't bother to use
> > the indent rules to
> > enforce default syntax, because I can't think of any time other than in a
> > "switch" where "default" would be used, and if the user screws up the
> > syntax, the linter should complain.  At any rate, the line could still
> end
> > with a comment, legitimately.  e.g. "default", "default -- something", or
> > "default #nothing else matter".
> > See above for a note on the indenting of switch/case/default
> > |(else.*) "else" and then whatever.  Every "else" line needs to pull back
> > one indent,
> > whether it is a straight "else", or "else if x=y then"
> > |(catch\s+?.+) "catch", then a space, and the error variable, e.g. "catch
> > a"
> > |(finally\s*?.*) "finally", and if desired, some whitespace, and maybe a
> > comment, e.g.
> > "finally", or "finally #we're done".  Let the linter catch if something
> > else was put at the end of the line, where I am recognizing that there
> > might be a comment, instead.
> > |((#|--|)\s*?&lt;/.*&gt;.*) End of a block (see above for discussion of a
> > block)
> > "#" or "--" then perhaps one or more spaces, then "<", then perhaps more
> > spaces, then a slash "/", then more text, then ">".
> > e.g. "#</v. 3.0>", or "# </loads the documents>".
> > )
> >
> >
> >
> > disableIndentNextLinePattern
> > ^\s*?(if\s+?.+?then\s+?.+) whitespace, perhaps, then "if", then
> > whitespace, then the condition, "then",
> > at least one space, and more text.  e.g. "if x=y then beep".
> > I'm trying to make sure we catch single-line if-then and if-then-else
> > statements, as those are NOT going to have indented code below them.
> Note
> > that this regex will also match the if/then that has a comment on the end
> > (e.g. "if x=y then #make sure we notify the user"), BUT, in that case,
> the
> > indent will override the "do nothing" rule.
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12