View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0035854||Lazarus||IDE||public||2019-07-17 10:43||2019-07-31 23:15|
|Reporter||Jan Sebosik||Assigned To||Martin Friebe|
|Product Version||2.0.3 (SVN)||Product Build||r61485|
|Target Version||Fixed in Version|
|Summary||0035854: Unable to scroll text editor while doing column selection|
|Description||Dear community, |
did anybody else observed situation that while you want to highlight column of text while holding Alt+Shift+Up/Down the code editor does not follow cursor?
|Steps To Reproduce||mark some text with SHIFT+Left/Right arrow, then while still holding SHIFT press and hold ALT key and scroll up/down past the visible part of code editor to make selection column|
|Tags||No tags attached.|
|Fixed in Revision||61649|
It works fine for me.
"mark some text with SHIFT+Left/Right arrow, then while still holding SHIFT press and hold ALT key and scroll up/down past the visible part of code editor to make selection column"
This is all performed by keyboard? No action/scrolling using the mouse?
It could be caused by some setting in Tools > Options.
Please find your config dir, usually: C:\Users\USERNAME\AppData\Local\lazarus
And in it the file EditorOptions.xml
Please attach this file.
Or do you mean, while pressing Alt+Shift you are using the mouse-wheel to scroll? This indeed will not extend the selection.
While marking column of text without going past the visible text it works fine - there is no requirement for editor window to scroll.
But - once I try to make column that needs to extend beyond visible text, then it does not scroll text while still holding pressed Alt+Shift+Up/Down arrow.
Once I release Up/Down arrow then source editor redraws content and I see where I stopped holding arrow key.
Everything done by keyboard, no mouse involved.
editoroptions.xml (957 bytes)
Unfortunately I still cannot reproduce.
Sorry this are going to be lots of questions now. But since I have no idea what causes the Issue, I need to look for any clue.
I tested with 2.0.3 61485 as you, also with trunk and with released 2.0.2.
All Lazarus are 64 bit and on Win10. And build with fpc 3.0.4
What I do to test:
- I open a unit that has more lines than fit in the editor (e.g ide/sourceeditor.pp).
- I press and hold shift
- I press cursor-right once (that will select one char)
- I press and hold Alt (now Shift + Alt are down)
- I press repeatedly cursor-down
When I reach the last fully visible text line, the next cursor down does scroll the editor up by one line, while still extending the selection.
Are those the exact same steps you do?
At any time, the source-editor window is fully visible on the screen. I can see the source editors statusbar at the bottom, and the tabs on the top.
- You are on Win 10 ?
- 64 bit?
- any packages installed?
If you use anchordocking (or other docking), can you try without? It did work with anchordocking for me, but still.
- fpc, which version? (though that is not likely to matter)
- IDE compiled with any optimization settings?
Anything else that may vary from a default install?
When you have the problem that the editor does not scroll, can you watch out and see if:
- While you do Shift-Alt-cursor_down, does the line number in the left corner of the status bar increase (as it should)?
- "does not scroll". Can you watch the scrollbar. Even if the text does not move. Does or Doesn't the scrollbar change?
And does your source-editor have a horizontal scrollbar? Or can you lower its width, until it has?
Please start the IDE with
To do so, edit the desktop shortcut. Or run from a cmd.exe terminal.
Once the IDE started, please reproduce the issue.
Then close the Issue, and upload the logfile.
For better imagination I will provide video capture of window.
Platform: Windows 8.1 x64 with updates till June 2019.
Used fpcupdeluxe to compile:
FPC 3.2.x-STABLE branch
Lazarus 2.0-STABLE branch
It seems to me that thanks to Windows Filter Keys the situation is worse.
But even with disabled filter keys it happens (but as keyrate is not so fast, it is not so bad - but text is still steady while scrolling).
Line number does not increase while scrolling, and scrollbar on right side of the text editor still scrolls - but - as it stalls scrolling text, right scroll bar slows down its speed.
Please see attached video (mp4 format) - stalled text editor is visible on this recording.
2019-07-17 22-13-01.mp4 (1,092,487 bytes)
So if you do NOT hold the cursor-up key, but instead press (and release) it once for each line, then it probably works.
If that is the case, then this behaviour can not be fixed (other than improving the overall processing speed of the editor).
So if this is the issue, then it can currently not be fixed.
As far as I can see, what happens is that the keys press events (auto repeat at a fast rate) use all the processing time, and there is no time for repainting the editor.
The way the many applications (including the IDE, and all LCL apps) work is, that they give paint events the lowest priority. So as long as key press events are coming from the OS, the IDE will not (re-)paint the editor (or do any other graphical update).
If it finishes a keypress, before the next one arrives, then it will do the painting. During that paint a lot of keypresses get queued, so after that paint it takes a long time to the next paint.
I can see, that the "extra carets" are painted (thin vertical white line). They are force painted, even if other painting is delayed. So that speaks for this being a "not enough time for paint" issue.
Note the editor and painting only use a single thread. So multi core CPU do not help here. This is a question between:
- The single core speed of your CPU
- The speed of your graphics hardware
- The time the editor needs to process the keypress
The editor is (unfortunately) not the fastest in the list. But it is not that slow either.
Until a year ago, I have used that editor on a vista pc that was about 10 years old. And scrolling was ok (Though I do rarely (if ever) use block selection). So I still wonder what slows it down for you.
You already turned off the most time consuming part of the editor, which is the "overview gutter" on the right side (that would be shown right next to the scroll bar).
There may be one more thing you can do. Especially if normal scrolling (cursor up/down, without selection) works for you).
Go to Tools > Option > Editor > General
Disable the checkbox: "Enable multi caret for column selection"
If you do column selection, the editor also creates additional carets, maybe painting those consumes to much time....
ONLY if you do NOT check above option "Enable multi caret for column selection"
If you do need the extra carets, you can try to compile the IDE with (Tools > Configure Build Lazarus)
I do not recall what the issue was with/without this define. It looks like it may reduce painting exactly in the case that causes this issue here.
So maybe it can help.
ONLY if you do NOT check above option "Enable multi caret for column selection"
Another thing you could try (not sure if that helps though):
Open and edit components\synedit\syneditpointclasses.pas
line 2999 depends on svn rev)
FForcePaintEvents := False; ///// <<<<<<<<<<<<<< CHANGE TO TRUE
FForcePaintEvents := True;
This will add more work when painting, outside scrolling. But when scrolling with multi carets, this may help
Please check if my description fits your case.
If you can: Does a lower key repeat fix/reduce the issue ?
once I unchecked the option "Enable multi caret for column selection" in Tools > Option > Editor > General, problem is gone.
My CPU is Core i7-6700HQ - not the best one on the planet, but should be sufficient for code editing.
( maybe guys with Java / Electron IDEs will have different opinion :D ).
Thanks for all the help that you've provided.
Ok, there is nothing I can fix in the short term.
On the long term, it might be that the multi caret drawing can be optimized (i.e. they should probably not be force drawn during scrolling)
So I leave the issue open, but it is not sure if/when any work will be done. Or if such work would be sufficient to fix the issue.
||May I kindly ask you if you know which part of Lazarus source code is responsible for drawing of multiline caret?|
Sure, all in the folder components/SynEdit.
In unit components\synedit\syneditpointclasses.pas
Also check in SynEdit.pp the function TCustomSynEdit.ScrollAfterTopLineChanged
On Windows, a process can draw outside the paint event. Using XOR paint, this reduces workload for SynEdit.
But it appears that the carets are painted, even if the scroll never happened. That is probably undesirable.
I am happy to assists with further info. But if you do not mind, could we discuss this on the forum or mail list? (If you mention synedit/multicaret, I will notice it).
Strange, now it suddenly happens on my PC too.
Something must have changed the timings to just tip it over.
Ok, I committed a fix to trunk (wont go to fixes).
Please test and close if ok. (re-open otherwise)
There remains a small chance of the scrolling still freezing. Most of them when doing carte down / scroll up. In that case the lowest line needs to be painted after each scroll (since the lowest line scrolled in).
If at the same time the editor needs to repaint a line further up, then all lines in between are repainted. This could in theory already cause freezes without the carets. But with the carets it is even more likely.
This can happen if:
- the caret moves over an "end;", and the matching "begin" is highlighted (if that feature is active)
- the caret leaves a long procedure, and the top-line of the editor had the "top line hint" name of the procedure, which then needs to be removed.
- ... other similar highlights.
Additionally the carets (while no longer all of them are repainted) still need to be processed. e.g. find which one(s) scrolled in/out. The more carets there are, the more processing. I found that (on my pc) at around 300/400 in combination with begin/end pairs, the first issues can be noted. After a minimal pause (release the keys), it is possible to continue (with all the carets), and it will scroll. I tested up to 2000 carets.
This processing may still be subject to minor optimization. But some freezing may remain, depending on the overall feature mix that is enabled.
EDIT: done in 61650
|2019-07-17 10:43||Jan Sebosik||New Issue|
|2019-07-17 11:56||Martin Friebe||Assigned To||=> Martin Friebe|
|2019-07-17 11:56||Martin Friebe||Status||new => feedback|
|2019-07-17 11:56||Martin Friebe||LazTarget||=> -|
|2019-07-17 11:56||Martin Friebe||Note Added: 0117279|
|2019-07-17 19:09||Jan Sebosik||File Added: editoroptions.xml|
|2019-07-17 19:09||Jan Sebosik||Note Added: 0117285|
|2019-07-17 19:09||Jan Sebosik||Status||feedback => assigned|
|2019-07-17 20:54||Martin Friebe||Status||assigned => feedback|
|2019-07-17 20:54||Martin Friebe||Note Added: 0117286|
|2019-07-17 22:21||Jan Sebosik||File Added: 2019-07-17 22-13-01.mp4|
|2019-07-17 22:21||Jan Sebosik||Note Added: 0117287|
|2019-07-17 22:21||Jan Sebosik||Status||feedback => assigned|
|2019-07-17 22:22||Jan Sebosik||Note Edited: 0117287||View Revisions|
|2019-07-17 23:09||Martin Friebe||Note Added: 0117289|
|2019-07-17 23:11||Martin Friebe||Status||assigned => feedback|
|2019-07-17 23:11||Martin Friebe||Note Added: 0117290|
|2019-07-17 23:14||Martin Friebe||Note Edited: 0117289||View Revisions|
|2019-07-18 00:25||Jan Sebosik||Note Added: 0117291|
|2019-07-18 00:25||Jan Sebosik||Status||feedback => assigned|
|2019-07-18 00:42||Martin Friebe||Note Added: 0117292|
|2019-07-18 01:09||Jan Sebosik||Note Added: 0117293|
|2019-07-18 02:01||Martin Friebe||Note Added: 0117294|
|2019-07-31 15:54||Martin Friebe||Note Added: 0117525|
|2019-07-31 22:56||Martin Friebe||Status||assigned => resolved|
|2019-07-31 22:56||Martin Friebe||Resolution||open => fixed|
|2019-07-31 22:56||Martin Friebe||Fixed in Revision||=> 61649|
|2019-07-31 22:56||Martin Friebe||LazTarget||- => 2.2|
|2019-07-31 22:56||Martin Friebe||Widgetset||Win32/Win64 => Win32/Win64|
|2019-07-31 22:56||Martin Friebe||Note Added: 0117530|
|2019-07-31 23:15||Martin Friebe||Note Edited: 0117530||View Revisions|