GNOME Bugzilla – Bug 482977
Bracket Completion should let you manually complete a bracket
Last modified: 2019-03-23 20:47:52 UTC
Please describe the problem: I like the bracket completion plugin very much, but sometimes out of habit I close a bracket or quote as I'm typing. It would be nice if the plugin could track whether I had manually relocated the cursor position since the last open, and if not then don't insert the character I'm typing. For example, if I type this: int main (int argc, void* argv[]) {} all in one go without pressing any arrow keys or changing the cursor position with the mouse, I should not end up with this in my editor window: int main (int argv[]) {}}]) The implementation of this will probably be a stack of all the completion characters used since the last manual cursor move. You'd compare each character as it's typed to the last on the stack, not forward it to the window if it matches and pop it off the stack. I think Eclipse does something like this, but Eclipse has the worst UI performance of any app I've ever seen. I don't know what kind of performance issue this will cause for gedit, if any, having to compare every typed character to another... Does that sound like a reasonable request? How about my proposed solution? Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I like the idea. Do you have a patch ? ;-)
No, but if you give me some info I can give it a shot: - What file contains the plugin code? - How do I detect when the cursor position manually changes? - Is there any kind of framework for creating a stack of characters? - What language was this plugin written in? :-P I'd be happy it give it a shot.
*** Bug 523257 has been marked as a duplicate of this bug. ***
Created attachment 119550 [details] [review] This patch implements this feature Maybe it could be implemented as an optional feature, but at the moment I don't know how to do that, I will learn soon and maybe post another patch, though
*** Bug 554230 has been marked as a duplicate of this bug. ***
Comment on attachment 119550 [details] [review] This patch implements this feature --- gedit-plugins-2.18.0/plugins/bracketcompletion/bracketcompletion.py +++ bracketcompletion.py @@ -35,6 +35,7 @@ 'ChangeLog': { '<' : '>' }, 'HTML': { '<' : '>' }, 'Ruby': { '|' : '|', 'do': 'end' }, + 'PHP': { '<' : '>' }, 'XML': { '<' : '>' }, } @@ -90,6 +91,10 @@ self._brackets.update(common_brackets) else: self._brackets = common_brackets + + self._closing_brackets = [] + for k in self._brackets: + self._closing_brackets.append(self._brackets[k]) def get_current_token(self): end = self._doc.get_iter_at_mark(self._doc.get_insert()) @@ -186,21 +191,36 @@ return word, start, end = self.get_current_token() - - if word not in self._brackets: + + # skips over the closing bracket + if word in self._closing_brackets: + + start = end.copy() + end.forward_chars(len(word)) + text = start.get_text(end) + if text == word: + self._doc.begin_user_action() + self._doc.delete(start, end) + self._doc.end_user_action() + self._doc.place_cursor(start) + return + end.backward_chars(len(word)) + + + if word in self._brackets: + + bracket = self._brackets[word] + + # Insert the closing bracket + self._doc.begin_user_action() + self._doc.insert(end, bracket) + self._doc.end_user_action() + + # Leave the cursor when we want it to be + self._last_iter = end.copy() + end.backward_chars(len(bracket)) + self._doc.place_cursor(end) return - - bracket = self._brackets[word] - - # Insert the closing bracket - self._doc.begin_user_action() - self._doc.insert(end, bracket) - self._doc.end_user_action() - - # Leave the cursor when we want it to be - self._last_iter = end.copy() - end.backward_chars(len(bracket)) - self._doc.place_cursor(end) class BracketCompletionPlugin(gedit.Plugin):
Created attachment 119555 [details] [review] Better patch with consistent indentation Sorry for the mess above. This patch is the same as the other one but it has consistent indentation. All that this does is checks if the character typed was a closing bracket and if there was a closing bracket as the next character and if there was it just skips over the closing bracket. This is exactly what eclipse and netbeans do ie. it is "stupid", it doesn't care if the end bracket was there from auto completion or not. In the end it doesn't matter because you'd still have to move the cursor over one way or another.
Comment on attachment 119555 [details] [review] Better patch with consistent indentation >+ 'PHP': { '<' : '>' }, It does not belong to that patch. More, <> in PHP is very annoying because it completes also for <, >, <= and >= signs, and best practice in PHP nowadays seem to lean towards separate files for "HTML templates" and actual PHP code. >+ self._closing_brackets = [] >+ for k in self._brackets: >+ self._closing_brackets.append(self._brackets[k]) This is self._brackets.values() >+ # skips over the closing bracket >+ if word in self._closing_brackets: if word in self._brackets.values(): >+ start = end.copy() >+ end.forward_chars(len(word)) >+ text = start.get_text(end) >+ if text == word: >+ self._doc.begin_user_action() >+ self._doc.delete(start, end) >+ self._doc.end_user_action() >+ self._doc.place_cursor(start) >+ return >+ end.backward_chars(len(word)) Removing a char that just had been inserted looks awkward to me. I think you should try to handle this in the key-press-event handler instead. I think the "closing bracket recognition" would never work ok for multi-char tokens anyway.
Yeah you are right. It was a quick hack for my personal use that works for me. My Python skills obviously leave much to be desired so I will fix those bits... As for the actual insert and removal, I agree it is awkward but since I've never used pyGTK before I just implemented something that would not require restructuring the rest of the plugin, because I don't really understand it yet. I might try to make it more elegant at some point, but for now it works for me so I might not do it soon...
nacho implemented this in svn. will be in next release
Tested, works great for everything, except < >. I noticed that those get autocompleted but not affected by this patch, for some reason. Tried with a random XML file, the > is not "replaced" when I press >.
This should be fixed since a few version ago.