I'm pleased to announce the availability of SchemeScript 1.0.0, a
full-featured Scheme/Lisp editor for the Eclipse environment.
http://schemeway.sourceforge.net
Although it has many features that are Kawa-specific, it can be used
to interact with any Scheme interpreter. It is especially targetted at
Scheme developers who also have to work in Java in the Eclipse
environment and don't want to switch between Eclipse and [X]Emacs.
SchemeScript provides the following features:
* customizable syntax coloring;
* correct, customizable, automatic indentation;
* S-expressions-based editing � la Emacs;
* parentheses matching and highlighting (with support for square
brackets);
* mouse-copy;
* content assist (code completion, text hovers, context
information);
* Find Definition (pressing F12 on a symbol will jump to the
symbol's definition, if it is defined globally);
* header/chapter/section style comment insertion, with the outline
view showing the document structure; and
* generic integration with any Scheme interpreter
* a Kawa scratchpad view for testing graphical components
interactively (see the documentation for more details and the
examples subdirectory)
* access to the Kawa interpreter embedded in Eclipse (can be
used to interact with the Eclipse infrastructure)
* and lots more...
SchemeScript is used by many professional developers and at a
a number of universities for introductory courses using Scheme.
Dominique Boucher
The SchemeWay Project
Dominique Boucher <·········@sympatico.ca> writes:
> SchemeScript is used by many professional developers and at a
> a number of universities for introductory courses using Scheme.
If it shows a progress bar to create a new Scheme source file, this
plugin has just lost in my eyes...
Regards,
--
Julian Stecklina
(Of course SML does have its weaknesses, but by comparison, a
discussion of C++'s strengths and flaws always sounds like an
argument about whether one should face north or east when one
is sacrificing one's goat to the rain god.) -- Thant Tessman
Julian Stecklina <··········@web.de> writes:
> Dominique Boucher <·········@sympatico.ca> writes:
>
> > SchemeScript is used by many professional developers and at a
> > a number of universities for introductory courses using Scheme.
>
> If it shows a progress bar to create a new Scheme source file, this
> plugin has just lost in my eyes...
Well, even in XEmacs (with font-lock enabled), I see a progress bar
when creating a new Scheme source file... So what's the point?
Dominique
Dominique Boucher <·········@sympatico.ca> writes:
> Julian Stecklina <··········@web.de> writes:
>
>> Dominique Boucher <·········@sympatico.ca> writes:
>>
>> > SchemeScript is used by many professional developers and at a
>> > a number of universities for introductory courses using Scheme.
>>
>> If it shows a progress bar to create a new Scheme source file, this
>> plugin has just lost in my eyes...
>
> Well, even in XEmacs (with font-lock enabled), I see a progress bar
> when creating a new Scheme source file... So what's the point?
Maybe if you open a large Scheme file. But I guess you have not used
Eclipse.
Regards,
--
Julian Stecklina
When someone says "I want a programming language in which I
need only say what I wish done," give him a lollipop. - Alan Perlis
Julian,
> > Well, even in XEmacs (with font-lock enabled), I see a progress bar
> > when creating a new Scheme source file... So what's the point?
>
> Maybe if you open a large Scheme file. But I guess you have not used
> Eclipse.
Read carefully: I see a progress bar when CREATING a new Scheme
file... (on a Celeron 2.4GHz).
And I do use Eclipse on a daily basis. I have developed many plugins
for it (SchemeScript is the only open-source one, though). I have even
switched completely to Eclipse for my Scheme programming.
That being said, Eclipse is much more a pain to develop for than
Emacs. But being able to display graphical components inside the
development environment is a win, IMHO. Give me graphical components
inside Emacs and I'll switch back to it.
Cheers,
Dominique
Dominique Boucher <·········@sympatico.ca> writes:
> Julian,
>
>> > Well, even in XEmacs (with font-lock enabled), I see a progress bar
>> > when creating a new Scheme source file... So what's the point?
>>
>> Maybe if you open a large Scheme file. But I guess you have not used
>> Eclipse.
>
> Read carefully: I see a progress bar when CREATING a new Scheme
> file... (on a Celeron 2.4GHz).
If I do C-x C-f foo.scm, it just opens an empty buffer without any
delay (on 1.4 GHz Pentium-M). If I create a new class in Eclipse, it
takes about two seconds and the only thing it does is filling the
empty file with a template... Eclipse generally feels _very_ sluggish
for most tasks (at least for me).
> And I do use Eclipse on a daily basis. I have developed many plugins
> for it (SchemeScript is the only open-source one, though). I have even
> switched completely to Eclipse for my Scheme programming.
Yes, (X)Emacs lacks a good environment for Scheme, but with a little
luck SLIME will fill that need quite nicely.
> That being said, Eclipse is much more a pain to develop for than
> Emacs. But being able to display graphical components inside the
> development environment is a win, IMHO. Give me graphical components
> inside Emacs and I'll switch back to it.
Climacs? ;) Seriously, I think that Emacs could benefit from
displaying graphics buffers. But on the other hand Eclipse could
benefit from a real editor... The Emacs keybindings for it are a (bad)
joke. So there is a tradeoff involved: Either you want to be efficient
at editing or you like the "klickibunti" (can someone translate this?
I cannot think of another word right now...) stuff.
Regards,
--
Julian Stecklina
When someone says "I want a programming language in which I
need only say what I wish done," give him a lollipop. - Alan Perlis
From: Christopher C. Stacy
Subject: Re: [Ann] SchemeScript 1.0.0 released!
Date:
Message-ID: <uk6hhn3ki.fsf@news.dtpq.com>
Julian Stecklina <··········@web.de> writes:
> Either you want to be efficient at editing or you
> like the "klickibunti" (can someone translate this?
> I cannot think of > another word right now...) stuff.
Yes, someone please translate this!
I am almost certain that I can't wait to start using this word!
Christopher C. Stacy wrote:
> Julian Stecklina <··········@web.de> writes:
> > Either you want to be efficient at editing or you
> > like the "klickibunti" (can someone translate this?
> > I cannot think of > another word right now...) stuff.
>
> Yes, someone please translate this!
> I am almost certain that I can't wait to start using this word!
I'm not aware of an existing English translation or equivalent. The
closest translation could probably be clicky-shiny (although 'bunt'
primarily means multi-hued/colored, in this case it also has
connotations of "ooh, shiny"; and it sounds better). In my experience
this is a very pejorative term for user interfaces (and the behaviors
users of said interfaces tend to exhibit) where number of colors and
icons used divert attention from the often inadequate functionality of
the interface for the task it's been designed (or often cobbled
together) for, but which nonetheless quite often sells a product.
--
Christopher
On Fri, 16 Sep 2005 08:12:45 -0700, Christopher Koppler wrote:
> Christopher C. Stacy wrote:
>> Julian Stecklina <··········@web.de> writes:
>> > Either you want to be efficient at editing or you
>> > like the "klickibunti" (can someone translate this?
>> > I cannot think of > another word right now...) stuff.
>>
>> Yes, someone please translate this!
>> I am almost certain that I can't wait to start using this word!
>
> I'm not aware of an existing English translation or equivalent. The
> closest translation could probably be clicky-shiny (although 'bunt'
> primarily means multi-hued/colored, in this case it also has
> connotations of "ooh, shiny"; and it sounds better). In my experience
> this is a very pejorative term for user interfaces (and the behaviors
> users of said interfaces tend to exhibit) where number of colors and
> icons used divert attention from the often inadequate functionality of
> the interface for the task it's been designed (or often cobbled
> together) for, but which nonetheless quite often sells a product.
I lurk quite a bit here, and this is the first thing I've been able to use
at work :) Nice phrase. I can't think of a single English word that has
*quite* the same connotations of pointless and distracting graphical
frippery.
At work, I'm frequently obliged to use VS.NET and I find myself
using the phrases "unnecessary cruft" and "all this space-wasting shite"
quite a bit in reference to the UI (excuse my language). This usually
happens when helping one of my team solve a problem and I'm peering at a
postage-stamp window of source code, drowning in toolboxes and palettes,
and just prior to demanding a larger and/or additional TFT for them.
In terms of delivery to customers, we often opine that they won't grok new
functionality unless its larded with "windows and sex".
None of these terms are meant to be complimentary :)
Christopher Koppler wrote:
> Christopher C. Stacy wrote:
>
>>Julian Stecklina <··········@web.de> writes:
>>
>>>Either you want to be efficient at editing or you
>>>like the "klickibunti" (can someone translate this?
>>>I cannot think of > another word right now...) stuff.
>>
>>Yes, someone please translate this!
>>I am almost certain that I can't wait to start using this word!
>
>
> I'm not aware of an existing English translation or equivalent. The
> closest translation could probably be clicky-shiny (although 'bunt'
> primarily means multi-hued/colored, in this case it also has
> connotations of "ooh, shiny"; and it sounds better). In my experience
> this is a very pejorative term for user interfaces (and the behaviors
> users of said interfaces tend to exhibit) where number of colors and
> icons used divert attention from the often inadequate functionality of
> the interface for the task it's been designed (or often cobbled
> together) for, but which nonetheless quite often sells a product.
>
Ah. We say "chrome." As in "there's no fundamentally new
functionality but they changed the chrome around," or "This
IDE doesn't do as much as Emacs, but it sure has a lot of
shiny chrome."
Bear
On Tue, 20 Sep 2005 22:38:36 GMT, Ray Dillinger <····@sonic.net> wrote:
> Ah. We say "chrome." As in "there's no fundamentally new
> functionality but they changed the chrome around," or "This IDE
> doesn't do as much as Emacs, but it sure has a lot of shiny chrome."
Yeah, that's similar but not really the same. "Klickibunti" has
"click" in it and is therefore often used to specifically distinguish
keyboard-based user interfaces from those where you /have/ to use the
mouse. Also, both "klicki" and "bunti" are fake diminutives which
makes the whole word sound like child stuff to German ears.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz writes:
> On Tue, 20 Sep 2005 22:38:36 GMT, Ray Dillinger <····@sonic.net> wrote:
>> Ah. We say "chrome." As in "there's no fundamentally new
>> functionality but they changed the chrome around," or "This IDE
>> doesn't do as much as Emacs, but it sure has a lot of shiny
>> chrome."
> Yeah, that's similar but not really the same. "Klickibunti" has
> "click" in it and is therefore often used to specifically
> distinguish keyboard-based user interfaces from those where you
> /have/ to use the mouse. Also, both "klicki" and "bunti" are fake
> diminutives which makes the whole word sound like child stuff to
> German ears.
At work (Munich, Germany) we also ironically ask "what's the color of
the button I have to click on in order to...". One can recognize the
same components of "Klickibunti" there.
--
"If you're stuck at the level of wanting to point at a picture and
click, you've got to understand that you're basically at the same
level as a preverbal child." <······················@sonic.net>
Christopher C. Stacy wrote:
> Julian Stecklina <··········@web.de> writes:
> > Either you want to be efficient at editing or you
> > like the "klickibunti" (can someone translate this?
> > I cannot think of > another word right now...) stuff.
>
> Yes, someone please translate this!
> I am almost certain that I can't wait to start using this word!
I found this discussion item in the English-German online dictionary I
sometimes use.
http://dict.leo.org/cgi-bin/dict/urlexp/20020509211445
The proposed translation for "Windows ist doch nur Klickibunti.'' is
"Windows is just a toy OS"
The key phrase for me (with my very limited German) in the discussion
is "sehr bunt und alles zum Anklicken." Approximately, "very colorful,
and all for clicking on."
Also interesting is www.klickibunti.org, particularly the
"Schocktherapie" link.
Julian,
> If I do C-x C-f foo.scm, it just opens an empty buffer without any
> delay (on 1.4 GHz Pentium-M). If I create a new class in Eclipse, it
> takes about two seconds and the only thing it does is filling the
> empty file with a template... Eclipse generally feels _very_ sluggish
> for most tasks (at least for me).
I won't dispute that Eclipse is slow and bloated. But it's not only a
text editor. Creating a new class does not only involve creating a new
text file. Eclipse must update its internal data structures (the
JDT). It's quite involving. (And it's written in Java ;-) We compare
apples and oranges, here.
> > And I do use Eclipse on a daily basis. I have developed many plugins
> > for it (SchemeScript is the only open-source one, though). I have even
> > switched completely to Eclipse for my Scheme programming.
>
> Yes, (X)Emacs lacks a good environment for Scheme, but with a little
> luck SLIME will fill that need quite nicely.
My plugin is not meant to replace XEmacs/Slime for Scheme
programming. It's goal is to provide a good Scheme editor for those
who have to work in Eclipse and don't want to switch between Eclipse
and XEmacs. I.e. people like me. I do not work in isolation. I work on
projects involving other Java (-only) programmers and we all
standardized on Eclipse (for good or for bad).
> > That being said, Eclipse is much more a pain to develop for than
> > Emacs. But being able to display graphical components inside the
> > development environment is a win, IMHO. Give me graphical components
> > inside Emacs and I'll switch back to it.
>
> Climacs? ;)
I haven't tried it yet. But I will do some day.
> Seriously, I think that Emacs could benefit from
> displaying graphics buffers. But on the other hand Eclipse could
> benefit from a real editor...
How do you define "a real editor"?
Dominique
········@nuecho.com writes:
> I won't dispute that Eclipse is slow and bloated. But it's not only a
> text editor. Creating a new class does not only involve creating a new
> text file. Eclipse must update its internal data structures (the
> JDT). It's quite involving. (And it's written in Java ;-) We compare
> apples and oranges, here.
Yes, you certainly have a point. And the fun thing is that people had
quite similar arguments (slow, bloated) against Emacs years ago (and
probably today). ;-) But see the next paragraph.
>> Seriously, I think that Emacs could benefit from
>> displaying graphics buffers. But on the other hand Eclipse could
>> benefit from a real editor...
>
> How do you define "a real editor"?
Defining arbitrarily complex text editing functions and binding them
to a key is a large part of what a "real editor" should provide
for. In Emacs this is quite easy, because the editor is in itself
something you can develop.
The Eclipse philosophy of different "views" is IMHO very distracting
itself. Emacs feels more integrated. CVS in Emacs and Eclipse is an
example for that. But again, YMMV.
Regards,
--
Julian Stecklina
When someone says "I want a programming language in which I
need only say what I wish done," give him a lollipop. - Alan Perlis
Julian Stecklina <··········@web.de> writes:
> Yes, you certainly have a point. And the fun thing is that people had
> quite similar arguments (slow, bloated) against Emacs years ago (and
> probably today). ;-) But see the next paragraph.
And maybe Eclipse will be fast and slim compared to the next
generation of IDEs ;-)
> > How do you define "a real editor"?
>
> Defining arbitrarily complex text editing functions and binding them
> to a key is a large part of what a "real editor" should provide
> for. In Emacs this is quite easy, because the editor is in itself
> something you can develop.
SchemeScript allows me to do that, to a certain extent. Many of the
new Kawa-related functionalities (like expand-namespace, etc.) have
been implemented this way (defining and testing text editing functions
interactively). Here is an example of code using an Emacs-like API
provided by SchemeScript:
(define (make-symbol-expander expander)
(lambda ()
(let-values (((start end) (backward-sexp)))
(when (and start end (eq? (sexp-type start) symbol:))
(with-buffer-text
start end
(lambda (text)
(let ((clause (expander text)))
(when clause
(set-point start)
(run-compound-change
(lambda ()
(delete-text (- end start))
(insert-text clause)))))))))))
The only missing part is the ability to bind such code to a key
sequence. But there are 10 'fast keys' (Alt-k 0, ... Alt-k 9) that can
be configured to run a small Scheme script.
What I miss most are keybord macros.
> The Eclipse philosophy of different "views" is IMHO very distracting
> itself. Emacs feels more integrated. CVS in Emacs and Eclipse is an
> example for that. But again, YMMV.
My mileage does vary.
Cheers,
Dominique