Like the documentation says, Reflow Lines/Block breaks lines **at** the long line marker if the line breaking is disabled. The problem is that the long line marker marks characters **after** the given column. This means that Reflow Lines/Block should probably reflow at `eprefs->long_line_column + 1`:
https://github.com/geany/geany/blob/b6fe9f17aeae40ab48e73481e618877e65db464b...
How do you count your columns, from 0 or from 1?
From 1, I guess: the status bar says that the column is 0 only when the caret is at the beginning of the line.
When line breaking is on the break happens when you type in column X (where X is the setting) and counts from 1.
And manually applied reflow is consistent with this, it breaks at the same place, which is what is expected. That happens irrespective of which setting it uses, line breaking setting or the long line setting, same setting value X, same breaking place. It would be a problem if the breaking happened in different places depending on which setting was used when they had the same value.
But long line marker is actually for another completely separate use which is to identify lines _longer than_ X, so the vertical line is located _after_ column X counting from 1 or sets background for the columns _after_ column X. So it doesn't mark column X, the breaking column.
So it seems to me both cases are doing the right thing. Perhaps the manual can be improved, feel free to propose a change via pull request if you think so.
Note the status column count is variable, you can change it to count from [zero or one](https://www.geany.org/manual/current/index.html#statusbar-templates).
Yes, manual reflow breaks in the same place, but this is exactly what surprises me.
I used to set the long line marker one column shorter than the breaking column (70 and 71 respectively). That way they behave consistently: when line breaking is enabled, typing the 71st character (that is, the character after long line marker) results in a line break; when line breaking is disabled, the 71st character exceeds the long line marker and is either shown after the vertical line or gets highlighted.
With these settings and line breaking enabled, both automatic breaking and manual reflow give the same result - a line takes up to 70 characters, as expected. But with disabled line breaking, manual reflow limits lines to 69 characters.
As you said, the long line marker is used is to identify lines _longer than_ X. As a user, I expect Reflow to wrap lines _longer than_ the marker's X as well, but instead it wraps at (X - 1). That's rather strange and inconvenient.
But with disabled line breaking, manual reflow limits lines to 69 characters.
Yes because its using a setting that has a value that is one smaller.
As a user, I expect Reflow with disabled Line Breaking to wrap lines _longer than_ the marker's X as well, but instead it wraps _at_ X. That's rather strange and inconvenient.
I have to say I find it simple and consistent, line breaking always behaves the same, it breaks __at__ the specified column, always, no matter what, thats being consistent. Long line functionality marks __after__ the specified column.
Note the two different emphasised words in the paragraph above, the two functions are different so of course they don't align.
Line breaking is a per document setting, it can be turned on and off for any document, but the settings are session wide. Suddenly having manual reflow happen at a different place because automatic line breaking is turned on for one document and off for another, even when the settings are the same number would be confusing and wrong.
Perhaps reflow should only ever use the line breaking setting, even if automatic breaking is off. That way the two functions are totally independent and internally consistent with themselves, instead of the same number (long line) being used in two different ways by two different functions.
Perhaps reflow should only ever use the line breaking setting, even if automatic breaking is off.
Yes, I think that would be more convenient and less surprising, at least in my particular use case.
I have to say I find it simple and consistent, line breaking always behaves the same, it breaks **at** the specified column, always, no matter what, thats being consistent.
It is not doing it consistently but not correctly. Regardless of whether you take 72 to mean column 72 (73rd column starting at 0) or 72 characters (ending inclusively with 71 starting at 0), that is not what the program is doing. It is reflowing but only allowing 71 characters per line, and the same occurs with Line Breaking. There is no possible way to interpret The setting "Column: 72" in the Preferences, Editor, Display tab as 71, unless it is a bug and interpreting column 72 as exclusive, and even in that case the right side of the character is still touching it not going past it. It would be reasonable for any user to assume that since it places the green line after 71 that it is starting at 0, or that it means 72 characters is a "long" line. Either way, that is where the green line is and not how reflow and Line Breaking behave. I confirmed it is not a problem with the pixel-based approach of Scintilla discussed here (may not apply to recent versions): https://lists.geany.org/pipermail/users/2012-March/007951.html because the behavior is the same whether I write a `t`, `m`, or `.` for the last character of "not" in the example below, Geany only allows 71 characters per line for Line Breaking or reflow. I can't type up to the green line with line breaking on, and with it off, I can't reflow up to it. My long line marker is 72 (and always has been so the problem is not something like #1358). Example: ``` Hippopotamuses may like apples but we will never know because I will not get that close. ``` (Geany doesn't allow "not" on the same line. Though that would be 72 characters, Geany only allows 71)
I am using Geany 1.38.
There are two independent functions and two settings.
1. line breaking, lets call the setting B, which adds a line end at the Bth __character__ (except tabs may be counted as more than one) on the line, irrespective of where on the screen it happens to be, so it is independent of font and screen width of the characters on the line.
2. long line marking, lets call the setting L, which indicates a __screen position__ with a vertical line or background at the pixel position of L space (0x20) characters in the current font and is the same for all lines on the screen irrespective of the characters on the line, even if they are double width, zero width, or using a non-monospace font.
So they are doing different things, counting characters and counting screen position in pixels. The only time there might be a coincidental relationship is with a proper mono font and all single width characters.
But somebody had the idea of using L instead of B if B is not set. That is the number set for L is used as B, there is no interaction between the functions, just they have the same number as their setting. So there is no guarantee that they will do the same thing, and again it is only coincidentally close with single width characters, no combining characters and monospace font.
it is only coincidentally close with single width characters, no combining characters and monospace font.
Yes, in my test I was using a monospace font.
In general these sort of discussions are not helped by the imprecise terminology used by Scintilla (inherited from long ago Windows where it was first developed IIUC) and therefore by Geany, character and column.
A "character" approximately maps to a Unicode code point, but I am not gonna guarantee that nowhere in the Geany manual is "character" used where the writer meant "byte".
A "column" has never existed since ASCII 80x24 terminals. The concept does map to glyphs for ASCII, but not otherwise since glyphs are not the same width and so "columns" do not map toglyphs or characters when:
- non-monospaced fonts are used - CJK characters are used (mostly double wide) - Symbols are used - zero width characters are used - combining characters are used.
When typing English text for sure these are not needed every character, but even then CJK and combining characters are needed for names, for example the ö in the name of one of Geany's esteemed originators is made from lower case ASCII `o` and `U+308`, thats two "characters" for one "column".
A specific comment as well:
use "72" not 73 for PEP8
The use-case for line breaking is not code line length assurance, it does not know anything about Python (in the PEP8 case) or any other programming language, so it could easily generate illegal code when breaking at arbitrary places, and for a setting B the break happens when the Bth character is typed (or the Bth line character when reflowing which is just line breaking applied to a selection/paragraph). The use-case for line breaking (and reflow) is for human language text, where breaks are less semantic and breaking at spaces works for most Western languages at least.
The use-case for the long line is for indicating code that exceeds some "limit" without actually performing a break and causing chaos in the code, here a setting of N (eg 72) will allow N single width glyphs before the vertical line, and since code is usually edited monospaced it works ... so long as no comments or strings or identifiers have non-ASCII characters in them :grin:. (yes Python and other languages even C++ and soon C gasp!! identifiers can be non-ASCII, think math `Σx = sum(x)`)
github-comments@lists.geany.org