2010/7/5 Lee Spector <lspec...@hampshire.edu>:
>
> 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.
>
Sorry if I offensed you by suggesting you didn't "get" the virtues of
homoïconicity ! I would love to hear details on what a good structure
editor (not just a semi-editor like paredit) looks like !
>>>> 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...").
>
BTW, if you feel like you could help improve the documentation of some
parts of ccw on the wiki or the Eclipse online help, you're very
welcome :-)
--
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
