Weird Lag when entering new lines

I’m using Monterey 12.0.1 with Scrivener 3.2.3. My laptop is the new MacBook Pro 16" with the M1 Pro and 16GB of RAM.

If I try to enter a new line above the last line of the document (or delete a line, basically any action that moves the last line of text in the document up or down) there is a lag in the movement of the last line. This does NOT happen on TextEdit or Pages. It happens regardless of the font I’m using.

Mysteriously, it doesn’t happen if the cursor is placed at the beginning of the last line of the document, and instead only when entering new lines above it.

See below for a video of the issue:

1drv.ms/v/s!ArlYERYmr0j83iMYaf9-JLtdXh46?e=6PR5te

search here for “lag” to get some initial ideas. focus on the system and keyboard first.

Thanks for the tip. I did search the forum for “lag” but didn’t find anything similar to my issue. Seems those tend to be issues regarding lag while typing or when opening documents or exclusively in composition mode, none of which I get. Typing is smooth up until a new line is inserted and composition mode works flawlessly (I’ve only ever noticed the new line lag once on composition mode).

This issue only happens when entering new lines (or removing them) above the last line of the document, either by using the return key or by pasting line breaks into the document or even by just typing until text wraps into new lines that push the last line down.

  1. Doesn’t happen on TextEdit, Pages, or other text editors.
  2. 16GB of RAM with 9GB free (low memory pressure) and 2% CPU usage.
  3. Happens in new and existing projects as well as short documents (see video in first post)
  4. Happens with different fonts, and with Chinese or English text on the document.
  5. Scrivener works otherwise flawlessly and very fast. I have a project with a 400k word manuscript, and it opens in a couple seconds and can open the entire manuscript nearly instantly.

i did a google on “typing lag macos” and found a number of articles. 7 Ways On How To Fix Keyboard Lag Issue On Mac gives some specific ideas.

Thank you for your help again, but this presupposes a hardware issue. If there were a hardware issue with my keyboard, surely typing on any software would be affected, right?

There is no lag on any other software I’ve tried where I can type text (TextEdit, Pages, Xcode, Safari, and Sublime Text).

Aside from this one issue, typing works flawlessly on Scrivener as well. Inserting new lines at the end of the document also works perfectly with no lag. The only issue is the aforementioned lag when adding new lines above the last line of the document.

last idea since you target scrivener … uninstall it and reinstall. may fix any corrupt files.

Thanks for your help. I uninstalled Scrivener, redownloaded it from this website and then reinstalled it. However, the issue still persists.

well, i am out of ideas. still think it is related to the system, though.

If you go to View > Text Editing > Typewriter Scrolling, does changing that setting affect the lag at all?

I tried with the Typewriter Scrolling setting on and off and the behavior was the same.

However, I neglected to mention that this whole time I’ve been using the application in full screen mode. I went out of full screen mode, and having Typewriter Scrolling on made a significant improvement, now the lag only happens if there are no empty lines in the document, and after creating one the lag goes away for subsequent new lines.

Turning off Typewriter Scrolling outside full screen mode got me a similar behavior as I was experiencing originally in full screen mode, but there seemed to be a slight improvement in the lag.

In sum:

Full Screen + T.S. On = very laggy
Full Screen + T.s. off = very laggy
Not F.S. + T.S off = less laggy
Not F.S. + T.S. on = only laggy if there are no blank lines, after the first new line, the subsequent ones are clean/smooth

Please let me know if a video would help, and what behavior you’d like me to record.

Thank you for those additional details regarding when the lag occurs. I tested a sample project on my Mac using Monterey and Scrivener 3.2.3, but I could not recreate the issues you’ve encountered in full screen.

You stated that your project is over 400k words. Does it have a lot of media files, images, or PDFs in its Binder? If so, that might account for some lagging.

If you’re willing to do some additional testing on this, I’d be curious to see if you can recreate the lagging issues you’ve encountered in full screen mode when you’re working in a different project.

For example, you could open Scrivener’s Interactive Tutorial (which you can access via the Help menu) and try taking it full screen.

Then, please try editing one of its existing documents to add some material, just like you’ve done in your project.

Does the lagging also occur in the Tutorial? If so, does it occur in all four combinations of full screen and typewriting mode? Is the lagging as bad as it was in your project? (You can reset the Tutorial to its defaults later via the Help menu.)

The Tutorial is a reasonably complex project, and testing this behavior in it could help us narrow down if this is something about your project’s size or something within the Scrivener installation.

If the Tutorial does not have a lagging problem, then I’d look to your project’s overall size to see if that’s a factor. You might also see if any project settings or Scrivener Preference changes affect how the lagging issue behaves.

Thank you for your response, RuthS. My project is entirely text except for one small JPG outside the manuscript.

I did a lot more testing with the default interactive tutorial as you suggested and found that I could no longer replicate the issue whenever I had Typewriter Scrolling enabled. The issue was still present with it disabled though - being full screen seemed to make no difference.

Just to be sure, I recorded another video showing all four combinations of settings with the interactive tutorial: 1drv.ms/v/s!ArlYERYmr0j83l4ll8IdVuEFNXhs

Thank you for testing the Tutorial and those different modes. Getting that information is helpful.

I have some troubleshooting steps that you might try. I suggest testing between each troubleshooting suggestion to see if the lagging behavior has been corrected.

I’d start with holding down the option key on the keyboard while clicking on Scrivener’s File menu. That should give you the option of selecting “Save and Rebuild Search Indexes.” It will prompt Scrivener to review its internal indexing system, in case the project’s size has affected its performance.

If the project continues to lag, then I’d suggest resetting the project’s display settings, and we have a Knowledge Base article about that process.

If the project continues to lag, you might check this Knowledge Base article to reset Scrivener’s preferences.

If the lagging behavior continues after you’ve done those three troubleshooting processes, please let me know.

Hi RuthS, thank you for the troubleshooting suggestions.

I tested after each of “Save and Rebuild Search Indexes” and resetting the project’s display settings and neither made any difference, so I moved on to resetting Scrivener’s preferences, and then restarting my computer.

When my computer booted again, I opened Scrivener from the launchpad and a small window opened with info about setting up the backup folder, but that window immediately closed and I got this crash report: gu-aiwen [dot] com/crashreport.txt (not sure why I’m not allowed to post any links, so please replace the [dot] with a . )

After reopening Scrivener, I got the backup folder window again, and then the option to open the interactive tutorial, which I clicked on. The tutorial opened fine this time, but I can confirm that the issue persists. I still get the same kind of lag with new lines at the end of the document.

Well now. That’s frustrating news.

At this point, I’d suggest starting a help ticket with our support team using our contact tools.

If you choose to start a ticket there, please include a link to this discussion. That way, the tech-support staffer who picks up your ticket can review our discussion and get up to speed on the steps we’ve already tried to resolve this.