Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line Number Mangle - Text disappears (hidden) #469

Closed
GoogleCodeExporter opened this issue Mar 14, 2015 · 17 comments
Closed

Line Number Mangle - Text disappears (hidden) #469

GoogleCodeExporter opened this issue Mar 14, 2015 · 17 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Just use Tw as usual
2.
3.

What is the expected output? What do you see instead?

Line numbers are readable if turned on
Sometimes they become mangled and adjoining text is hidden

Using Format/ turn line number off, and then repeat but turn back on, sorts it 
out and comes right.

I also got caught with http://code.google.com/p/texworks/issues/detail?id=222
Thinking that changing the preference would also change the current document at 
the same time - made a comment there as well.

What version of the product are you using? On what operating system?

----- configuration info -----
TeXworks version : 0.3r728 (MinGWcross)
Install location : D:/LaTeXPortable/LatexUtils/TeXworks/TeXworks/TeXworks.exe
Library path     : D:/LaTeXPortable/LatexUtils/TeXworks/TeXworks/config\
pdfTeX location  : D:/LaTeXPortable/LatexUtils/MiTeX 2.8.3541 
Portabe/miktex/bin/pdftex.exe
Operating system : Windows XP Professional Service Pack 3
Qt4 version      : 4.7.1 (build) / 4.7.1 (runtime)


Please provide any additional information below.
Can't discern what causes it to happen.

Original issue reported on code.google.com by paul.a.norman on 8 Feb 2011 at 1:42

Attachments:

@GoogleCodeExporter
Copy link
Author

Hm, to me this seems like a Qt bug. In fact, I would consider the line numbers 
to work "correctly", showing the place where the (hidden) lines should be.
My guess is that there is a problem with the layouting of the text. If you 
disable/reenable the line numbers, the effective widget width changes, the text 
is relayouted, and the missing paragraphs reappear.
Doing a quick browse through the Qt bug reports, I didn't see anything related, 
but that doesn't mean anything. You could try raising the issue on the Qt 
forums, but without finding a reliable way of reproducing this it will be 
impossible to debug...

Original comment by st.loeffler on 9 Feb 2011 at 4:55

@GoogleCodeExporter
Copy link
Author

I've had this problem too right now, [TW 0.4.0 r.759 on Win 7 HP 32bit] but I 
was able to turn off this unwanted "merging" by turning off line numbering via 
the format-menu and turning it on again. As default setting in preferences I've 
got line numbering enabled.

In my case only "empty" lines seemed to merge into one empty line with many 
numbers at once. Don't now how to reproduce, will keep an eye on that!

Johannes

Original comment by [email protected] on 28 Mar 2011 at 12:10

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

So, this is not XP-specific, but still seems to be limited to the Windows world.

I did another search of the Qt bug reports, but I still couldn't find anything 
identical to this (though there are a couple of issues related to wrapping and 
eliding).

In any case, I'd really like to resolve this problem, but haven't got 
information to reproduce this, let alone track it down. Any information you 
could provide would be helpful!

A few questions that might get you started:
 * Does this happen at load-time (i.e., when you open a file, as opposed to after hacking away in/changing the document)?
 1) Does this happen on short documents as well (say, less than 1000 lines, or less than 100 lines)?
 2) Does this happen on short, non-empty lines (where no wrapping kicks in)
 3) Does this happen without wrapping (i.e., when you have it disabled)?
 4) Does it go away when you change the wrapping mode?
 5) Does it go away when you change the editor font/font size?
 6) Does it go away/change when you restart Tw (i.e., close, then reopen the same document at the same place)?

Original comment by st.loeffler on 12 Apr 2011 at 8:43

  • Added labels: Security, OpSys-Windows

@GoogleCodeExporter
Copy link
Author

The problem didn't occure another time yet, I don't know how to reproduce too. 
I Try to remember the circumstances while it happend:
 1) Does this happen on short documents as well (say, less than 1000 lines, or less than 100 lines)?
    - Yes, <1000, my document had about 350 lines, but long lines (one paragraph a line)
 2) Does this happen on short, non-empty lines (where no wrapping kicks in)
    - Not yet noticed
 3) Does this happen without wrapping (i.e., when you have it disabled)?
    - I can't tell
 4) Does it go away when you change the wrapping mode?
    - I can't tell
 5) Does it go away when you change the editor font/font size?
    - I can't tell
 6) Does it go away/change when you restart Tw (i.e., close, then reopen the same document at the same place)?
    - Disabling and re-enabling line numbers already solved it in my case, so I can't tell.

If it happens again, i'll report it here.

Original comment by [email protected] on 16 Apr 2011 at 10:31

@GoogleCodeExporter
Copy link
Author

Happens every time when I open a big file (~2000 lines).
 1) Does this happen on short documents as well (say, less than 1000 lines, or less than 100 lines)?
  - No, it seems.
 2) Does this happen on short, non-empty lines (where no wrapping kicks in)
  - Not sure. I think, yes.
 3) Does this happen without wrapping (i.e., when you have it disabled)?
  - Yes, I have wrapping disabled.
 4) Does it go away when you change the wrapping mode?
 5) Does it go away when you change the editor font/font size?
 6) Does it go away/change when you restart Tw (i.e., close, then reopen the same document at the same place)?
  - Changing "Line Numbers" helps, haven't tried other ways.

Original comment by [email protected] on 13 May 2011 at 10:26

@GoogleCodeExporter
Copy link
Author

Me I've been hit by the same problem, on Windows 7 with MikTeX 2.9!

Original comment by [email protected] on 2 Jun 2011 at 8:03

@GoogleCodeExporter
Copy link
Author

Following the example file in issue 505, I've been able to reproduce this and 
(hopefully) fix it in r837. Until I can produce new builds, could you verify 
that this is caused by the babelHook.js script (you can disable it via Scripts 
> Scripting TeXworks > Manage Scripts > Hook Scripts > Babel Language)

Original comment by st.loeffler on 10 Jun 2011 at 11:35

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

> could you verify that this is caused by the babelHook.js script

Confirm. Windows XP 32-bit, TeXworks version 0.4.0.r759.

Turning off babelHook.js results in correct line numbers (not overlapped).
After turning it back on the line numbers become once again mangled.

Original comment by [email protected] on 10 Jun 2011 at 12:14

@GoogleCodeExporter
Copy link
Author

It seems r837 didn't quite cut it. Apparently, the underlying issue is some 
kind of race condition between different parts of the code changing the editor 
size and markup, so what seems to work on one machine doesn't necessarily work 
on all others.

Up to r843, I tried to defer all changes to a time when they (hopefully) don't 
produce problems. Please test.

Original comment by st.loeffler on 11 Jun 2011 at 3:14

  • Removed labels: OpSys-Windows

@GoogleCodeExporter
Copy link
Author

r843 didn't fix this problem completely, unfortunately. In r845, I took another 
approach, please test.

Original comment by st.loeffler on 21 Jun 2011 at 6:02

@GoogleCodeExporter
Copy link
Author

r858 still has this problem on Win xp 32bit!

Original comment by [email protected] on 6 Sep 2011 at 7:45

@GoogleCodeExporter
Copy link
Author

Same problem here.. r858 and also the beta seems to have the same problem.

Windows 7 x64

Original comment by [email protected] on 24 Jan 2012 at 2:05

@GoogleCodeExporter
Copy link
Author

And yet another attempt to resolve this issue in r958. I hope this finally 
settles this issue - please test.

Original comment by st.loeffler on 27 Feb 2012 at 9:08

@GoogleCodeExporter
Copy link
Author

Issue 558 has been merged into this issue.

Original comment by st.loeffler on 3 Apr 2012 at 12:38

@GoogleCodeExporter
Copy link
Author

I experience the same problem on TeXworks bundled with MiKTeX 2.9.4535 (it 
seems to be the latest version available for MiKTeX).

It seems as if the problem is in some way related to the content of the file. I 
was editing my thesis for a long time and did not experience it; then, some 
day, it appeared (I did not change the preamble, only the text itself), and 
persisted even between TeXworks restarts and after removing all the service 
files like .synctex.gz etc.
Currently I'm experiencing the problem even on a short (<1000 lines) files; 
though it is possible that the file contents only matters when the problem 
arises for a first time (back then, it was >1000 lines long).

What makes it all worse is something that original reporter did not mention: 
TeXworks crashes reporting an error in QtGui4.dll if user sets cursor to the 
line with the "mangled" numbers.

The number seems to "mangle" only for the empty lines (that is, it appears as 
if there was no empty line, and its number is "mangled" with the number of the 
following non-empty line).

Disabling the babel script seemed to fix the problem.

Original comment by [email protected] on 12 Jun 2013 at 3:34

stloeffler added a commit that referenced this issue Apr 16, 2017
NonblockingSyntaxHighlighter is a reimplementation (and replacement) of
QSyntaxHighlighter, with the aim of keeping the UI responsive even
during lengthy highlighting tasks (e.g., long documents). It achieves
this goal by queuing highlighting tasks and executing them for a certain
time (a few milliseconds) before returning control to the main event loop
for processing other events. Once the other events are processed, the
highlighter resumes its work for a few milliseconds and so on until the
whole documented is highlighted.

Inspired by http://enki-editor.org/2014/08/22/Syntax_highlighting.html
@stloeffler
Copy link
Member

This Qt bug should hopefully be fixed in Qt 5.15.1...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants