On Jul 4, 2010, at 6:46 PM, Laurent PETIT wrote:
>
> I guess I could make the Tab-as-indent-line behavior go back to the
> default mode, and introduce the
> Esc.-as-no-interpretation-by-the-editor-for-the-nex-keystroke . So
> people wanting to insert a real tab could do it by first hitting the
> Esc. key first.
>From where I currently sit that would be quite helpful.
> Maybe you're not "embracing" the source-code as data to its full
> extent ? I was not -and still am not- an emacs/paredit.el user, but
> now I can't go back to the default mode. I'm thinking about my code
> more and more in terms of forms, not in terms of a begin-to-end flow
> of characters. Just to give you a powerful example : [deleted]
I find this a little funny because my unshared reaction to the recent
discussion about "The Lisp Way" in the thread on "the joys of lisp" thread was
that for me the Lisp Way is mostly about source-code as data (aka
homoiconicity). From macros to genetic programming (one of my research areas)
homoiconicity is core to my view of Lisp and of the way that I wish all
programming languages work. So I embrace it!
I think what I don't embrace (yet -- maybe I'll come around) are the way that
the the current implementation interacts with typing, the way it prevents you
from sketching out code in a structurally invalid way (which is sometimes the
way my mind works), and the way that knowledge of how it's going to react to
typing is necessary to type anything correctly. You have to be thinking about
its rules as well as about the code. Of course once you internalize the rules
then I can see it would be great, but the interaction with ordinary typing and
the initial "opacity" of the system's rules aren't so great IMHO.
My favorite Lisp editing environment ever, although I probably misremember it
because I haven't seen it for something like 25 years, was the Interlisp-D
environment on Xerox Dandelion machines. I wish I could find some screen snaps
online, but I haven't yet. In any event, it was based around the concept of
structure editing but I don't recall it interfering with typing or that I had
to predict its behavior or move around things that it typed, etc. That really
might be flaws in my memory (anyone else here work with those)? In any event I
am SURE there were structure-oriented buttons that you could click to add
parentheses and do other handy structure editing things. As I recall it this
made it relatively easy to do the kinds of things that you illustrate with your
example, but no memorization of key stroke combinations was required and
ordinary meanings of common keys (like "(") weren't overridden.
At least that's how I recall it, although it may be a mangled memory. In any
event, maybe I can grow to love the CCW approach to this but FWIW my issue
isn't about "source code as data," it's about the mechanics of the user
interface.
One other cool thing that I remember about the Interlisp-D code editor, btw, is
that it maintained two selections -- the most recent one and the one from
before that, with the most recent underlined and the 2nd most recent underlined
with a dotted line -- and there were some button-based editing functions that
worked with this. For example, with one click you'd swap the two selected
expressions, and I think there were others.
>>> Oh, this for sure is a bug ! Lau Jensen opened an issue for it [etc]
>> Great!
>
> btw, now fixed in my local branch !
Wonderful!
>> There will be an interaction between this and the automatic insertion. If
>> you get rid of automatic insertion (which I would prefer) then if the I type
>> "(defn foo" and hit return then the parentheses will be unbalanced
>> (globally), so unless this issue is resolved the next line couldn't be
>> indented at all. That wouldn't be very helpful.
>
> Sincerely, I'll make everything in my power to get it back.
Wonderful!
> In fact - but maybe I'm saying that because "it's my baby and I'm used
> to his strengths and weaknesses" :-) -, when in Strict mode, I don't
> see the {, (, ", [ keys as characters anymore: they are commands for
> structurally editing the code: ( means create a new block, not add the
> ( character. ) means jump to the end of the ancestor ) (not
> necessarily the parent form). Maybe "switching" perspective to this
> angle may help. But I can understand that it may resemble "dark
> magic", so maybe explaining it a little bit more may help.
That makes sense, and that may be the best way to explain it. (For example "In
the Strict mode several keys that would ordinarily produce characters are
instead treated as commands for structurally editing the code...").
Thanks so much,
-Lee
--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspec...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438
Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
