current-column and invisible text

[Drew Adams]

Suppose I have an overlay in a given line of text, and it has properties
`invisible' and `before-string', where the `before-string' value is "12345".

The invisible text does not count in the calculation of `current-column' -
that makes sense. But I wonder about the `before-string' text. It seems that
regardless of its length, it counts as a single column. Is this normal? If
so, what is the rationale for this? I don't see this explained anywhere in
the Elisp manual. I would expect the `before-string' and `after-string'
values, together, to count in place of the overlay text, when counting
columns.

I understand that `before-string' and `after-string' are not really buffer
text, but they are display artefacts, so I would expect them to count in
column calculations. (They apparently do count, but only as one column,
regardless of their length).

Why does it matter? When resizing a `one-window-p' frame to fit its buffer,
I resize it to fit the longest line, and I do this by checking
`current-column' at each line end. If a `before-string' (or `after-string')
value of length > 1 is present, the line-length calculation will be
incorrect. The `current-column' just before the `before-string' is correct.
The `current-column just after the `before-string' text (and throughout the
invisible overlay) is one greater than the value before it, regardless of
the length of the `before-string' value. The longer the `before-string'
value, the worse my calculation of the line length.

If this is the intended behavior and not a bug, then, besides wanting to
understand the rationale, I'd like to know of a workaround. All I can think
of is trying to check, on each line, for the presence of an overlay with
`before-string' or `after-string' values, and somehow account for them
(which could be messy if an overlay crosses lines). That would be such a
pain that I would likely forego it. But if there is an easy workaround, I'd
be interested in knowing it. Thx.