editor window not always showing all of file [$40 awarded]

[achiestdragon]

sometimes , when editing large files the editor fails to display all the file as if its cut short
resizing the editor window usually corrects this

---

The $40 bounty on this issue has been claimed at Bountysource.

[kintel]

I've noticed the same on Mac. Which OS are you using?

[achiestdragon]

suse12.3 , but have seen the same bug on winxp, and win7 , on 2013.01

I don't think its a qt problem as I don't get the same problem with other qt apps

[donbright]

is this a regression that wasnt in 2013.01? ive never seen this before.

[achiestdragon]

its been there some time , I remember encountering it some time back on
winxp ether on 2001.01 or 2013.05 snapshot when i was starting to use
openscad on a quite large file from thingiverse

still have not pinpointed the action that causes it but getting closer :)

On Sat, Jun 15, 2013 at 6:55 PM, donbright notifications@github.com wrote:

is this a regression that wasnt in 2013.01? ive never seen this before.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/406#issuecomment-19500533
.

[achiestdragon]

well not been able to find the action that causes it every time , as in it seems to be somewhat intermittent although could be related to https://bugreports.qt-project.org/browse/QTBUG-16880 as it appears to happen only after switching to another app and back or resizing

[donbright]

got any sceenshots?

[achiestdragon]

its not on screen missing , more like its only showing and letting you edit and scroll about the first 100lines of the file, as if the file got shortened , until you resize the edit window again then it behaves as it should

first image "snapshot2.jpg" showing where it thinks end of file is when it happens ,, note size of scroll bar ,, and it wont let it scroll passed ,, 2nd "snapshot3.jpg" image after adjusting size of window its back to how it should be

[achiestdragon]

wrong button

[ivoknutsel]

I have seen this as well on windows 64 2013.06

[DiMilan]

I just closed #489 because it's (probably) addressing the same issue.

Saving a larger file automatically results in the file getting cut somewhere in half and the second half won't be displayed anymore. The cursor then jumps back to line 1. The second half doesn't get lost and the file is nog changed. On close and re-open the code looks perfect again.

[rvansa]

I experience this with 2013.06 on Fedora 17 as well

[Zenmaster43]

I've experienced this bug on both windows and OS X 2013.06 versions. The bug appears to be fully cross-platform, and thus in the platform independent part of the code.

Simply saving the file triggers the effect. (Of course, saving is only enabled when you've made a change to the text of the file.)

Recovery is triggered intermittently by resizing the window.

Partial recovery also occurs by typing a character and deleting it, resulting in a few more lines being displayed in the editor each time.

I really want this fixed a.s.a.p., since most of my files are long and I don't like having to break them down into shorter files just because of this bug, or having to screw around to get to see the text every time I save it.

Also, if it would simply not jump to the top of the file when I save it, that would be very helpful as well.

If it weren't for my full schedule, I'd dig in and fix it myself. Whoever does fix it will have my full appreciation.

[DiMilan]

Sorry Zenmaster43, I don't want to be that guy but you "really want this fixed a.s.ap."? I wouldn't even demand a fix for paid software. Openscad is a great program written by people that probably put all their free time in it and still do so by helping the community out on a daily base on different forums.

[Zenmaster43]

No disrespect intended folks. No demand was indicated. I only intended to indicate my desire. I figure this one has been a problem for many other users though, for at least several months now, and something as basic as a text editor should be pretty simple to fix, don't you think?

On the other hand, I would make a much stronger effort to get this fundamental issue resolved if it were commercial software, since it would probably involve significant cost in loss of business productivity.

As a conscientious software developer myself, I wouldn't leave such a simple text editor semi-functional any longer than absolutely necessary, regardless of its open-source or proprietary status.

Having worked for several software houses, I can tell you from experience that allowing such a fundamental flaw to be included in a public release would easily be grounds for getting fired, were this commercial software. Whoever wrote the code is lucky that's not an issue.

Personally, I hold the quality control of my own freeware code to the same standard as my commercial software and hope others see the wisdom of doing the same.

I only hope

Sent from my iPhone

On Dec 26, 2013, at 11:20 PM, Westmd notifications@github.com wrote:

Sorry Zenmaster43, I don't want to be that guy but you "really want this fixed a.s.ap."? I wouldn't even demand a fix for paid software. Openscad is a great program written by people that probably put all their free time in it and still do so by helping the community out on a daily base on different forums.

�
Reply to this email directly or view it on GitHub.

[kintel]

The "not jump to the top of the file when I save it" should have been fixed in #553.

The OpenSCAD editor has lots of room for improvement. One idea is to look at QtScintilla (http://pyqt.sourceforge.net/Docs/QScintilla2) for possible integration.

Personally, I tend to use an external editor and I haven't prioritized spending time on the internal one, but patches are welcome. Sometimes it also helps adding bounties to issues to motivate developers to take a look at it.

[MichaelAtOz]

@Zenmaster43 you can always use an external editor such as Notepad++, you can get autocomplete & syntax highlighting bits for it on Thingiverse. Works really well.

[Zenmaster43]

Is there a way of setting up a sort of bounty pot for contributions from users, to be awarded to whoever's solution is deemed by those users to be acceptable? Since any individual might not be able or willing to fund the entire effort to resolve a particular issue, but collectively, a few dollars per user could add up to a significant bounty, this would seem to be a helpful way to move things ahead that might otherwise remain log-jammed for ages.

Sent from my iPhone

On Dec 27, 2013, at 10:16 AM, Marius Kintel notifications@github.com wrote:

The "not jump to the top of the file when I save it" should have been fixed in #553.

The OpenSCAD editor has lots of room for improvement. One idea is to look at QtScintilla (http://pyqt.sourceforge.net/Docs/QScintilla2) for possible integration.

Personally, I tend to use an external editor and I haven't prioritized spending time on the internal one, but patches are welcome. Sometimes it also helps adding bounties to issues to motivate developers to take a look at it.

�
Reply to this email directly or view it on GitHub.

[Zenmaster43]

The application's object rendering is good, but that makes such a fundamental flaw as this text editing problem all the more worrisome. Advice to use an external editor is well taken, but still seems a bit cumbersome, compared to a properly functioning built-in editor.

[Zenmaster43]

MichaelAtOz, is there one that works with OpenSCad on MacOS X?

[MichaelAtOz]

I'm new to linux/BSD (hence OSX), but there is
TextWrangler
For those Linux users. Adds syntax highlighting for OpenSCAD files in the kate (and thus kwrite, among others) editors
Can't comment on suitability.
I believe there are OSX users here who may recommend more than I can.

[kintel]

@Zenmaster43 Take a look at BountySource: https://www.bountysource.com/issues/416601-editor-window-not-always-showing-all-of-file?utm_campaign=plugin&utm_content=tracker%2F52063&utm_medium=issues&utm_source=github

I haven't used it with more than one backer, but AFAIU, there is support for that. Nevertheless, it's easier to split up a request into several smaller, well-defined, issues.

[MichaelAtOz]

I found SciTE which I knew had syntax highlighting and autocomplete, and found someone had done the OpenSCAD bits, so you could grab the OpenSCAD.xml files and use it on OSX, but then found SciTE for OSX was not free, like it is for Win/Linux; I don't know why.
p.s. I'll try to remember putting this stuff on the wiki.

[Zenmaster43]

Thanks for the info. I'll look into it.

Being a long-time Mac user, I've often had to deal with that inequality that hits the pocketbook pretty hard at times.

I guess some folks think that if we can afford a Mac, we can also spend more $$$ to get the same application features that are available for much less or even free on Windows or Linux.
(The excuse I heard in earlier years was that it takes extra effort because the software was developed on windows before the Mac version. With today's more modern development environments, that excuse should have evaporated years ago.)

My reality is often the opposite, in that having spent more for the computer, I have less remaining for software purchases and thus I have to rely more on freeware and low-cost shareware.

Sent from my iPhone

On Dec 28, 2013, at 12:15 PM, Michael notifications@github.com wrote:

I found SciTE which I knew had syntax highlighting and autocomplete, and found someone had done the OpenSCAD bits, so you could grab the OpenSCAD.xml files and use it on OSX, but then found SciTE for OSX was not free, like it is for Win/Linux; I don't know why.
p.s. I'll try to remember putting this stuff on the wiki.

�
Reply to this email directly or view it on GitHub.

[Zenmaster43]

Thanks for the info. I have used TextWrangler in the past, so it's good to learn that it works with OpenSCad. I'll give it a try. I'm still a little concerned though that using any external text editor may add steps to the OpenSCad design cycle.
Until the bug is fixed, though, it may temporarily be an improvement.

Sent from my iPhone

On Dec 28, 2013, at 3:24 AM, Michael notifications@github.com wrote:

I'm new to linux/BSD (hence OSX), but there is
TextWrangler
For those Linux users. Adds syntax highlighting for OpenSCAD files in the kate (and thus kwrite, among others) editors
Can't comment on suitability.
I believe there are OSX users here who may recommend more than I can.

�
Reply to this email directly or view it on GitHub.

[kintel]

I reduced this down to being related to highlighter->unhighlightLastError(); and highlighter->highlightError( parser_error_pos ); in MainWindow::compileTopLevelDocument().

Could perhaps be that QTextBlock instances don't survive a setPlainText() call?
Needs some fresh eyes..

[ec1oud]

I think it would be worth a try to swap out the buggy editor for http://pyqt.sourceforge.net/Docs/QScintilla2/

[kintel]

@ec1oud I agree

[laird]

@ec1oud @kintel I agree, and added a bit to the bounty. :-)

[kintel]

PS. This issue is meant as a stability bugfix which can be released immediately (as this issue is a blocker making a new release); that's what the bounty was meant for at least. Implementing a new editor based on Scintilla should be a separate, new issue.

[laird]

OK. Well, I guess I'd still be $10 happier not having most of the file randomly disappear. :-)

And when there's a "integrate a new editor" issue, I guess I'll kick in again. I've got way too many projects going to do this myself (too busy using OpenSCAD...) but I'm happy to encourage someone else to do this. :-)

[nophead]

I think the bug only happens if you have "automatic reload and compile"
enabled, which is not necessary when using the internal editor.

On 12 February 2014 22:13, Laird Popkin notifications@github.com wrote:

OK. Well, I guess I'd still be $10 happier not having most of the file
randomly disappear. :-)

And when there's a "integrate a new editor" issue, I guess I'll kick in
again. I've got way too many projects going to do this myself (too busy
using OpenSCAD...) but I'm happy to encourage someone else to do this. :-)

Reply to this email directly or view it on GitHubhttps://github.com//issues/406#issuecomment-34924636
.

[laird]

That's consistent with what I see. I always have that enabled, since (aside
from this bug) it's harmless when using the internal editor and essential
when using an external editor.

• Laird Popkin

Sent from my iPhone. Apologies in advance for typo's.

On Feb 12, 2014, at 7:28 PM, Chris notifications@github.com wrote:

I think the bug only happens if you have "automatic reload and compile"
enabled, which is not necessary when using the internal editor.

On 12 February 2014 22:13, Laird Popkin notifications@github.com wrote:

OK. Well, I guess I'd still be $10 happier not having most of the file
randomly disappear. :-)

And when there's a "integrate a new editor" issue, I guess I'll kick in
again. I've got way too many projects going to do this myself (too busy
using OpenSCAD...) but I'm happy to encourage someone else to do this. :-)

Reply to this email directly or view it on GitHub<
https://github.com/openscad/openscad/issues/406#issuecomment-34924636>
.

Reply to this email directly or view it on
GitHubhttps://github.com//issues/406#issuecomment-34935688
.

[t-paul]

Oh, i guess in that case the test case is to write the file very slowly. It's probably finding the file modification time changed and triggers a reload before the external editor finished writing it.
Sounds like OpenSCAD needs to wait a bit and only trigger a reload if the file content did not change between two checks.

[t-paul]

Running the script from https://gist.github.com/t-paul/9024903 I can reproduce the error in highlighter->unhighlightLastError(); pretty much instantly (like after 10 or 20 refreshes). Using highlighter->rehighlight(); to force a full rehighlight does not seem to have problems.

But if that happens, OpenSCAD completely crashes, so I'm not sure if that is the same thing as the truncated file case. Unfortunately I can't yet reproduce that problem with the script. Could that have something to do with the effect where a compile error does not release the GUI lock?

[kintel]

The compile error gui lock issue was fixed recently, but that only affected F6 compiles I think.

[kintel]

I can reproduce this every time I try on Mac with this file: https://gist.github.com/kintel/9045497
To reproduce:

• Make sure Automatic reload is turned on
• Open the file
• On the first line, enter and delete a space (to change the document)
• Save
  -> the content after save & auto-reload ends after echo("G");

Some notes:

