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 want.
>
> It's interesting when we take a comment out of context and spin it in
> another direction by treating it as a different request or problem! :)
Not my intention to take it out of context, but to broaden the context.
My suggestion of considering a custom SE isn't reductio ad absurdum.
It's far worse: I'm actually serious.
Here's where I'm coming from:
Maybe it's just because I was one of the last MC users, but Dr. Raney's
DIY encouragement never left me: "Let a thousand flowers bloom" he would
say of anyone with time and interest to fork and replace IDE components.
I kept using the MC IDE about a decade after Revolution first premiered.
Eventually I got tired of making my own GUIs for the new engine
features, so I started using LC IDE - but the script editor was too slow.
So I forked MC's, added line numbers (years before the LC IDE had line
numbers - we were all such savages back then <g>), and made it into a
plugin. Ken Ray also helped with some of the fork, and we used it for
another five years or so even after we switched from MC to LC so we
could use the other tools.
After the big Waddingham SE Overhaul things got a lot better, and the
balance of features vs performance became more favorable for me, esp. in
light of the work required to properly maintain a fork. So now I use
LC's SE.
There's a couple points with this:
1. People can and do make their own script editors.
Why not? It's text in a field. If we can't make a good text editor in
LC why are we even here? But after delivering a good many custom work
processors I came to believe -- and still do -- that LC can make an
excellent text editor.
Basic features aren't hard. It's modestly rewarding, and you learn a
lot about making text editors.
What I found, though, was:
2. It ain't the field slowing us down.
As far as I can tell, the LC field object is pretty responsive to input.
And MC is faster than LC. Given the same engine, the difference is in
the scripts.
So the good news is that fixing serious slowdowns require the one skill
everyone on this list has: LiveCode scripting.
I've spent enough time going through the LC SE code to know that I don't
enjoy it. No offense to the team; it just has layers of legacy stuff
and over time it's accumulated a bit of cruft, made more complex by the
demands of the audience for new features. I understand how it got that
way, and I appreciate it's ambitions. I just don't enjoy working on it;
it's a beast.
So if anyone were relying on me to fix the SE performance issue (and
there are many reasons we're all glad no one is relying on me for that),
I'd be inclined to write a new one from scratch instead.
It may be possible to design and build something with all the current
engine strengths and weaknesses in mind that could become more
satisfying than continually patching a complex legacy stack.
However...
...there's a reason the team patches rather than replaces. Replacing is
expensive. Done well would take tremendous time. Sure, a field with a
"Save" button takes only an hour, and a slightly more usable feature set
takes a day; but a productive set takes weeks; greatness would take months.
And even then, ultimately we may find ourselves left with the question:
Is it possible to deliver the feature set current SE users demand
without adding a performance hit?
I'm one of the lucky ones, because once I turned off the SE features
that seemed likely to slow me down, I no longer have a slow SE.
Accordingly, I'm happily making stuff for clients, and am not very
motivated anymore to work on a script editor.
But if this were bothering me, I'd either dive into the existing SE and
fix it, or write my own.
Life's too short not to have what we want.
> The wiki sounds like a neat project. Simplicity helps, and whether to
> locate it in the SE is a consideration. Besides performance, another
> issue is that the original proposal here was adding user comments back
> to the Dictionary.
Personally, I prefer dedicated tools. The MC SE slowed down a lot when
it was combined with the debugger. When I forked it I returned to a
editor separate from a debugger, each purpose-built for the task they do
(extra bonus points that a sufficiently discrete debugger can also be
used in a standalone).
Combining lots of functionality into one window contributes to
complexity, which often finds expression in performance, and can slow
maintenance work while increasing cognitive load for user and developer
alike.
For that reason, I'd prefer a wiki be in a layout optimized for reading,
leaving the script editor optimized for writing.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
