Script Editor future (was Open Source Kickstarter Report Card)
Kay C Lan
lan.kc.macmail at gmail.com
Sun Aug 23 02:51:35 EDT 2015
Mike Kerner said:
> effort should instead be spent on a
> BBEdit/TextWrangler plugin or some
> method for leveraging someone else's
> text editor.
Malte Brill said:
> +1, just eclipse… ;-).
The Dr. said:
>vi, of course . . .
>If you want to use that heretical emacs contraption, you'll get performance
>almost as bad as the current IDE.
>the problem with this approach is that you need to find a single editor
>runs on Linux, OS X Windows. Without using a single editor/IDE on all
>the developer experience and ease of use will rapidly diminish.
I don't agree, I think you've got that wrong way around. I think a lot of
the recent discussion has been about 1st impressions. If an investigating
developer turns up who spends most of his time in BBEdit/Emacs/vi/Eclipse
discovers he can use the same tool for LC, that has to be a good thing.
Surely it would be advantageous for a developer to turn up with any tool of
his choice and be able to use it so as to keep his comfort zone as large as
possible and his learning curve as small as possible. All his favourite
keyboard shortcuts would work, his screen layout would be similar, his
syntax hilighting colour preferences unchanged. He can then focus on the
idiosyncrasies of LC.
I don't care if the LC Script Editor in Linux is exactly the same as the SE
experience on OS X. Why should it matter? The SE experience in Linux should
be a Linux experience, in Win it should be a Win experience, in OS X an OS
>I have no idea how difficult that would be, but it sounds like the
>cracking the walnut.
But isn't that the point. The feeling I get from comments is that people
think the current Script Editor is a tack hammer and they are wanting
something a bit more meaty. The nice thing about some of the tools
mentioned is they can be used as a tack or ball pien when light and agile
is needed, or they can be a mallet or sledge when really heavy work is
required - they are specifically built for text manipulation tasks and they
have gained their reputation because they are extremely good at it.
Scott also said:
>I would be surprised if the amount of work making a plugin for another
>would be less than just fixing what currently exists.
><g> from the work I've done on glx2 I'd second that. The IDE has way too
many hooks that need to be trapped
And Mark would know, but again is this because the problem is being viewed
wrong way around, is this the horse driving the kart? I wonder if someone
from the mothership sat down and said "right, we are going to make our
Script Editor compatible with the top 3 text editors on each platform, how
do we make that happen." if a lot of those hooks could be simplified and
the process more 3rd party friendly?
I recently posted about this Document viewer:
150+ documents sets, integrating with 25+ Apps including TextWrangler,
BBEdit, Eclipse and Emacs. What it doesn't tell you is that it recognises
80+ languages including Xojo, GEDCOM (family history), Lilypond (Music
notation), the extremely cool sounding SuperCollider (audio) and Metaslang;
which is so rare that even Google can't find it. Apparently all maintained
by a single person.
I admit I have no clue, but I imagine what we are talking about is passing
a chunk of text from LC to another program. If one guy can figure out how
to grab the text from 150+ doc sets, and then feed that into 25+ apps, and
then syntax colour the text, I figure it shouldn't be too hard for a single
person from the mothership to figure out how to ease the process of passing
an LC script to a dozen different text editors and ensure those text
editors are kept up to date with the LC syntax definitions.
At the end of the day the LC Script Editor should be a glowing example of
what LC can do.
But by the same token, Xcode,along with all the other text centric programs
that I use, allow me to choose a different text editor. The wheel was
invented a long time ago. There are developers who's living is made from
perfecting the wheel. There must be a reason why so many 'others' allow you
to choose a different Text Editor in their application rather than being
forced to use the built in one.
More information about the Use-livecode