Line wrap breaks at word boundaries (word wrap). Straight line wrapping - breaking at a column - would be better for long lines of cryptic code.
When long lines end with series of tabs followed by text intended to align at column, calculation of column varies by number of characters preceding the wrap.
To replicate, type a long line of text that wraps a couple of words onto the (wrap) following line<tab><tab><tab><tab>Aligned Text
Insert characters into the first line (before the wrap) and watch "Aligned Text" shift a character at a time.
Expected behavior is "Aligned Text" should only shift a tab at a time, as the second line increases length. The number of characters on the first line, before the wrap, shouldn't make any difference.
Xubuntu 17.10 with latest Geany from repository (1.29).
Scintilla (the editing widget Geany uses) does the wrapping, and allows for word, character or whitespace wrapping (or no wrapping of course). Geany currently only switches between word wrapping and no wrapping. A well written pull request that allowed the alternative wrapping choices to be selected, both in the document menu and the default in the preferences dialog, for example using a combo box, would probably be accepted.
Makes sense. So the alignment problem originates with Scintilla, and character wrap is easy to implement but counts as a feature request? It's unusual for a text editor to implement word wrap before character wrap. I suspect that the alignment problem is with word wrapping not character wrapping. Still thinking of a workaround. Changing space characters or word characters doesn't affect word wrapping. Does anything else?
To be clear, the wrapping options are already implemented in Scintilla, but Geany does not have any way for the user to select the option. So all you get is word wrap or no wrap.
I guess whoever made the UI to turn wrapping on only wanted it for documentation (ie text) not for code. Long lines are often frowned on in code, and since there is no way of knowing where a wrap is gonna be (since it depends on how wide the screen is), two users looking at the same file may not see the same thing.
Though I suspect that no matter what type of wrapping is chosen tabs and wraps may not interact well together.
Compare to gedit.
Geany 1.3.6
Paste the following into a new window:
When I consider every thing that grows Holds in perfection but a little moment. -- Random 1
But wherefore do not you a mightier way Make war upon this bloody tyrant Time? -- Random 2
With line wrapping on, "-- Random 1" and "-- Random 2" should align correctly.
Next, drag the window to it's minimum width, so both lines wrap to two. "-- Random 1" and "-- Random 2" are no longer correctly aligned.
@oonet those two lines do not align with a monospace font, so you must be using a variable width font.
Since wrapping is by word, and the words in the two lines are different lengths the wraps won't align most of the time.
Using monospace font.
Problem with test is tabs weren't included for cut and paste. Silly me! Sorry about that. . . .
If you insert however many tabs before the "--" in a wide window, they can be made to align. Then reduce the width of the window as far as it will go. Inserting tabs can *not* align the text. (Unless enough tabs are inserted to place the "-- Random" text on a *third* line, in which case they will align again, as expected.)
You seem to be misunderstanding how tabs work, they do not align things, they simply move the next character to the next tab stop. The location of tabs stops is the pixel location at the position of every n spaces in the default font, where n is set in preferences and defaults to 4.
Of course since those positions are the same on each line, tabs can be used by humans to make things align.
But what to do when wrapping? Re-tab the wrapped part of the text, or tab based on the full line and copy that number of pixels when wrapping. Either could be considered valid, and Scintilla appears to do the second, probably because it is less costly, and wrapping is already very expensive.
But since wrapped tabs are just a number of pixels this means that the position of the `--` is determined by the number of non-tab characters before the tab, so it can take positions that are not on tab stops.
Closed #1495.
Thanks for the explanation. I guess you have no control over what happens in Scintilla. (Scite has the same problem.)
Scintilla is the only editor I've seen with this bug. Typically, the window width is divided into fixed tab stops so text following a tab always falls precisely on a stop rather than between them.
One thing to note is that Scintilla can set tab stops anywhere, not just on equal divisions (although Geany does not expose the capability). That could cause weird effects when combined with wrapping, so probably another reason it works as it does.
github-comments@lists.geany.org