Full Screen - Jumps in text

Hi,

This is probably a setting somewhere that I have overlooked, but I can’t figure it out.

When I work in scrivenings, in Mac full screen mode, I get weird jumps in the text. For example when I delete an empty line, the whole text seems to jump to the extent that I lost the cursor. This of course is not ideal.

I do not work in typewriter mode and it occurs independent of the editor being ‘locked in place’. The jumps do not occur when the window is not full screen.

Any suggestions? Many thanks!

I get a cursor jump, too, but it’s only when I open a project that resumes my writing in a scrivenings. Then I type about a half dozen characters before it jumps to the beginning of the last document in the scrivenings. Obviously this isn’t a horrible bug, but it catches me often enough to be annoying.

Yeah, that was another one I considered posting, but it only happens occasionally. Very strange though…

The other jumps are happening persistently, so a bit more urgent.

Hi,

Are there any specific steps we can take to reproduce the issue? I tried loading scrivenings in full screen and typing for a while, in different places, but haven’t seen anything like this yet.

Thanks and all the best,
Keith

Thanks for looking into this. I am sorry to put such a vague description up, but this was mainly because I was not sure if this was something simple due to a setting on my side. I have not experimented with it too much.

However, I just went back to it and played around with split screen settings. In full screen I had the screen vertically split.

First: changes in one side affect the other view. For example, if the right screen shows text that comes after the text of the left screen, adding text left will lower the text in the right screen (are you still with me?). This is somehow understandable, but not intuitive.

But second, and that is what this thread was really about, the left screen will also show jumps. So there is some sort of mutual influence, resonance, or name it. When I had then un-split the window, somehow the jumps remained. Maybe because the editor was originally locked in place?

Is this something you can replicate?

On the first point, this would be expected behaviour (I’m not sure why that wouldn’t be intuitive). If the right side of the screen is showing text below that on the left, then text inserted into the editor on the left, which will be above the viewable area on the right, will naturally push all other text down - that’s what happens when you insert text somewhere in a document in any app, the text below it gets pushed down. That’s just standard macOS text view and scroll behaviour. (To stay in the same place, Scrivener would have to constantly monitor the current top corner position, monitor for changes in another editor, and then scroll back to that position after a change, only if the change came before that corner position. That would be quite a lot of processing for non-standard behaviour.) You’ll see the same behaviour in Word’s split view, for instance.

As to the second point, though, that is truly strange! And I’m afraid I cannot reproduce it. The only effect the editors have on each other is that they share the same underlying text, so edits to one will cause the other to update as the text is changed. They have no scrolling effect on each other, so I can’t think offhand what could be the cause of this.

Are you using page layout view? A zoomed editor? There must be some particular circumstances that trigger this.

All the best,
Keith

I get the cursor jump every time I open a project that resumes in scrivenings. And it’s vexing, because I usually do a bit of thinking before I start typing, so when I do start, I’m no longer thinking about Scrivener but about the writing. My thoughts are then thrown off, the cursor is lost, and I have to start the process again (although now irritated).

Ok - apologies for the silence. I realised the effect only takes place on my external screen, which is in my office. Tiny detail I forgot to mention.

The problem seems to occur when I zoom my text to 135%, which is a custom zoom. On playing around with this, there appears to be a range in which custom zooms cause this behaviour
95% - ok
105% - jump
115% - jump
135% - jump
145% - jump
155% - jump
165% - ok

I can imagine this effect to be affected by the resolution of the external screen. Which, in my case is 3840x2160 (4K) and I am using a scaled display setting (the second largest from the five options in MacOS settings). Writing this down, I can also imagine that this is becoming so hyper specific that you might not bother looking into it further. I could just try to adjust to a different zoom to work in peace.

Btw - I have now worked around this by zooming to 136%. No text jumps.

I’m glad you’ve found a workaround at least. I haven’t been able to reproduce this yet, even with an external screen (I use an external screen for writing with Scrivener myself). However, I suspect that’s because this will take a particular combination of screen size, window size and text zoom (just resizing the window might have possible got rid of the jumps).

The problem is that the macOS text system isn’t really designed to be scaled and reflowed, but I bend it to do so. This means that certain scales result in fractional values in zoomed font sizes, line spacing and so on, and sometimes the text system just doesn’t like those particular sizes. For this very reason, in fact, in Scrivener 2 I limited the number of zoom factors available and allowed no way to pick a custom zoom. Users really wanted a custom zoom setting, though, so I figured it was best just to allow it and to deal with issues as they arose. :slight_smile:

Thus a tiny tweak such as adding 1% to the zoom factor can make things behave normally.

Exactly. Thanks for the background–it confirms my suspicion. And you are right, it does not happen when the window is resized. Just an unlucky combination of settings.

I like the ability to set my own zoom factor. Rather than giving the user the exact zoom that is entered, it may be an idea to ‘snap’ to the nearest value that won’t give problems. But that is assuming you know when this occurs. Given the various factors that play a role that may be complex.

Anyway, for me the problem is solved. Thanks for sharing your insights.

Unfortunately, that is indeed the problem - it’s almost impossible to know whether a particular scale factor will cause problems. I already round the scale slightly to try to account for this as best as I can, but because of the various factors, a scale might work fine on one screen and not on another, or it might work well with one window size and not with another, so it’s only possible to do a “best fit”. The fact that the window resizing worked well is telling, too. Sometimes the scale can cause the text view itself just to have a fractional internal size that the text system doesn’t like, and this is hard to account for, because a scaled view has a different size internally than it does as considered by other UI elements (a text view at 200% thinks it is half the size than the window thinks it is). A fractional tweak to the window size and the problems go away because the two sizes, inner and outer, suddenly align better with the window. And this is compounded, of course, by the difficulties in reproducing issues at any particular scale because of all the particular factors involved.

(You would think that just having Scrivener adjust the window and view sizes so that none of them are fractional might help, but even that won’t necessarily work, because a scaled text view may require a fraction in its size to account for the scale. Given that different text views - the two editors, the notes area and the bookmarks area - can be scaled, then they might have conflicting requirements, too.)

I’ll definitely keep pondering on it, though; it’s something that I’ve improved quite a lot over the years, so that only a few quirks - such as the one you encountered - remain.

All the best,
Keith

Hi, I just want to flag that this issue is still there, possibly worse, as my editor behaves as if typewriter scrolling is turned on when I work at a custom zoom factor.

As in the past, I’ll adjust the zoom to make Scrivener behave, but I think you should be aware there is a mode where Scrivener does not perform as it should. The custom zoom is nice to have, but it of course comes with the expectation that it performs the same as the preset modes.