GNOME Bugzilla – Bug 132824
Tab and Shift Tab should indent en masse
Last modified: 2014-02-15 12:53:00 UTC
When selecting multiple linse Tab and Shift Tab should atomicly indent or unindent the selected lines. Gedit has a plugin for this (not using the tab and shift tab keys), glimmer does it, and MD does it. We need to check if it is an a11y problem, though every editor i have seen does it.
Well, I think this should be eventually fixed in GtkTextView. We should ask the UI and A11Y guys and eventually provide a patch for GtkTextView. BTW, I think the gedit solution would be ok since I don't think GtkSourceView should behave differently from GtkTextView while editing. Gustavo?
I am not sure if *every* text buffer should have this functionality. I mean, in most buffers, it doesnt really do what you want. I mean, the only time indentation is really meaningful is in code. Most users do not want to increase the indent level of something. wrt to a11y, this is pretty much solved because ctrl+[shift]+tab will move backwards/forwards just as [shift]+tab does in most controls. I do think there are some editing issues that a code editor should do differently than a `normal' text entry. For example, in code, ctrl+arrow should act differently than with text.
But why would a user want to press tab to delete several lines of text instead? Just (un)indenting seems like a much safer and useful action to me, and it would also be more consistent to have it in GtkTextView. Imagine a user would be used to this behavior from his text editor and then tries the same in some other text entry: Instant data loss (of course there is undo, but still...).
*** This bug has been marked as a duplicate of 107044 ***
ah, here it is... I couldn't find this bug anymore. I don't think this is a dup of 107044. That bug deals with support for language sensitive autoindentation. This one just requests that tab and shift+tab add/remove indentation from an selected block of text behving like the current gedit indent plugin. Like discussed many times (though I can't find the relevang bugs at the moment) the major concern with this is the interaction with accessibility, since a11y makes use of shift+tab. [I am reviving this because I am still convinced that it's a valid request, we should try to get an opinion out of a11y people instead of speculating] also, I need this bug open so that I can mark others as dup of this one :P
*** Bug 312976 has been marked as a duplicate of this bug. ***
Ok, finally discussed this with Calum during the gedit UI-review: (19:15:04) <joachim> when's a good time to talk about indent/unindent? (19:15:14) <pbor> joachim: what about it? (19:15:33) <joachim> it seems every gnome text editor has different shortcuts for this (19:16:20) <pbor> well, we get *tons* of bugreports about asking to use tab for "mass indent" many lines (19:16:35) <pbor> would be nice to get a word from calum about this (19:16:55) <pbor> we currently use ctrl+t and ctrl+shift+t (19:16:55) <joachim> bluefish uses CTRL < > (without shift, but that;s the mental association) (19:17:07) <joachim> SubEthaEdit on OS X uses CTRL [ ] which is nice too (19:17:15) <joachim> both of thoe have a visual association that's nice (19:17:28) <calum> have to say that selecting a bunch of lines and hitting Tab is usually the first thing I try, I don't know why though :) (19:17:56) <calum> (because my head tells me that should replace the selection with a tab...) (19:17:59) <pbor> calum: yup, the problem is that we need something similar for unindent (19:18:06) <calum> Shift-Tab? (19:18:13) <joachim> yup, that works on SciTE (19:18:16) <pbor> yes, that would be the first guess (19:18:34) <pbor> calum: but we were always afraid to break keynav (19:18:43) <pbor> focus handling I mean (19:18:47) <joachim> what do you think about <> or [] ? (19:19:06) <kikidonk> eclipse uses tab (19:19:13) <kikidonk> and ctrl-tab (19:19:57) <pbor> joachim: they are very uncomfortable on my keyboard (19:20:05) <calum> pbor: well, in a text editing app, I don't think anyone would really expect Tab/Shift-tab to move focus out of the editing window... we use Ctrl-Tab and Shift-Ctrl-Tab instead for those situations... (19:20:32) <calum> s/use/tell people to use :) (19:20:42) <mknepher> bluefish uses < and >, but I prefer the tab button (19:21:09) <pbor> joachim: on a .it keyboard <> [] require shift or alt gr to be typed (19:21:14) <pbor> calum: rock on (19:21:18) <joachim> yuck! (19:21:54) <pbor> calum: I just need to convince paolo then and we then get it in sourceview so that all app using it benefit (19:22:07) <calum> fine by me :)
*** Bug 338598 has been marked as a duplicate of this bug. ***
*** Bug 340708 has been marked as a duplicate of this bug. ***
Created attachment 65018 [details] [review] patch since this comes up pretty often on irc here is the patch implementing the change. Note that this is the minimal patch that only makes tab and shift+tab (un)indent. We should probably consider the following additional issues: * we should probably make indent/unindent public methods * maybe they should be vfuncs, so that they can be overridden (for instance implementing indenters) * maybe we should make the behavior dependent on a enable_mass_indent property * maybe some of the api belongs to GtkSourceBuffer instead of View.
Comment on attachment 65018 [details] [review] patch > +static void > +insert_tab_or_spaces (GtkSourceView *view, GtkTextIter *iter) > +{ > + GtkTextBuffer *buf; > + gchar *tab_buf; In that function, buf == NULL when view->priv->insert_spaces == FALSE.
Well, no, I mean buf is not initialized.
Created attachment 65025 [details] [review] corrected patch
Ok, we want this to go in, but make it slightly smarter (see eclipse and kate): when just a part of a line is indented, Tab should replace the selection with \t, while when the whole line or more than a line is selected Tab should indente. Shift+Tab always unindent. I stilll think adding a property to turn off this feature is a good idea, while I think methods to indent, unindent a line can wait until a real user see the need for them.
Created attachment 69876 [details] [review] patch Ok, here it is one more patch implementing the 'smarter' behavior described above. It still doesn't include a property to make the mass indenting optional... how should such a property be named? By the way, I also spotted a bug in the current code: if you have 'insert spaces instead of tabs' checked and you press tab with some text selected, the spaces are appended to the selection instead of replacing it.
Created attachment 69904 [details] [review] patch updated so that applies on HEAD
Created attachment 70396 [details] [review] final patch Ok, here is the patch I am going to commit. It is the same as last one but it makes the feature conditional to the 'indent-on-tab' property. The property is off by deafult in order to not break potential users which already deal with tab (indenters etc), we may revisit this on gsv 2.
committed