OK.
Concerning the specific "indent line" issue, I guess I'll finally do
the following :
* align the default way of re-indenting a line with the Eclipse
standard, e.g. Ctrl+I on Windows/Linux (what is it for Mac ?)
* this way this can be overriden by the user via the Window >
Preferences > General > Keys menu
* but (there's a but), it's not possible in Eclipse to redefine
the behaviour of the Tab key from the above mentioned menu, so:
* create a configuration flag for the behaviour of the Tab key.
* Make this behaviour orthogonal to the currently enabled
structural editing mode (Default or Strict)
* Make the default behaviour be the reindentation of the current line
* The flag will be accessible as usual from Window > Preferences >
Clojure > Editor menu
2010/7/5 Laurent PETIT <laurent.pe...@gmail.com>:
> 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
