Version: 2.2.1 (using KDE KDE 3.2.1) Installed from: RedHat RPMs This is especially useful with Auto Bracket enabled but might be useful/applicable even without. NOTE: In all cases here, ' + ' means "then type...", never the '+' symbol (exceptions are granted to 'i++' meaning increment i by one). All capitals mean a special button or the blinking cursor (clearly indicated). So CAPS LOCK means press the 'Caps Lock' key, not 'C' + 'A' + 'P' + 'S' + etc. Now the Auto Bracket option tries to save time by automatically typing in the closing bracket/brace which is great, but I'll still have to reach for an ARROW KEY or END button to get out of that section again which are actually further away than ')' or '}' or ']'. Now getting past these with ARROWS/HOME/END is a necessity, but there are many situations where I shouldn't need to. Here's my proposed solution: One example: if the opening and closing braces/brackets are on the same line, and the cursor is just before a closing brace/bracket, I want to just hit a configurable (read: easier) hot key like TAB to jump past that bracket. That is I should press TAB instead of reaching for the RIGHT ARROW and reaching back so I can put in a { or a ; like I would when making functions, loops, or function calls. So I can type: "functionName" + ( + "parameterName" + TAB) + '{' or ';' instead of: "functionName" + ( + "parameterName" + RIGHT ARROW) + '{' or ';' (remember ')' is there automatically so you don't type that in) Is there any reason to put a tab (read: \t) between two brackets or braces that are on the same line? A similar suggestion: with Auto Bracket enabled, typing '{' gives me: {CURSOR HERE} I would like: { CURSOR HERE } So I can put my functions or loops in, hit '{', and just continue typing instead of ENTER + ENTER + UP ARROW. *THIS DOESN'T MEAN PUT OPEN CURLY BRACKET ON A NEW LINE*. I actually prefer: for(i = 0; i < maxSize; i++) { CODE HERE } to: for(i = 0; i < maxSize; i++) { CODE HERE } One final suggestion is to interpret );) as an error that will delete the last round bracket. If I want to make a parameter free function call, I have a very quick tendancy to type "functionName + ( + ) + ;" very quickly which, with auto bracket enabled renders: functionName();) So the session is: "functionName" + ( + ) + ; + DELETE) + ENTER or sometimes: "functionName" + ( + ) + ; + END or RIGHT ARROW) + BACKSPACE + ENTER When I would like: "functionName" + ( + ) + ; + TAB or ENTER) To sum up and put together a whole session, here's a simple 'for' loop with every key stroke (Auto-Bracket enabled of course) (indents automatically of course, I don't think I can format this text properly): right now: for (i = 0; i < maxSize; i++RIGHT ARROW) + { + ENTER + ENTER + UP functionName();RIGHT ARROW) BACKSPACE CURSORHEREWHENDONE } And I would like: for (i = 0; i < maxSize; i++TAB) + { + functionName();TAB) CURSORHEREWHENDONE } Where both give this: for (i = 0; i < maxSize; i++){ functionName(); } This is hard to explain without a good visual :D Bottom line: I want to stop using arrows/home/end to navigate around brackets and braces which are *always* necessary with Auto-Bracket on. I am sure there are many other possibilities like these you all can come up with and I stronly encourage you share them. Thanks for an absolutely amazing editor otherwise!
Agreed, I've found auto brackets more trouble than it's worth. I actually find I spend more time moving my cursor around and deleting extra brackets than with this option off. Perhaps function brackets should not be created? Only structural brackets (IE: if, else, for, etc). Also i believe it would be nice if the closing structural bracket '}' could be placed on it's own line 2 lines below. IE: if (condition) TYPE_SQUIGGLEY_BRACE CURSOR_HERE CLOSING_BRACE_INSERTED_HERE --meaning-- if (condition) { CURSOR_HERE } That way based on the location of '{' it would place '}' two lines below with the cursor between the two. That way, autobrackets works for both styles "if (condition) {" and "one true brace."
*** This bug has been confirmed by popular vote. ***
you should look at Textmate on OS-X warning: you may never want to use anything else after
please also look at bug #101213 we may want to merge comments or something...
there is now a patch in #101213, I think it may answer what is requested on this bug as well.
IMHO in this example {CURSOR HERE} I would like: { CURSOR HERE } if you press enter after the first bracket it should indent the other one. so { + "CURSOR HERE" == {CURSOR HERE} but { + ENTER + "CURSOR HERE" == { CURSOR HERE // see auto-indent } // see indent align with current block level. if you dont press ENTER it should just stay on the same line as it is. the second suggestion is invalid IMHO you don't want to trap for );) I think we should just remove the extra bracket if [] as been type consecutively. semicolon as nothing to do there. see bug #101213 and I have a question for Mr Will Beldman: have you tried kate in KDE 3.5 ?
JUST upgraded to 3.5. I'll also peruse the changelog for kate. Yes, the enter and indent is a good idea too. On 1 Dec 2005 16:43:21 -0000, Mathieu Jobin <somekool@somekool.net> wrote: [bugs.kde.org quoted mail] -- "The unexamined life is not worth living" - Socrates
(In reply to comment #6) > if you press enter after the first bracket it should indent the other one. Yes, surely. > I think we should just remove the extra bracket if [] as been type > consecutively. I agree.
There's actually an extension available in the reposit that solves half of the above issues. The autoplacement of the brace } is done properly through usage of the autobrace extension. This solves the issue for {} see: http://jakob.petsovits.at/autobrace-update and http://websvn.kde.org/trunk/playground/devtools/kte_autobrace/ The above does not solve the closing of the function parameter section
As stated on #kate and bug 198540 I have a IMHO simple idea to solve that closing brackets problem. I didn't look in the code, yet, so I don't know how much effort it is. Idea is to have a stack with all closing parts that are inserted while using auto brackets. - if you just continue to write and type the contents of the stack, it will be ignored/replaced instead of added to the text and poped from stack - if you move the cursor right as pressing -> the brackets are poped from stack, too - if you make any more complicated move, the stack is cleared completely I think this will handle most of the cases where you are annoyed of "auto brackets"
Can you retest with current Kate version (KDE >= 4.6) ? There, using auto brackets together with the cstyle indenter works quite nice.
Any news?
I think the auto brackets works nicely already. what is the proposed change? I would close this as WORKFORME
Please add a comment, if it does not work correctly in a recent KDE version.
really needs improvement about this issue closing the brackets really annoys in this way (which is at the moment)
Muhammad, could you add exact steps to reproduce the bug?