Re: regex deconstructor

2018-01-29 Thread Brian Milby via use-livecode 
>
> Based on how it works, indent applies to the next line and unindent
> applies to the current line (in Atom).
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-29 Thread Mike Kerner via use-livecode 
I don't think you can double-indent, and you can't double-unindent, either,
so the case/switch structure for instance is a bit of a hack that we had to
compromise on.
The problem with the indent/unindent applying to the current line is that
the docs say that they apply to the _next_ line.  It would make sense for
the unindent (but not indent) to apply to the current line, but that isn't
the way the docs are written.

On Mon, Jan 29, 2018 at 10:53 AM, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 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 <
> use-livecode@lists.runrev.com> 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 
> > 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. ""
> > >
> > > 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
> > > #
> > > ...
> > > #
> > >
> > > 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:
> > > 
> > > 
> > > 
> > > name
> > > LiveCode Script Indentation
> > > scope
> > > source.livecode
> > > settings
> > > 
> > > 
> > > increaseIndentPattern
> > > ^\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*?\s*?[^/].*?))
> > > decreaseIndentPattern
> > > ^\s*((end\s+?.+)|(case\s+?.+)|(default\s*?.*)|(
> > > else.*)|(catch\s+?.+)|(finally\s*?.*)|((#|--|)\s*?&
> lt;/.*?))
> > > disableIndentNextLinePattern
> > > 
> > > ^\s*?(if\s+?.+?then\s+?.+)
> > > bracketIndentNextLinePattern
> > > 
> > > 
> > > unIndentedLinePattern
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > >
> > > 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",

Re: regex deconstructor

2018-01-29 Thread Brian Milby 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 <
use-livecode@lists.runrev.com> 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 
> 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. ""
> >
> > 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
> > #
> > ...
> > #
> >
> > 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:
> > 
> > 
> > 
> > name
> > LiveCode Script Indentation
> > scope
> > source.livecode
> > settings
> > 
> > 
> > increaseIndentPattern
> > ^\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*?\s*?[^/].*?))
> > decreaseIndentPattern
> > ^\s*((end\s+?.+)|(case\s+?.+)|(default\s*?.*)|(
> > else.*)|(catch\s+?.+)|(finally\s*?.*)|((#|--|)\s*?/.*?))
> > disableIndentNextLinePattern
> > 
> > ^\s*?(if\s+?.+?then\s+?.+)
> > bracketIndentNextLinePattern
> > 
> > 
> > unIndentedLinePattern
> > 
> > 
> > 
> > 
> > 
> >
> >
> > 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

Re: regex deconstructor

2018-01-29 Thread Mike Kerner 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 
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. ""
>
> 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
> #
> ...
> #
>
> 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:
> 
> 
> 
> name
> LiveCode Script Indentation
> scope
> source.livecode
> settings
> 
> 
> increaseIndentPattern
> ^\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*?\s*?[^/].*?))
> decreaseIndentPattern
> ^\s*((end\s+?.+)|(case\s+?.+)|(default\s*?.*)|(
> else.*)|(catch\s+?.+)|(finally\s*?.*)|((#|--|)\s*?/.*?))
> disableIndentNextLinePattern
> 
> ^\s*?(if\s+?.+?then\s+?.+)
> bracketIndentNextLinePattern
> 
> 
> unIndentedLinePattern
> 
> 
> 
> 
> 
>
>
> 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*?\s*?[^/].*)) Mikey's favorite custom construct, the
> block.

Re: regex deconstructor

2018-01-29 Thread Mike Kerner 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. ""

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

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:



name
LiveCode Script Indentation
scope
source.livecode
settings


increaseIndentPattern
^\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*?\s*?[^/].*?))
decreaseIndentPattern
^\s*((end\s+?.+)|(case\s+?.+)|(default\s*?.*)|(else.*)|(catch\s+?.+)|(finally\s*?.*)|((#|--|)\s*?/.*?))
disableIndentNextLinePattern

^\s*?(if\s+?.+?then\s+?.+)
bracketIndentNextLinePattern


unIndentedLinePattern







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*?\s*?[^/].*)) 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. "#", or "# ".  The reason for excluding
the "/" is because that is an end tag - it will

Re: regex deconstructor

2018-01-28 Thread BNig 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-28 Thread Brian Milby 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 <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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
> > use-livecode@lists.runrev.com
> > 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-28 Thread Mike Kerner 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 <
use-livecode@lists.runrev.com> 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
> use-livecode@lists.runrev.com
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-27 Thread Brian Milby 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-27 Thread Brian Milby 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 <
use-livecode@lists.runrev.com> 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:
>
>
> 
> 
> 
> name
> LiveCode Script Indentation
> scope
> source.livecode
> settings
> 
> 
> increaseIndentPattern
> 
> decreaseIndentPattern
> (?x)
> ^\s*
> (
> end\s+.
> | case\s+.
> | default\b
> | catch\b
> | finally\b
> )
> 
> unIndentedLinePattern
> 
> ^\s*(?:#|--|/\*)
> 
> 
> 
>
> On Thu, Jan 25, 2018 at 7:16 PM, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> 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 <
> > use-livecode@lists.runrev.com> 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 <
> > > use-livecode@lists.runrev.com> 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 <
> > > > use-livecode@lists.runrev.com> 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
> > > > use-livecode@lists.runrev.com
> > > > 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
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-25 Thread Mike Kerner 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:





name
LiveCode Script Indentation
scope
source.livecode
settings


increaseIndentPattern

decreaseIndentPattern
(?x)
^\s*
(
end\s+.
| case\s+.
| default\b
| catch\b
| finally\b
)

unIndentedLinePattern

^\s*(?:#|--|/\*)




On Thu, Jan 25, 2018 at 7:16 PM, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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 <
> > use-livecode@lists.runrev.com> 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 <
> > > use-livecode@lists.runrev.com> 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
> > > use-livecode@lists.runrev.com
> > > 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
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-25 Thread Brian Milby 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 <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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 <
> > use-livecode@lists.runrev.com> 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
> > use-livecode@lists.runrev.com
> > 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-25 Thread Mike Kerner 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 <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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
> use-livecode@lists.runrev.com
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-24 Thread Bob Sneidar 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 
>  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-24 Thread Mike Kerner 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 
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 <
> use-livecode@lists.runrev.com> 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 <
>> use-livecode@lists.runrev.com> 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 <
>> > use-livecode@lists.runrev.com> 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
>> > > use-livecode@lists.runrev.com
>> > > 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
>> > use-livecode@lists.runrev.com
>> > Please visit this url to subscribe, unsubscribe and manage your
>> > subscription preferences:
>> > http://lists.runrev.com/mailman/listinfo/use-livecode
>> >
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-24 Thread Mike Kerner 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 <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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 <
> > use-livecode@lists.runrev.com> 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
> > > use-livecode@lists.runrev.com
> > > 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
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-24 Thread Lagi Pittas 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 <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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
> > use-livecode@lists.runrev.com
> > 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-24 Thread Martin Koob 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-23 Thread Mike Kerner 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 <
use-livecode@lists.runrev.com> 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
> use-livecode@lists.runrev.com
> 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: regex deconstructor

2018-01-23 Thread Brian Milby 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 <
use-livecode@lists.runrev.com> 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode