[texworks] Problem with line mangling

[Paul A Norman]

May be (if not already tried) posting a picture of the line numbers
jumbled up, in appropriate Qt forums (even bug reports) asking how the
component could ever do that?

I'm stepping back from the detail, to propose that the result seen of
line numbers jumbled on top of each other be treated as the problem at
face value.

i.e viewing it as a flaw in the component that that could ever happen at all.

Simply that the failed functionality by which line numbers end up
superimposed on each other be treated as the basic bug?
Or if the fault lies in Tw somehow there must be someone in Qt who
knows how such a line number pileup could happen?

I'm thinking here how the numbers superimpose themselves on each other
- there could only be a few mechanisms known to the Qt designers, by
which that could even happen perhaps?

As I say, as the detail is obscure - retreat to the obvious and
visible that is not obscure - numbers piling up on each other - push
the point `how can that happen'?

Additionally, If we can can say (giving reasons) that it looks pretty
solid that the problem came in with Qt version so and so ,,,

Paul


On 7 July 2011 23:23, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> On 2011-07-07 12:18, Paul A Norman wrote:
>> There seem to have been some connected issues for a while possibly as
>> far back as 2009 depending on the true status/nature of this report.
>> http://code.google.com/p/texworks/issues/detail?id=176&can=1&q=line%20number
>
> I agree with Jonathan here, this was a different problem.
>
>> Definitely pre February 2011
>> http://code.google.com/p/texworks/issues/detail?id=469&can=1&q=line%20number
>
> Like Jonathan, I too am weighing the possibility that this is indeed a
> Qt issue. Of course, having someone else to blame doesn't help the
> normal Tw user much, but maybe it could give us some more insight into
> what's going on (and eventually the possibility to report this to Qt
> upstream properly).
>
> Anyway, regarding the Qt versions I can give some (approximate) numbers:
> Tw on Windows is built using the mingw-cross-env environment. From its
> release notes, I compiled the following
>
> Jun 8 2010 - Oct 27 2010: mingw 2.14-2.15, Qt 4.7.0beta1
> Oct 27 2010 - Dec 11 2010: mingw 2.16, Qt 4.7.0
> Dec 11 2010 - Mar 19 2011: mingw 2.17-2.18, Qt 4.7.1
> Mar 19 2011 - Jun 7 2011: mingw 2.19-2.20, Qt 4.7.2
>
> All dates are mingw-cross-env release dates, so add maybe a week or two
> until I upgraded and used it for Tw. But it should give some rough
> estimates when which version of Qt was in use.
> Some additional things:
> I don't remember any reports from Ubuntu before the 11.04 release (and
> at least one colleague of mine used it to write his thesis). Ubuntu
> 11.04 (natty) uses Qt 4.7.2, whereas its predecessor, Ubuntu 10.10
> (maverick) used Qt 4.7.0.
>
> This doesn't imply any hard facts, of course, but still suggests that
> the problem was not present int Qt 4.7.0. Together with the pre Feb 2011
> condition, this suggests that the problem was introduced in Qt 4.7.1 (if
> this theory holds, of course).
>
> One more supporting fact is that, during debugging, I tried to bisect
> the source changes to see when the problem occurred, and IIRC I could
> reproduce the issue (using Qt *4.7.2*) back to revisions with some 600
> revision number (dating back to Apr-May 2010). So, assuming the problem
> didn't exist in the builds back then (could someone check?), this is
> even more evidence for the Qt origin. Still, we have to find a way to
> work around it for now (preferably without the need to patch Qt, which
> doesn't work on OSs that use system libraries, such as Linux)...
>
>> Stefan, your point about memory -- my short document was opened second
>> after a much much longer one.
>
> I don't know, these are just wild speculations at this point. But
> otherwise it's hard to explain why this would be so unreproducible...
>
> HTH,
> Stefan
>