#2349 some lines appear twice

[Rudolph]

Conditions in Geany

• no line numbers are shown on the left side
• long lines are wrapped

Steps to reproduce
1: open Geany
2: open two different txt-documents, both very long, so that only two tabs exist
3: close Geany
4: reopen Geany (result: the txt-document what is in focus is shown correctly)
5: switch to the other tab where the other txt-document is located

Result
The problem is that this happens not often, and one need to scroll to look for double lines (I did all the steps above about 20 times and during the 20 times I switched sometimes to Firefox to surfed around):
The txt-document is not shown correctly. Some lines of the document are shown twice. What is also strange is that the cursor is stretched over two lines. Once I saw multiple lines, I think it was 4x. Here two examples:
https://github.com/geany/geany/issues/3271
https://github.com/xiota/geany/issues/2#issuecomment-1226190192

Remark
I thought that it was caused by the plugin Geany Preview or by using Geany 1.39 by PPA (https://github.com/xiota/geany/issues/2 and https://github.com/xiota/geany/issues/3). But yesterday I reinstalled Lubuntu 22.04, I installed Geany 1.38 (not the PPA-version), I installed geany-plugins (without activating a plugin), I installed some software for kvantum for having the dark mode, and I used Sleepy Pastel as colorschemes in Geany. And then the issue was there again. I can't remember that I saw this issue in Geany 1.37.
The issue disappears when during the Geany session View>Show Line Numbers will be activated in the menu. By deactivating it again, the issue does not appear any more in the Geany session. Same for wrapped lines: In the moment where long lines are not wrapped any more, the issue disappears. By activating wrapped lines again in the menu, the issue does not appear any more in the Geany session. The issue occurs in documents with txt-format and html-format, but maybe also in other formats. The issue appears in some lines: If a line is not wrapped, or the last line of wrapped lines. Maybe those hints can help to figure out where the problem is. When I was using Geany 1.39 by PPA with the plugin Geany Preview and two lua-scripts, I could reproduce the steps from above (Steps to reproduce) every time. I don't know how to install Geany git version or latest Scite for making tests.

[Neil Hodgson]

I have seen this rarely. A possibility is that buffered drawing is on and that an error in the drawing code causes return to the by-line loop without any new drawing into the buffer bitmap. Then the previous line's image is drawn onto the new line. You could turn off buffered drawing (SCI_SETBUFFEREDDRAW) if it is on to check this - I don't know if Geany supports changing this setting.

Another possibility is that there is a bug in the line wrap positions so that the same subline is present twice.

[Rudolph]

Another possibility is that there is a bug in the line wrap positions so that the same subline is present twice.

And how should it be determined if it is a bug or not?

[Neil Hodgson]

Run the application inside a debugger. When the problem occurs, break into the debugger and examine the state of the line wrap positions.

[Rudolph]

In the editor FeatherPad I replaced in src/editor.c this code

#ifdef GDK_WINDOWING_QUARTZ
# if ! GTK_CHECK_VERSION(3,16,0)
    /* "retina" (HiDPI) display support on OS X - requires disabling buffered draw

     * on older GTK versions */
    SSM(sci, SCI_SETBUFFEREDDRAW, 0, 0);
# endif
#endif

by this code:

/*#ifdef GDK_WINDOWING_QUARTZ*/
/*# if ! GTK_CHECK_VERSION(3,16,0)*/
    /* "retina" (HiDPI) display support on OS X - requires disabling buffered draw

     * on older GTK versions */
    SSM(sci, SCI_SETBUFFEREDDRAW, 0, 0);
/*# endif*/
/*#endif*/

Then I saved the document. I closed the document in the editor.

In the terminal I did:

cd geany_build
cd geany_git
make install
cd ../bin
./geany -c ../config

The issue is not there any more.

[Neil Hodgson]

A check could be added to LineLayout::AddLineStart to see if the line starts are unexpected:

diff -r a3968947bfde src/PositionCache.cxx
@@ -8,6 +8,7 @@
 #include <cstddef>
 #include <cstdlib>
 #include <cstdint>
+#include <cassert>
 #include <cstring>
 #include <cmath>

@@ -203,6 +204,12 @@
        lenLineStarts = newMaxLines;
    }
    lineStarts[lines] = static_cast<int>(start);
+

