Closed oOosys closed 11 months ago
The crash is caused by view.wrap_count(line_no)
call when given too large line_no
. The original reason for this is that in wrapping mode active_view.first_visible_line
does not report the line number seen as line number in the line numbering margin, but some other value which is much higher and changes when scrolling one line at a time by values like for example 10 or 15 at a time.
In other words the crash occurs because view.first_visible_line
does not report the actual first visible line number seen in the line numbering margin with switched on line wrapping.
Is it a bug or a feature that view.first_visible_line
does not provide the right line number if wrapping is switched on? How to detect if wrapping is active from within Lua code in user init.lua
?
I haven't looked at your code, but my first instinct is that you need to call view:doc_line_from_visible(view.first_visible_line)
to get the actual document/buffer line number from the one displayed/visible. This is a feature of Scintilla, not a bug.
OK ... So view.first_visible_line
gives a line number which is the result of counting lines as they would appear in the view on screen. i.e. If an actual document line N (counted by newlines in the file of the loaded viewed text if the text was not yet changed) is wrapped into five lines, navigating to the last of these lines will give view.first_visible_line==N+4
where view:doc_line_from_visible(view.first_visible_line)==N
will still give the in the line numbering margin shown line number N.
In other words, switching line wrapping ON results in converting the entire viewed buffer text into wrapped text, not only the part which is visible in the view, right? So wrapping lines in case of very large documents will result in making the CPU busy with recalculating all the line numbers in the entire document and should be avoided as not practicable, right?
Further in other words, if I want wrapping of long lines in texts with a huge amount of long lines I need to implement it on my own and take full control of what is displayed in the view, no matter the actual content of the viewed text, right?
Your understanding is correct. I doubt you can "tak[e] full control of what is displayed in the view" though. Scintilla (via GUI widget) has its own way of displaying/laying out text that Textadept does not interfere with.
Thanks for the hint towards view:doc_line_from_visible(view.first_visible_line)
. This is a perfect starting point for "print()-based" debugging and understanding what is going on with the side-effect of solving the problem which was the reason for opening this issue. That the application shouldn't crash given a wrong value for a line number is another topic I am currently not ready to cope with.
Assertion [line < model.pdoc->LinesTotal()] failed at .../build/_deps/scintilla-src/src/EditView.cxx 402 Aborted (core dumped)
Where is the core dumped?
This crash started to occur after implementation of "follow mode" in the local user "init.lua" file while trying to fix the issue with wrong values for line numbers shown in the view. Only querying of values was done to get some insight about line numbering because of weird results of adjusting the scrolling of another view showing same buffer. I can't query the values of insight about is not possible because of the crash.
My system: Linux Mint 21.2 Xfce, GTK-version.
Below some more context.
The output in the Terminal window from which the editor was started:
Here the code in init.lua which is maybe the reason for the crash which occurs when there are two views showing the same buffer and in one of them Ctrl+\ is used to switch to wrapping mode to see what happens to the reported and calculated line numbers: