Word wrapping is not respecting indentation

Bug #318517 reported by drx on 2009-01-18
This bug affects 11 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Won't Fix
gtksourceview3 (Ubuntu)

Bug Description

Binary package hint: gedit

When wrapping a line it would be awesome to have gedit indent the wrapped line just like the original line.

Imagine "_" being a space character, the current wrapping works like this

____hello hello hello hello hello
hello hello hello

It would be better if it worked like this:

____hello hello hello hello hello
____hello hello hello

While editing this makes code-indentation readable even if the editing window is resized to be very narrow. It is also very helpful for unavoidable long lines, like regexps or URLs. It makes formatting less of a pain with generated code. etc etc etc

KDE editor component and Eclipse both have this behaviour, it was also present in the famous EditPlus editor for Windows.

I am sure i am not the first person requesting this feature, so i wonder if there is a philosophical stance against this wrapping style or if a plugin is available to handle it.

ProblemType: Bug
Architecture: i386
Date: Sun Jan 18 20:17:05 2009
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/gedit
Package: gedit 2.22.3-0ubuntu1
PackageArchitecture: i386
SourcePackage: gedit
Uname: Linux 2.6.24-23-generic i686

drx (drx) wrote :
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, there is a similar request on http://bugzilla.gnome.org/show_bug.cgi?id=321910

Changed in gedit:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist
status: New → Triaged
Changed in gedit:
status: Unknown → New
David (david.regev) wrote :

There is also an upsteam bug for gtksourceview: http://bugzilla.gnome.org/show_bug.cgi?id=326821 .

I would like to amend the original suggestion slightly. When a line is wrapped, instead of inheriting indentation, I think it should inherit the last tabstop. To use a common use case as an example (‘ → ’ represents a tab and ‘ ↲’ represents a soft wrap.):

 → somePieceOfCode(); → // This is a very long comment ↲
                            that spans two lines.

Note that the second line is indented to the position of the most recent tabstop rather than the indentation of the whole line. As far as I know, the other editors that do wrap more intelligently do not take such non-initial tabs into account. I believe that this suggestion yields even more readable text, as the whole comment in now separate from the actual code. This would also be useful in the many cases where text is arranged in a table-like manner. When tabs aren’t inserted in the middle of a line, the result is identical to the the original suggestion.

Changed in gedit:
importance: Unknown → Low
drx (drx) wrote :

There is a gedit-plugin available that does great things with tabstops and indets, called "elastic tabstops", see

It does what i asked for and many things more, but it is terribly slow. A few kilobytes of code will slow the editor down to be almost unusable. But maybe it is a good thing to build upon it.

David (david.regev) wrote :

drx: Elastics tabstops doesn’t indent wrapped lines. I do think the two features go hand-in-hand: elastic tabstops make tabs semantic, while indented wrapping makes new lines semantic. In fact, I asked[*] the author for this feature, but he believes that someone should provide this functionality in a separate plugin.

[*] http://nickgravgaard.com/elastictabstops/news/support-for-more-editors-in-the-works/

Tory (tory-andrew-law) wrote :

This would be nice...

Changed in hundredpapercuts:
milestone: none → gedit
assignee: nobody → Paper Cuts Ninja (papercuts-ninja)
Timothy Arceri (t-fridey) wrote :

The following is copied from the Upstream Bug:

Ignacio Casal Quinteiro (nacho) [gtksourceview developer] 2012-12-04 17:15:42 UTC

Here are some find outs from a quick research that I made today.
First of all we need to touch almost all the layers to have this working, so if
somebody is brave enough to make it here are the steps:

1) Get the size of a tab "\t" from the gtktextlayout.c. For this we can either
check if there is a way to get it from the pango layout or we could as well
move the tab-width property from GtkSourceView to GtkTextView.

2) From the gtktextlayout.c we need to detect the indentation of the paragraph,
counting the number of tabs and get the size in a pango scale.

3) For that layout we need to set the indentation level for the wrapped text.
For this we can already do it by setting a negative value to the pango layout
indent value (i.e set_indent(-20)). Although I think the right thing to do here
is to set a new set/get_indent_wrapped_text, which will do the same as the
indent value but just for the wrapped text.

4) We need to add a setting into gedit, either in the preferences dialog or at
this point it could be easily done with a plugin. (A setting in the dialog I
think it would be better though).

So if somebody wants to have some fun feel free to go fixing each of those
steps, and if you have any question we are like always in the irc channel
spotted in the previous comment.

Changed in hundredpapercuts:
status: New → Triaged
Sebastien Bacher (seb128) wrote :

@Timothy: thanks for following up there, the fix seems to be non trivial and impact several components... not sure if that qualify for a papercut bug?

affects: gedit (Ubuntu) → gtksourceview3 (Ubuntu)
Changed in gtksourceview3 (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Timothy Arceri (t-fridey) wrote :

@Sebastien: I think we should leave this as a papercut bug for now, part of the reason for the decline of the papercut project has been the lack of bugs to actually work on. Relaxing the criteria for a papercut has meant we have been more productive so far this release.
To be honest from my experience most papercuts are non trivial otherwise they would just have been fixed already.

Changed in hundredpapercuts:
milestone: gedit → papercuts-s-gedit
Changed in hundredpapercuts:
importance: Undecided → Low
Bib (bybeu) wrote :

At least a control button wrap/unwrap in the toolbar would be a great feature, whatever is the fate of the wrapping indentation request.
... or a direct keyboard shortcut
hscwftic (hope some coder will find this idea cool :) )

Changed in hundredpapercuts:
assignee: Papercuts Ninjas (papercuts-ninja) → nobody
importance: Low → Wishlist
Changed in gedit:
importance: Low → Wishlist
Changed in gedit:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.