Hey,
2010/7/5 Lee Spector <lspec...@hampshire.edu>:
>
> On Jul 4, 2010, at 4:10 PM, Laurent PETIT wrote:
>> So there are 2 possibilities:
>> a. I create an additional "configuration parameter" so that anybody
>> can choose if he wants the Tab key to behave "normally" or to be bound
>> to the "reindent line" feature. And I make this "structural editing
>> mode-independent". The next question is: which default state for this
>> configuration parameter ?
>> b. I move the feature back to "default mode". No additional
>> configuration parameter.
>>
>> My preference would go for b. [etc.]
>
> I would be happy with either, although my preference would also be b. I have
> no use for tab aside for indentation in Clojure code, so it's okay with me if
> it always means "re-indent this line." BTW if it's possible to make it
> "re-indent this line or, if there's a selection, all of the lines in the
> selection" then that would be even better.
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.
>> Currently I can say that the strict mode is not totally feature
>> complete. I intend to provide some "escape" key, which would allow
>> "escaping the next typed character from the strict mode evaluation".
>> This escape key may well end up being the Esc. key. If you were
>> provided with this way to, some times, really add, insert or delete
>> this damn ")", would you reexamine adopting the strict mode ?
>
> I guess I'd give it a whirl, but really the issue here is that I'd like to
> think just about the code when I'm typing it, and not some combination of the
> code and "what the editor is going to think of it or going to type for me so
> I have to remember not to type it, and instead to move around what it types,
> etc." In other words, I would prefer it if the only characters that show up
> in the buffer are the ones that I type. I love feedback, which I get through
> auto-indentation and auto-coloring, but I personally don't like it when an
> editor messes with the actual characters that I type. I guess it would be
> better if there was a way to disable this "helpfulness" on a per-use basis,
> but I'd rather if it just wasn't there or if I could turn it off completely.
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 :
I have this code:
(if true
(foo bar)
(baz))
Now I have a spy function I want to apply to foo. This function will
print the value of foo, and then return the value of foo. With
structural editing, I do the following sequence: select via structural
selection "(foo bar)", hit the "(" key to wrap "(foo bar)" with
balanced parens, type "spy " and voilà : (consider pipe is the cursor,
double pipe is a selection)
" |(foo bar)" -> hit Shift+Alt+Right -> "|(foo bar)|" -> hit "(" ->
"(|(foo bar))" -> type "spy " -> "(spy (foo bar))"
Now you have debugged and I want to get rid of the spy call. What I
want to do is make the (foo...) call replace (raise over) its parent
form. Easy with the "raise over" structural edition command. I must
just go in front of the (foo..) call, and call the function:
"(spy |(foo bar))" -> hit Alt+R (R as in Raise over) -> "|(foo bar)" ! !
And of course this works even if the (foo ...) form is very long,
dispatched on several lines, etc. :-)
>> Oh, this for sure is a bug ! Lau Jensen opened an issue for it (
>> http://code.google.com/p/counterclockwise/issues/detail?id=114 ),
>> which I was not able to reproduce on my side. With the help of this
>> new input, I'll try to reproduce -and then eradicate- it!
>
> Great!
btw, now fixed in my local branch !
>>> In both modes auto-indentation seems to be oddly global, with a mismatched
>>> bracket anywhere in the buffer turning off all auto-indentation everywhere.
>>> In other lispy editors that I've used I think that the indentation has
>>> always been determined only from the code *before* the cursor and only back
>>> to the beginning of the current definition.
>>
>> That's, unfortunately, a current limitation of the implementation.
>> We'll try to work on this, but give no promise for the short term.
>
> 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.
>> The default "reindent line" keyboard shortcut in Eclipse is Ctrl+I.
>> Would this be acceptable to you ? I chose Tab because emacs did this,
>> and I found this easier to type than Ctrl+I, given that we may type
>> this quite a lot ?
>
> Agreed. I'd say stick with tab unless there's a reason not to. Especially if
> you have to do it once per line it would be a bit cumbersome to have to do a
> two key combo on each line in order to re-indent a whole definition.
>
>>
>>> working to re-indent the current line and with the indentation determined
>>> only from the text before the insertion point, back to the beginning of the
>>> current definition (as in emacs, etc.). I would also personally prefer to
>>> be able to turn off automatic pair insertion entirely -- maybe I'll get
>>> used to it, but I'm not at all sure about that (and if I do then I'll
>>> probably end up leaving out closing brackets when I write code
>>> elsewhere...).
>>
>> Yes, in the default mode, I've had reports that the automatic
>> insertion is getting tedious to work with, since you don't jump after
>> the closing paren. Or maybe I could make it "jump after the closing
>> paren" only if between the cursor and the closing paren, only spaces
>> (or nothing at all) are present ? But I can already hear some people
>> tell they really wanted to insert a new closing paren, ... :)
>
> My own view of this is that you're trying to do something cool here, but it's
> too cool. When I am typing code I have an image of the code in my head and
> the simplest thing is just to type all of those characters, not to type a
> subset while keeping in mind which other ones the editor will type for me.
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.
>If this can be made to work with auto-indenting (requiring that auto-indenting
>works even if stuff after the insertion point is unbalanced -- and I
>understand that's not straightforward in the current implementation), then
>that would be best from my perspective.
>
>
> --
> 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
--
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