• Commenting out highlighter->unhighlightLastError(); in mainwin.cc makes the problem go away.
• Debugging shows that the entire file is indeed read before calling that method)
• When the file is partially shown, the issue goes away when horizontally resizing the window (just vertical resizing doesn't help)
• Changing Highlighter::portable_rehighlightBlock() so that rehighlight() is called instead of rehighlightBlock() also fixes the issue

[kintel]

@t-paul As you can see, this is a pure GUI rendering issue. This doesn't affect openscad compilation at all, since the whole file is available for the parser. That crash you mentioned is likely to be totally independent from this. If you can reproduce it with a stack trace it would be cool. I didn't manage to reproduce it using your script (might be since I had to slim it down a bit to make it work on Mac).

[laird]

As an added data point confirmation, the behavior that I'm seeing is
consistent with this email thread, on both Mac OS 10.9.1 and Windows 8.1.

That is:

• The display of the file is incomplete (and I can't move the cursor into
  the newly blank error)
• Resizing horizontally refreshes the text
• Saving the file saves a complete copy
• Compiling and rendering operate on the complete file
• Turning off 'auto update' appears to fix the problem.

I've seen this now with pretty much every file I've been editing.

On Mon, Feb 17, 2014 at 2:34 PM, Marius Kintel notifications@github.comwrote:

@t-paul https://github.com/t-paul As you can see, this is a pure GUI
rendering issue. This doesn't affect openscad compilation at all, since the
whole file is available for the parser. That crash you mentioned is likely
to be totally independent from this. If you can reproduce it with a stack
trace it would be cool. I didn't manage to reproduce it using your script
(might be since I had to slim it down a bit to make it work on Mac).

Reply to this email directly or view it on GitHubhttps://github.com//issues/406#issuecomment-35315570
.

Laird Popkin | Executive Director, Architecture
KAPLAN TECHNOLOGY
Kaplan, Inc. | 6301 Kaplan University Avenue, Fort Lauderdale, FL 33309
tel +1 954 515 4509 | email laird.popkin@kaplan.com

[t-paul]

Looks like it crashes only with the console window closed. With open console window the debug output seems to change the timing in a way the crash does not happen (or at least not so often).

Stacktrace:

#0  0x00007ffff580b51a in QTextBlock::position() const () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#1  0x00007ffff5847ce5 in QTextCursor::QTextCursor(QTextBlock const&) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#2  0x00007ffff585fd85 in QSyntaxHighlighter::rehighlightBlock(QTextBlock const&) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#3  0x000000000051d533 in Highlighter::portable_rehighlightBlock (this=0x111d350, block=...) at src/highlighter.cc:271
#4  0x000000000051d50d in Highlighter::unhighlightLastError (this=0x111d350) at src/highlighter.cc:265
#5  0x0000000000639de2 in MainWindow::compileTopLevelDocument (this=0xff61f0) at src/mainwin.cc:1321
#6  0x0000000000634553 in MainWindow::compile (this=0xff61f0, reload=true, forcedone=false) at src/mainwin.cc:673
#7  0x000000000063a269 in MainWindow::actionReloadRenderCSG (this=0xff61f0) at src/mainwin.cc:1376
#8  0x0000000000639ff3 in MainWindow::checkAutoReload (this=0xff61f0) at src/mainwin.cc:1334
#9  0x00000000008db70f in MainWindow::qt_static_metacall (_o=0xff61f0, _c=QMetaObject::InvokeMetaMethod, _id=81, _a=0x7fffffffd170) at objects/moc_MainWindow.cpp:253
#10 0x00007ffff508d658 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#11 0x00007ffff5091811 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#12 0x00007ffff55a96cc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x00007ffff55afd40 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#14 0x00007ffff50793cd in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#15 0x00007ffff50a90e3 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x00007ffff50a6419 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#17 0x00007ffff63d0ea6 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff63d11f8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff63d129c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007ffff50a6615 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#21 0x00007ffff5647776 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#22 0x00007ffff5077f9f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#23 0x00007ffff5078295 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#24 0x00007ffff507da69 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#25 0x000000000061d3a9 in gui (inputFiles=..., original_path=..., argc=2, argv=0x7fffffffe3e8) at src/openscad.cc:553
#26 0x000000000061ecd6 in main (argc=2, argv=0x7fffffffe3e8) at src/openscad.cc:700

[kintel]

New Mac binaries with the suggested fix from Don is now online. Works for me. Anyone else want to give it a spin?

[t-paul]

Looking good on Debian. The test script is running for some time now without any crashes.

[kintel]

Fixed by #662

[donbright]

re: QScintilla

everytime we add a dependency, god kills a kitten.

think of the kittens.

[t-paul]

Oh, nooooo. The text() feature will be a cat massacre then...