SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: b on March 14, 2019, 12:17:01 AM
-
If I start SE, it will reopen my windows of the previously opened workspace, but it appears to stubbornly force the view such that the "remembered" cursor is 6 characters from the right.
I've been working around this by using the vim emulation '^' to shift the window back to normal. I've seen this when I other workspaces while SE is running (and switching back can spuriously exhibit this issue). The cursor position is in the correct last remembered location, but the window view always forces the cursor to position 6 so it's all shifted weird. I've even resorted to exporting my options, blowing away my 23.0.1 config directory and reimporting my options (attached), but it crops up after a few sessions.
SlickEdit Pro 2018 (v23.0.1.0 64-bit)
Serial number: FE10296
Licensed number of users: Single user
License file: C:\ProgramData\slickedit\23\slickedit.lic
Build Date: February 14, 2019
Emulation: Vim
OS: Windows 10 x64
OS Version: 10.00.0
Memory: 49% Load, 8047MB/16265MB Physical, 9984MB/18697MB Page File, 4658MB/134217727MB Virtual
Shell Information: C:\WINDOWS\system32\cmd.exe /q
Screen Size: 1920 x 1040, 1920 x 1080, 1200 x 1920
Project Type: (Other)
Language: .c (C/C++)
Encoding: Automatic
Installation Directory: C:\Program Files\SlickEdit Pro 23.0.1\ (non-removable drive,NTFS,44782MB free)
Configuration Directory: C:\Users\bkurle\Work Folders\Documents\My SlickEdit Config\23.0.1\ (non-removable drive,NTFS,44782MB free)
-
No luck reproducing this so far. No idea what the trick is.
-
I'm running on MAC and am able to reproduce this by splitting my window (Window menu, split vertically) when my cursor is far right on the line. For instance, I have most of my files setup for 80 column width. If I put my cursor past the end of the line on column 80 when in one window view mode then do the vertical split, the new window opens similar to how the original poster indicated. My cursor is still on column 80 but that column is no longer on the far right of the window, instead the left most column displayed is column 45.
-
I'm running on MAC and am able to reproduce this by splitting my window (Window menu, split vertically) when my cursor is far right on the line. For instance, I have most of my files setup for 80 column width. If I put my cursor past the end of the line on column 80 when in one window view mode then do the vertical split, the new window opens similar to how the original poster indicated. My cursor is still on column 80 but that column is no longer on the far right of the window, instead the left most column displayed is column 45.
I can reproduce this on Windows and macOS. We will look into this. No way to know if this issue is related to the auto-restore workspace files issue.
-
These issues are probably related. This is not hot fixable. This fix will be added to 23.0.2 (no date set yet -- guess ~2 months).
-
I'm running on MAC and am able to reproduce this by splitting my window (Window menu, split vertically) when my cursor is far right on the line. For instance, I have most of my files setup for 80 column width. If I put my cursor past the end of the line on column 80 when in one window view mode then do the vertical split, the new window opens similar to how the original poster indicated. My cursor is still on column 80 but that column is no longer on the far right of the window, instead the left most column displayed is column 45.
I hadn't even thought of that association, but my was horizontally split.
-
I use horizontal split window a lot. Previously, when I hit this issue I could never reproduce the problem. The trick is to put the cursor further out to the right. Also, you may have to have a minimap window for this to occur.
-
I definitely have minimap on. It actually happens quite frequently (several times a day). I look forward to the fix when it comes.
-
Also, you may have to have a minimap window for this to occur.
I also have minimap on.
-
These issues are probably related. This is not hot fixable. This fix will be added to 23.0.2 (no date set yet -- guess ~2 months).
I just encountered this issue with 23.0.2. Note from screen capture that I had minimap disabled.
-
If your vrestore.slk hasn’t been modified by exiting SlickEdit, post it here. I’ll check it over.
-
Looking at the date, I presume that it hadn't been modified.
-
I need your "About" information which has a "Screen Size:" field giving the resolutions of your monitors. You have a lot of different monitor configs and I don't which one to look at.
-
SlickEdit Pro 2018 (v23.0.2.0 64-bit)
Serial number: FE10296
Licensed number of users: Single user
License file: C:\ProgramData\slickedit\23\slickedit.lic
Build Date: May 28, 2019
Emulation: Vim
OS: Windows 10 x64
OS Version: 10.00.0
Memory: 55% Load, 8953MB/16265MB Physical, 15247MB/21382MB Page File, 10244MB/134217727MB Virtual
Shell Information: C:\WINDOWS\system32\cmd.exe /q
Screen Size: 1920 x 1040, 1920 x 1080, 1200 x 1920
Project Type: Cpp
Language: .process (Process)
Encoding: Automatic
Installation Directory: C:\Program Files\SlickEdit Pro 23.0.2\ (non-removable drive,NTFS,14396MB free)
Configuration Directory: C:\Users\bkurle\Work Folders\Documents\My SlickEdit Config\23.0.2\ (non-removable drive,NTFS,14396MB free)
Migrated from: C:\Users\bkurle\Work Folders\Documents\My SlickEdit Config\23.0.1\
Spill File: C:\Users\bkurle\AppData\Local\Temp\$slk.14816 (non-removable drive,NTFS,14396MB free)
-
Couldn't get anything useful out of this. I managed to get it to restore but it didn't restore exactly to what you are seeing. Possibly not a close enough reproduction of your test case. If I click on the cantask-proto.c tab in the top row, I'm not seeing any extra horizontal scroll. I just created dummy files for your files.
-
Very odd. I've had several files that if my cursor is towards the end of a line and I switch projects, or open SE to that project, it will frequently exhibit that nasty behavior of placing the cursor at position 6 in the viewing window and shift the source over. It seems to be very obstinate about that position. (Are you sure you haven't programmed SE with an attitude? :-)
Seriously, it does get very annoying.
I went through several different workspace switches and captured the following:
(remaining is character in line after the cursor to end of line not including trailing newlines)
One project/workspace:
Cursor placed at row 1, col 3 (physically line 48, col 19) w/ 10 characters remaining after cursor
Cursor placed at row 1, col 5 (physically line 31, col 17) w/ 12 characters remaining
after cursor
Cursor placed at row 1, col 6 (physically line 294, col 25) w/ 21 characters remaining after cursor
Cursor placed at row 1, col 6 (physically line 735, col 42) w/ 0 characters remaining after cursor
Cursor placed at row 1, col 6 (physically line 146, col 17) w/ 0 characters ramaining after cursor
Another project/workspace:
Cursor placed at row 1, col 6 (physically line 110, col 68) w/ 7 characters remaining after cursor
Cursor placed at row 1, col 6 (physically line 37, col 19) w/ 43 characters remaining after cursor
The above was just switching workspaces within SE. Closing and reopening SE and repeating the steps of opening different workspaces with multiple windows open finds at least some windows that exhibit this issue.
My workaround (which is rather annoying) is to vim-key ^ to beginning of line and then resume my editing for each file that does this.
-
After banging on this some, I hit a test case where I get some unnecessary horizontal and vertical scrolling. I'm not sure why the issue only happens for some files and not others. Almost seems random. So far, I'm only seeing this when switching workspaces but not if I restart SlickEdit. I'll let you know what I find.
-
Agreed in that it is inconsistent in that it doesn't do it all the time. However, it does it with enough frequency that it is annoying. I look forward to your findings.
-
PM sent.