If using a binary stack, ScriptTracker makes it easy to edit scripts in an
external editor.
Levure includes a server process that allows Sublime Text tell LC to reload a
script only stack when saved from there (I don’t think it depends on the app
itself being managed with Levure). I use Atom
On Thu, Jan 24, 2019 at 12:36 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> When I forked it I returned to a
> editor separate from a debugger, each purpose-built for the task they do
>
YES. If I had a nickel for every time I expand the variable list while in
the
GLX2 was great at one time, but certain features added later, like code saving
caused problems. I'd like to see GLX2 gone through and made stable again, and
although Mark Weider has been very diligent to correct any issues that have
sprung up in the past, no can expect him to continue brooding
Richard:
> 2. It ain't the field slowing us down.
> As far as I can tell, the LC field object is pretty
> responsive to input.
Agreed, vast majority of SE problems are not field problems. I spend a
lot of my time in fields and it's pleasant. Responsive in most cases.
> I'm one of the lucky
Hi Curry - you wrote:
A project wiki would fit in the SE better than it would the Dictionary,
> of course, it would have more features and I could see that being a tab.
> But then again user keyword comments would fit the Dictionary very well,
> they could simply be added there. Having a separate
Curry Kenworthy wrote:
> Richard:
> > Curry Kenworthy wrote:
> >> What people need most in the Script Editor is to view and edit the
> >> code itself smoothly, without jitters or delays
>
> > Not hard to make one. A frontScript trapping the editScript
> > message lets you do whatever you
Richard:
> Curry Kenworthy wrote:
>> What people need most in the Script Editor is to view and edit the
>> code itself smoothly, without jitters or delays
> Not hard to make one. A frontScript trapping the editScript message
> lets you do whatever you want.
It's interesting when we take a
+1 for Sublime. I do not code in it much, but there are plugins like for
comparing two scripts to see differences. If I ever get around to converting my
main app to Levure, I would probably use it more.
Bob S
> On Jan 23, 2019, at 10:52 , Trevor DeVore via use-livecode
> wrote:
>
> On
Trevor DeVore wrote:
> On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin wrote:
>>
>> And then there are the countless third-party text editors, some of
>> which have LC-specific add-ons crafted by our community for them,
>> like Trevor's plugin for Atom. I've been using Atom enough in web
>>
On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> And then there are the countless third-party text editors, some of which
> have LC-specific add-ons crafted by our community for them, like
> Trevor's plugin for Atom. I've been using
Curry Kenworthy wrote:
> What people need most in the Script Editor is to view and edit the
> code itself smoothly, without jitters or delays
Not hard to make one. A frontScript trapping the editScript message
lets you do whatever you want.
You can make a stack with a field and a Save
Oh, let's get campy.
In a perfect world there should not really be a need for "us" and "them"
camps with LiveCode,
it should cater to all people along a continuum stretching from "us" to
"them".
While LiveCode may be tending to introduce more "them" features
(arguably because all
"us"
Well, Curry, at the risk of causing you terminal disappointment, I can
do nothing but support
your request for the thing to be a simple as possible.
"my budget hardware"
my "budgetist" hard ware is a Pentium 4 I picked up 12 years ago, second
had, for $12 . . .
It has "2000" written on the
Hi Richard - yes indeed Github and GIST integration is part of the mix. I
have libraries for those and have been publishing directly from Livecode
for a few years now so it works well. My thinking on it is to use Github as
an option for offloading (large) data, and keeping the json as metadata -
I've posted the Documentation Editor code to GitHub. I'll try to add some
screen shots eventually.
https://github.com/bwmilby/DocEditorPlus
https://github.com/bwmilby/DocEditorPlus/raw/master/DocEditorPlus.livecode
Script index:
Graham Samuel wrote:
> It’s OK, I think, to provide more facilities for the ‘big picture’
> professionals, such as making it easier to use version control and
> to work in teams, and to have an ever-expanding set of functions
> and even platforms; but it’s not OK if this is at the expense of
>
David:
> I'm working on a solution for this
> collaborative with the minimal possible barrier to entry
> integrated into developer workflow - that means the script editor
> personal project wiki's for the software a developer is working
> on directly from the script editor
> Thoughts?
Thanks Brian - if you have the tie to dig out that stack it would be great.
I have come across the handlers / libs a few times - but as its not
documented it takes a while to track down :)
It would be great to figure out how to get proper flow back to the main
project - so any thoughts on that
GFM syntax is used, but it does go through additional processing before being
turned into what we see in the IDE. All of that code resides in the IDE so it
can be leveraged to process the updates. I actually modified a stack that can
allow the editing of a doc and then preview it in a
On Tue, 22 Jan 2019 at 14:40, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> That license will not allow inclusion into the LiceCode dictionary as it
> requires any derivative works to carry the same license. For integration
> into the LiveCode project a CLA will need
It sounds very ambitious. My main suggestion was for a shareable user additions
part of the dictionary that could be incorporated into the main dictionary at
some later date, if useful. It is so common to see user comments on web
content, that I don’t see how there could be a problem with
Just to clarify, I didn’t really mean to suggest that there was a plan - it’s
just that a lot of the creative energy around LC and its development seems to
be going away from this as if it were bad, basically because it’s hard to do
version control on binary stacks, as far as I can see. I do
Two comments initially:
That license will not allow inclusion into the LiceCode dictionary as it
requires any derivative works to carry the same license. For integration into
the LiveCode project a CLA will need to be signed by each author and their
contributions also submitted with copyright
I'm working on a solution for this - it's kind of ambitious and won't be
ready to share publicly for about 3 months at a guess - but I'm happy to
share it with anyone who want to use GitHub and get deep into the issue.
*Quick outline of dictionary strategy*
1. It should be collaborative with
Graham:
> a conflict between the “everyone can code” philosophy [...]
> and the perceived need to be more professional and serious as a
> player in the whole software development arena.
Well-said!
Nor should it be assumed that pros and trend-chasers are always
serious/correct and others are
I agree with Richmond. There are many great suggestions for coding tricks, and
workarounds that occur on this list. That wisdom remains in the archives, but
is not necessarily obviously accessible to those of us who may be exploring an
unfamiliar or poorly documented technique. The dictionary
Oh, fruit-flavoured socks . . .
If many developers do not trust Microsoft, who can change their term
anytime, and
no one knows what they will do . . .
One could wonder about the same sort of thing about other software
manufacturers;
even those who keep changing their commercial licensing
Many developers do not trust Microsoft, and neither do I.
Things may be fine right now, but it is the future that
concerns me more. They can change their terms at
anytime, and no one knows what they will do.
Just a word of caution.
Cheers,
Rick
> On Jan 20, 2019, at 2:50 PM, Richard Gaskin
Rick Harrison wrote:
> I do not believe most of LC’s users are interested in signing up
> for GitHub and having to sign an agreement with new owner Microsoft
> too.
In what way has Girhub's TOS been changed after Microsoft's acquisition
which would be a concern to LiveCode developers?
--
I agree that LC should be as simple as possible to use
and to contribute to for most users. I do not believe most
of LC’s users are interested in signing up for GitHub and
having to sign an agreement with new owner Microsoft too.
User’s want a simple interface that is easy to use. Scattering
LC
Just covering this one point of Geoff’s in the Dictionary discussion. I agree
with his comment, and I think it’s symptomatic of a problem with the
development of LC in the last few years: there is IMHO a conflict between the
“everyone can code” philosophy that LC inherited (and greatly
31 matches
Mail list logo
