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. > 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. > 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! >> 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. > 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. 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
