GNOME Bugzilla – Bug 343755
insert-spaces does not work as expected when tabs are present
Last modified: 2014-02-15 12:53:00 UTC
If you have tabs in the line, have insert-spaces-instead-of-tabs on and hit <tab>, it will add a wrong amount of spaces. You can do it this way: 1. Create a file containing tabs 2. Enable insert-spaces 3. Hit tab on a line already containing tabs. For instance, having a tab size of 4, if I have a line containing two tabs and I hit the tab key, it will only add two spaces. This is due to that line: (in gtksourceview.c, gtk_source_view_key_press_event) > num_of_equivalent_spaces = tabs_size - (cur_pos % tabs_size); It could be replaced with something like this one: > gunichar c; > GtkTextIter tabiter = cur; > gint tabpos = cur_pos; > > /* Find the position of the last tab of the line > (the 0 offset if there is no tab) */ > do > { > tabpos--; > gtk_text_iter_backward_char (&tabiter); > c = gtk_text_iter_get_char (&tabiter); > } > while (tabpos > 0 && c != '\t'); > > if (c == '\t') > tabpos++; > > /* count chars from the last tab to the current position */ > num_of_equivalent_spaces = tabs_size - (cur_pos - tabpos) % tabs_size; Sorry for the lack of real patch but I'm not able to test it right now. I did this patch on an already patched version of gsv and didn't take the time to redo it against a clean cvs version.
Created attachment 66713 [details] [review] patch
Created attachment 66739 [details] [review] updated patch Fixes an issue when trying to indent from offset 0 in the previous patch.
the patch looks correct to me: in practice we start counting from the last tab instead of the beginning of the line. I think we should get this committed. In fact it should prolly also go in gnome-2-14 branch
Created attachment 69879 [details] [review] patch This updated patch also fixes another similar issue I found: when pressing tab with a selection the spaces are appended to the selection instead of replacing it.
fixed