+   // Check line starts:
+   assert(lineStarts[0] == 0);
+   for (int li = 1; li <= lines; li++) {
+       assert(lineStarts[li] > lineStarts[li - 1]);
+   }
 }

 void LineLayout::SetBracesHighlight(Range rangeLine, const Sci::Position braces[],

The change should abort with a message if there is a problem. This patch is based on current Scintilla and Geany may be using an old version that doesn't have AddLineStart but there'll be some similar code that adds line starts.

[Neil Hodgson]

Another possibility is that there is a difference with the number of screen lines for a document line between the LineLayout object for the line and the ContractionState for that line. These could be unsynchronized if background wrapping code isn't run.

It may be possible to check for this with this assertion.

diff -r 6a4bc01227bd src/EditView.cxx
@@ -2549,6 +2549,7 @@
                    ll = RetrieveLineLayout(lineDoc, model);
                    LayoutLine(model, surface, vsDraw, ll.get(), model.wrapWidth);
                    lineDocPrevious = lineDoc;

+                   assert(ll->lines == model.pcs->GetHeight(lineDoc));
                }
 #if defined(TIME_PAINTING)
                durLayout += ep.Duration(true);

[Rudolph]

To your last two posts:

I'm not a software developer, I'm just a software user. I can just program simple HTML-code. I have no idea how to install or use a debugger. But I already asked for help ( https://github.com/geany/geany/issues/3271#issuecomment-1237248610 ).

[Rudolph]

First I would like to mention this:

When buffered drawing is turned off, then the issue is not there any more, but then there are two disadvantages:

1. there is an empty line where I can't even place the cursor (between 15 and 16)
2. if I navigate on the keyboard with the key arrow-down from line 13 to 16, the cursor will stop at line 15 at the end of the line; even if I press again many times the key arrow-down, the cursor will not move (but navigating with the key arrow-up from line 17 to line 13, then there are no problems; the cursor will just jump over the empty line)

The disadvantages occur only if an other tab with a txt-document is right away in focus after a restart of Geany. In other words: If the tab of the corresponding txt-document is right away in focus after a restart of Geany, then there are no disadvantages.

The disadvantages occur only if "Line Wrapping" is activated. By deactivating and reactivating the disadvantages disappear.

I think that all the problems are because the line stops at the right border.

[Neil Hodgson]

I think that all the problems are because the line stops at the right border.

If this is the case for all occurrences then it is a significant clue.

[Rudolph]

Before I turned off buffered drawing, here a picture of the issue with the stretched cursor over two lines.

[Rudolph]

A check could be added to LineLayout::AddLineStart to see if the line starts are unexpected:

In which document should I look for it? Or is a debugger necessary?

[Neil Hodgson]

In which document should I look for it?

scintilla/src/PositionCache.cxx

Run the application from a command prompt and the assertion message should show there when the failure occurs. Running inside a debugger helps examine the context and possibly continue from the assertion.

[Neil Hodgson]

For someone that isn't a software developer the priority should be finding a 100% reproducible case that shows the bug. If I can't make the bug happen then its very unlikely I can work out why it is occurring then fix it. If a reproducible case can't be found then evidence about the conditions under which the bug occurs can help others investigate the bug.

From a command prompt, an assertion failure looks like this running SciTE (I use SciTE, so am am set up to build and run it):

$ scite/bin/SciTE
SciTE: ./../src/PositionCache.cxx:210: void Scintilla::Internal::LineLayout::AddLineStart(Sci::Position): Assertion `lineStarts[li] < lineStarts[li - 1]' failed.
Aborted (core dumped)

The above had the assertion added but with the check inverted to provoke a failure to illustrate.

Running inside the common gdb debugger where run then back trace bt are the most commonly useful things to do:

$ gdb scite/bin/SciTE
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
## ... eliding messages from gdb

(gdb) run

Starting program: /home/neil/merc/scite/bin/SciTE 
## eliding uninteresting messages that contain "thread"
[Thread 0x7fffd6334640 (LWP 3354) exited]
SciTE: ./../src/PositionCache.cxx:210: void Scintilla::Internal::LineLayout::AddLineStart(Sci::Position): Assertion `lineStarts[li] < lineStarts[li - 1]' failed.

Thread 1 "SciTE" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737313675904) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.

(gdb) bt

#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737313675904) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140737313675904) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140737313675904, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff69a1476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff69877f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff698771b in __assert_fail_base (fmt=0x7ffff6b3c150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff7035e78 "lineStarts[li] < lineStarts[li - 1]", file=0x7ffff7035e4a "./../src/PositionCache.cxx", line=210, function=<optimised out>)
    at ./assert/assert.c:92
#6  0x00007ffff6998e96 in __GI___assert_fail (assertion=0x7ffff7035e78 "lineStarts[li] < lineStarts[li - 1]", file=0x7ffff7035e4a "./../src/PositionCache.cxx", line=210, function=0x7ffff7035e08 "void Scintilla::Internal::LineLayout::AddLineStart(Sci::Position)")
    at ./assert/assert.c:101
## stack above here is just the assertion failing but below is the context
#7  0x00007ffff6fd5900 in Scintilla::Internal::LineLayout::AddLineStart(long) (this=0x5555560c2350, start=81) at ./../src/PositionCache.cxx:210
#8  0x00007ffff6fa1f09 in Scintilla::Internal::EditView::LayoutLine(Scintilla::Internal::EditModel const&, Scintilla::Internal::Surface*, Scintilla::Internal::ViewStyle const&, Scintilla::Internal::LineLayout*, int)
     (this=0x555555d68690, model=..., surface=0x5555560c2b20, vstyle=..., ll=0x5555560c2350, width=618) at ./../src/EditView.cxx:690
#9  0x00007ffff6f70e93 in Scintilla::Internal::Editor::WrapOneLine(Scintilla::Internal::Surface*, long) (this=0x555555d68000, surface=0x5555560c2b20, lineToWrap=2) at ./../src/Editor.cxx:1503
#10 0x00007ffff6f7171e in Scintilla::Internal::Editor::WrapLines(Scintilla::Internal::Editor::WrapScope) (this=0x555555d68000, ws=Scintilla::Internal::Editor::WrapScope::wsVisible) at ./../src/Editor.cxx:1596
#11 0x00007ffff6f725a2 in Scintilla::Internal::Editor::Paint(Scintilla::Internal::Surface*, Scintilla::Internal::PRectangle) (this=0x555555d68000, surfaceWindow=0x555555835270, rcArea=...) at ./../src/Editor.cxx:1770
#12 0x00007ffff7020fc4 in Scintilla::Internal::ScintillaGTK::DrawTextThis(_cairo*) (this=0x555555d68000, cr=0x555556069400) at ScintillaGTK.cxx:2700
#13 0x00007ffff70210fb in Scintilla::Internal::ScintillaGTK::DrawText(_GtkWidget*, _cairo*, Scintilla::Internal::ScintillaGTK*) (cr=0x555556069400, sciThis=0x555555d68000) at ScintillaGTK.cxx:2722
#14 0x00007ffff7b66eb8 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#15 0x00007ffff7b100e1 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#16 0x00007ffff7478640 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff74787a3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff7b1fd82 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#19 0x00007ffff7900825 in gtk_container_propagate_draw () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x00007ffff7021380 in Scintilla::Internal::ScintillaGTK::DrawThis(_cairo*) (this=0x555555d68000, cr=0x555556069400) at ScintillaGTK.cxx:2755
#21 0x00007ffff70213fd in Scintilla::Internal::ScintillaGTK::DrawMain(_GtkWidget*, _cairo*) (widget=0x555555d67130, cr=0x555556069400) at ScintillaGTK.cxx:2767
## there are 30 more lines that are internal to GTK so uninteresting
(gdb) 

[Rudolph]

For someone that isn't a software developer the priority should be finding a 100% reproducible case that shows the bug. If I can't make the bug happen then its very unlikely I can work out why it is occurring then fix it.

The bug occurs at the moment on a 22-inch-FHD-display. I could try to reproduce it on a 15.6-inch-FHD-notebook on Lubuntu-Live-ISO with Geany installed by PPA (that uses geany-git from last Sunday), with two txt-documents. I could then upload the two txt-documents so that you could see the bug and work on it. What you think about that and do you have a 15.6-inch-FHD-notebook (I could try maybe on 11-inch-FHD-notebook)? Or do you have an other suggestion?

[Neil Hodgson]

I only use Linux in a virtual machine through VirtualBox on Windows, so hardware form factor won't match.

