After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 132824 - Tab and Shift Tab should indent en masse
Tab and Shift Tab should indent en masse
Status: RESOLVED FIXED
Product: gtksourceview
Classification: Platform
Component: General
0.7.x
Other Linux
: Normal enhancement
: ---
Assigned To: GTK Sourceview maintainers
GTK Sourceview maintainers
: 312976 338598 340708 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-01-29 04:02 UTC by Ben Maurer
Modified: 2014-02-15 12:53 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
patch (5.37 KB, patch)
2006-05-08 12:38 UTC, Paolo Borelli
reviewed Details | Review
corrected patch (5.43 KB, patch)
2006-05-08 14:21 UTC, Steve Frécinaux
none Details | Review
patch (5.67 KB, patch)
2006-07-29 15:02 UTC, Paolo Borelli
none Details | Review
patch (6.50 KB, patch)
2006-07-30 10:34 UTC, Paolo Borelli
none Details | Review
final patch (11.26 KB, patch)
2006-08-07 15:26 UTC, Paolo Borelli
committed Details | Review

Description Ben Maurer 2004-01-29 04:02:42 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.
Comment 1 Paolo Maggi 2004-02-02 10:52:03 UTC
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?
Comment 2 Ben Maurer 2004-02-02 15:50:56 UTC
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.
Comment 3 Daniel Borgmann 2004-04-09 09:42:45 UTC
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...).
Comment 4 Jeroen Zwartepoorte 2005-08-05 10:51:57 UTC

*** This bug has been marked as a duplicate of 107044 ***
Comment 5 Paolo Borelli 2005-12-15 15:45:55 UTC
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
Comment 6 Paolo Borelli 2005-12-15 15:48:02 UTC
*** Bug 312976 has been marked as a duplicate of this bug. ***
Comment 7 Paolo Borelli 2006-02-19 19:36:01 UTC
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 :)

Comment 8 Steve Frécinaux 2006-04-15 14:35:27 UTC
*** Bug 338598 has been marked as a duplicate of this bug. ***
Comment 9 Steve Frécinaux 2006-05-05 08:15:27 UTC
*** Bug 340708 has been marked as a duplicate of this bug. ***
Comment 10 Paolo Borelli 2006-05-08 12:38:27 UTC
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 11 Steve Frécinaux 2006-05-08 14:07:01 UTC
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.
Comment 12 Steve Frécinaux 2006-05-08 14:08:35 UTC
Well, no, I mean buf is not initialized.
Comment 13 Steve Frécinaux 2006-05-08 14:21:24 UTC
Created attachment 65025 [details] [review]
corrected patch
Comment 14 Paolo Borelli 2006-07-26 09:09:06 UTC
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.
Comment 15 Paolo Borelli 2006-07-29 15:02:16 UTC
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.
Comment 16 Paolo Borelli 2006-07-30 10:34:40 UTC
Created attachment 69904 [details] [review]
patch

updated so that applies on HEAD
Comment 17 Paolo Borelli 2006-08-07 15:26:39 UTC
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.
Comment 18 Paolo Borelli 2006-08-07 17:20:23 UTC
committed