At 1:38 AM +0900 2/27/01, [EMAIL PROTECTED] wrote:
>?
>Jim Correia <[EMAIL PROTECTED]>wrote:
>>BBEdit knows where MacPerl is, and launches it for you.
>Umm I metioned before that I didn't want to get involved with an editor
>war, and I think this is wandering OT a bit. Sufice to say I tried BBedit
First, my appreciation to Alan Fry and others who've raised this
topic and, I gather, offered to do some work to implement what
emerges.
I think we really have two threads to this: one has to do with
MacPerl's built-in editor, and the other with external editors. Let's
keep it straight.
Of course they're related; if MacPerl's built-in happened to have a
richer set of features, perhaps many of us would use it more rather
than using other editors, depending on what other tasks we do with
our other editors.
But here we are today with what we have, and the upgrade of MacPerl
offers an opportunity to improve *something* involving the editor. In
this context, the situation will continue to evolve with both aspects
(built-in and external), probably even if someone installed a
full-featured editor right into MacPerl.
So let's explicitly bifurcate the discussion: there are things that
could be improved in MacPerl's built-in editor, and some of us would
benefit; the way Macperl works with external editors could also be
improved, and some would benefit from that, too. These aren't
conflicting goals.
I think it's great that Jim Correia, programmer of BBEdit,
participates in this discussion. Several times in this thread, Jim
has seemed to be in the position of explaining/defending BBEdit's
capabilities WRT MacPerl. Couldn't this be more productive if
slightly re-cast? One of us asks, petulantly or not, "Why can't we
have XYZ?!!", and then Jim says "Well, actually you can do some of
that with BBE, here's how, but if you want way max XYZ, we can't
provide it because MacPerl doesn't have ABC." What's the point of
this interchange? Especially given Robin's wise caution against
editor wars, the only useful bit for this discussion was that
something was identified that could be improved in MacPerl's editor
situation, namely ABC.
So regarding MacPerl vis a vis external editors, I suggest that the
goal of any discussion be to smoke out the limiting factors of
MacPerl. Not to add more to Alan et al's assignment, but if such a
list were on hand when they delve into MacPerl's internal editor,
maybe opportunities related to external editors could be seized.
Now regarding the internal editor. I'm so used to working with an
external editor that I doubt a few improvements to MacPerl's editor
qua editor would attract me back. Much more interesting to me would
be to strengthen those aspects of the internal editor that make it an
interface to MacPerl execution. Others have suggested, or we already
have, command line, <STDIN>, <STDOUT>, <STDERR>, ways to use the
power of Perl in the editor with installed scripts, simulated
execution (syntax check), access to the symbol table, etc.
I'm not even sure what could be added to this list, but in the
abstract I'd say I want MacPerl's editor to be as programmable as
possible. I want instant ability to test in various ways. I want to
blurt input and see output. How about the editor window having a
console pane in which I can type a quick command that would be
executed on what I have in the text pane?
Alan, is this heading away from what you were considering? For my
wishes, the internal editor would certainly need to overcome the 32k
limit. Beyond that, is there a simple catalytic mechanism that
enables lots of programmability, like the capacity to install scripts
that operate as commands within the editor? This is beyond my
knowledge, and I'm grateful for whatever can be developed.
1;
--
- Bruce
__bruce_van_allen__santa_cruz_ca__