You should upload the text documents that have shown the effect as there could be something unusual about them.

[Rudolph]

I only use Linux in a virtual machine through VirtualBox on Windows, so hardware form factor won't match.

Why running Lubuntu-Live-ISO with Geany installed by PPA (that uses geany-git from last Sunday) is not possible?

I don't think that you will see the bug, but who knows. Just follow the description. Please tell me if you see the bug.

[Neil Hodgson]

scintilla_bug.txt appears to be a recipe for producing the actual file. Just upload the actual file.

[Neil Hodgson]

Lubuntu 22.04 as mentioned above, does not seem to have a simple download link from https://lubuntu.net/ which mentions various 19.x versions.

"Geany installed by PPA" is unclear: provide shell commands to do this.

[Rudolph]

Lubuntu 22.04 as mentioned above, does not seem to have a simple download link from https://lubuntu.net/ which mentions various 19.x versions.

If you go on en.wikipedia.org and type Lubuntu, then the answer will be lubuntu.me as webpage and not lubuntu.net.

[Rudolph]

"Geany installed by PPA" is unclear: provide shell commands to do this.

I would give a very clear step-by-step-description. But I think that the bug depends on the display-size and the resolution: For testing your display must be Full HD.

Is your display Full HD?
Which kind of display-size (in inch) do you use for testing (examples: 11´´ or 15.6´´ or 22´´ or 24´´) (the best for me would be 22´´ or second best 15.6)?

Please answer both questions and then I will try to reproduce the issue on Lubuntu ISO on a computer with the corresponding display size.

[Rudolph]

[Rudolph]

The issue exists already in Geany 1.38. Is that OK for you if I try to reproduce the issue in live ISO Lubuntu 22.04 in Geany 1.38 or you prefer the Geany nightly tarball by PPA from last Sunday?
Geany 1.38 would be easier because it is only the command sudo apt install geany.

[Rudolph]

step-by-step-description how to see the bug

1: run the ISO of Lubuntu 22.04.1 from lubuntu.me
2: open Main menu, System Tools, Qterminal
3: sudo apt install geany
4: open Geany by terminal: geany
5: maximize the Geany-window
6: open the two txt-documents scintilla_restart.txt and scintilla_bug_long.txt
7: follow the instructions of scintilla_bug_long.txt

I could not reproduce the bug on Xubuntu 22.04.1, neither on a 15.6´´display (notebook) nor on a 22´´ display (desktop PC).

I could reproduce the bug on ISO of Lubuntu 22.04.1, sometimes on a 15.6´´display (notebook) and always on a 22´´ display (desktop PC).

Can you confirm the bug on the ISO of Lubuntu 22.04.1?

[Neil Hodgson]

I have reproduced the bug. It doesn't occur in many similar situations (like a 1,000 line file) so its likely to be caused by particular sequences of operations. That will make it more difficult to understand and fix.

[Neil Hodgson]

This occurs because the widget (and file) is active while hidden as an unselected tab. At this point, it is not a real (mapped, realized) window but already has a file loaded and is trying to wrap the file's text. It wraps a portion of the text and is then resized to be 7 pixels wider (I don't know why). This takes line 15 from requiring 2 lines to all fitting on one line. Because the resize occurs while the widget doesn't have a window, it doesn't run some code including invalidating the wrap information for lines already wrapped. There was a deliberate choice in [20a8ad] to ignore size changes before the widget is mapped.

The check for mapped window could be removed by inverting the above change set, calling ChangeSize (in scintilla/gtk/ScintillaGTK.cxx ScintillaGTK::Resize) even when the widget is unmapped. This seemed to work, but I don't know what the change was protecting against - perhaps it is no longer an issue but it could also cause new problems. For example, scrollbars are manipulated inside ChangeSize and perhaps they aren't ready so will fail or will fail under particular window systems or GTK versions.

Try removing the GTK_WIDGET_MAPPED check. It could be changed in Geany if it works but its more dangerous for Scintilla which runs on older versions of GTK than are supported by Geany. SciTE, for example, runs on GTK 2.x and won't see the bug as it maps Scintilla widgets before loading files.

Checking for changes in size in more places and clearing cached wrapping data could fix this but there are issues here with data consistency. There could be unnecessary work when resize events with no actual change in size occur which is common.