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
he
> script editor - with wiki pages for projects, stacks, scripts and handlers.
> These project wiki's should be self-contained but link to the general
> Livecode Dictionary. Should you wish to personalise / write more extensive
> notes than available in the "Livecode Dictionary&q
personal
project wiki's for the software a developer is working on directly from the
script editor - with wiki pages for projects, stacks, scripts and handlers.
These project wiki's should be self-contained but link to the general
Livecode Dictionary. Should you wish to personalise / write more
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
g in life one
> has to rely on
> that involves other people; so worrying about Microsoft, if one spends too
> much time on
> it can become fairly unhealthy: and what about Apple, Canonical, and so on
> and so forth?
>
> -
>
> My objection to bunging user stuff for t
people; so worrying about Microsoft, if one spends
too much time on
it can become fairly unhealthy: and what about Apple, Canonical, and so
on and so forth?
-
My objection to bunging user stuff for the LiveCode dictionary on GitHub
has nothing to
do with Microsoft, but has a lot to do with acc
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
On Sun, Jan 20, 2019 at 12:07 PM Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> The permissions are over the top, but not intentional I am sure.
>
Agreed. I'm just waiting to see if:
1. My changes go in with the current state of affairs.
2. Someone from LC re-ups their
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 think the LC team set things up so that its convenient for them in their
workflow of growing & maintaining Livecode, ...its not so much our
convenience per se.
I think removing notes from the dictionary is a step backwards. This one
needs correction.
The permissions are over the top, but not
Rick Harrison wrote:
> Now that Microsoft owns GitHub perhaps LC should consider
> moving everything over to some other entity such as Bitbucket,
> or SourceForge.
>
> What do you think?
Personally, I think if it's good enough for the world's largest software
project, the open source Linux
On Sun, Jan 20, 2019 at 6:47 AM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
> LiveCode can’t use your contribution without the CLA. Someone from LC May
> need to clarify the details. Since they release code as GPL and
> Commercial, we need to assign copyright to them
On Sun, Jan 20, 2019 at 6:10 AM Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> The newsletter also lists documentation bugs which need fixing. Here is a
> link to the latest edition:
>
>
>
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
Now that Microsoft owns GitHub perhaps LC should consider
moving everything over to some other entity such as Bitbucket,
or SourceForge.
What do you think?
Rick
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to
LiveCode can’t use your contribution without the CLA. Someone from LC May need
to clarify the details. Since they release code as GPL and Commercial, we need
to assign copyright to them for any changes we make and also assert that we are
not introducing code where we are not able to assign
On Sat, Jan 19, 2019 at 9:00 PM Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:
> 1. Not everyone (very few people?) understand how git/GitHub works.
> 2. Even if you have a reasonable grasp of how to use git it's not obvious
> how to contribute to the dictionary using git.
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
On Sat, Jan 19, 2019 at 8:22 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
> I agree that the dictionary isn’t the easiest to update without a GutHib
> client, but dictionary updates can be done completely in a browser.
Yep, I figured that out after I spent several
On Sat, Jan 19, 2019 at 8:11 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Interesting. I just checked on GitHub and the oauth token for LiveCode
> was recently revoked automatically since it was not used. It’s been quite
> a while since I did it and I can’t recall
I agree that the dictionary isn’t the easiest to update without a GutHib
client, but dictionary updates can be done completely in a browser. The use of
the browser widget for the display of the dictionary data is quite independent
from the data itself. Maybe the community could put a complete
Interesting. I just checked on GitHub and the oauth token for LiveCode was
recently revoked automatically since it was not used. It’s been quite a while
since I did it and I can’t recall about having write access. There are several
apps that I still have linked (Hacktoberfest...).
Thanks,
So I have to sign an agreement -- I thought I had, but I have now.
And I have to link my LiveCode account and my GitHub account, meaning LC
can read and write all user data, including private email addresses,
private profile information, and followers. Is that really necessary?
gc
On Sat, Jan
1. Not everyone (very few people?) understand how git/GitHub works.
2. Even if you have a reasonable grasp of how to use git it's not obvious
how to contribute to the dictionary using git. I've maintained Navigator in
git/GitHub for about a year, and I'm sure I don't know the detailed steps
--
Use Bernd's TinyDictionary.
There everybody can add his own (private) notes.
Download from "Sample Stacks" or
http://livecodeshare.runrev.com/stack/825/TinyDictionary
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to
> On Jan 19, 2019, at 8:54 AM, Brian Milby via use-livecode
> wrote:
>
> We have an even better option now. Contributions to the actual dictionary
> can be submitted via GitHub.
If you have to post this here, it means it needs to be more obvious in the
Dictionary wrapper that we all use.
We have an even better option now. Contributions to the actual dictionary can
be submitted via GitHub.
Thanks,
Brian
On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode
, wrote:
> Some of those user entries were extremely useful.
>
> It would be good if user entries could be restored to
Some of those user entries were extremely useful.
It would be good if user entries could be restored to the dictionary
once again.
Richmond.
On 19.01.19 9:49, Simon Knight via use-livecode wrote:
Hi all,
I have just read about two “issues” and both would be resolved or at least
helped
Hi all,
I have just read about two “issues” and both would be resolved or at least
helped with a more detailed dictionary entry. Now in the dim distant past the
RunRev dictionary use to allow humble users to add comments and examples which
I for one found useful. Does anyone know why this
Stephen Goldberg wrote:
I've noticed that many dictionary words present in earlier versions
of LiveCode do not appear in the LC 7.0.4 dictionary. Can anyone
suggest why, or what I might be doing wrong? For example, try
searching for mouseUp in the LC 7.0.4 dictionary. Can you find it?
I've noticed that many dictionary words present in earlier versions of LiveCode
do not appear in the LC 7.0.4 dictionary. Can anyone suggest why, or what I
might be doing wrong? For example, try searching for mouseUp in the LC 7.0.4
dictionary. Can you find it? (I'm using Mac 10.9.5.)
Never mind. I immediately discovered why many words did not show up in the
dictionary. I should have set the left hand column of the dictionary to All,
and it had been stuck on Image.
Stephen Goldberg
stgoldb...@aol.com
___
use-livecode mailing list
On Tue, Apr 19, 2011 at 10:11 PM, tbodine lvhd...@gmail.com wrote:
Is there a way to increase the type size of the LiveCode Dictionary? The
details of the dictionary entries are usually where all the rich details
lurk, but that type is way too small for my middle-aged eyes. Suggestions?
While
Thanks David!
-- Tom Bodine
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Can-LiveCode-Dictionary-text-be-enlarged-tp3462035p3465031.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use
Is there a way to increase the type size of the LiveCode Dictionary? The
details of the dictionary entries are usually where all the rich details
lurk, but that type is way too small for my middle-aged eyes. Suggestions?
Thx,
Tom Bodine
--
View this message in context:
http://runtime
56 matches
Mail list logo