Inform7 IDE Slow Editing

I tried loading the project you sent (by email) in the latest Inform IDE (1.68.1), and I had no problems editing at all.

(I have that elastic tabstop preference turned on. It’s now called “auto-space table columns” in the preferences pane.)

I didn’t see anything in the code that looked suspicious, either. No particularly long paragraphs or comments or I6 inclusions. No line break peculiarities.

The only thing that was slightly odd was a bunch of table declarations with extra tabs:

Table of Smarter Parser Messages (continued)
	rule name		message
	stripping niceties rule		"[run paragraph on]"

According to normal I7 style, these lines would be unindented. The compiler doesn’t care – your code works – but the indentation trips up the “auto-space table columns” preference; those tables are not in fact auto-spaced in the editor.

But, as I said, I don’t see any slowdown problems. So that indentation is a red herring as far as I can tell.

Andrew, do you have the latest Mac release for Catalina or another release?

I have Big Sur 11.1, which is later than that.

It would be strange if the editing code had broken only on Catalina, though. 1.68.1 was released for Catalina.

Actually I also have Big Sur. So that’s mysterious.

OK, I should’ve thought of this experiment earlier, but it is definitely syntax highlighting related. If I disable syntax highlighting, I get no typing lag.

1 Like

I am having the same problem. And the solution was indeed disabling the syntax highlighting feature. It was working quite fine until I (unfortunately) updated the Big Sur version to 11.13.1 hoping to fix some screen glitches. Not only my external monitor is not working at all, but also Inform became unbelievably slow.
Is there some other text writer that you would recommend to write the text using syntax highlighting? Is a feature that I’ve became an addict to, my source text has plenty of substitutions, so I’m kind of lost now because the colors were really helping me.
Any suggestions are very welcome.
Thank you!

I gave up on the IDE. I started using Atom which is a sophisticated editor I use for most of my programming. There is a inform7 context highlighting plugin.

I had some challenges around representation of headings and the IDE (still used for compiling) overwriting the file I was editing (as described here).

But these were largely overcome by adding a few rules in Atom to increase the size and font-weight of hedings. And the overwriting problem was overcome with this great suggestion.

Thanks a lot! I will read more and see if it helps.

I’m afraid this syntax-coloring slowdown is connected to some factor that we don’t yet understand. Wes saw it starting on MacOS 10.15; you saw it starting on 11.13.1; I don’t see it at all.

I don’t use Mac, so I can’t help you. However, mysterious slowdown points me to 2 possible causes: 1. Cache Memory. 2. Bad library.

It may be worth it to run test files ( no need to compile, just load it in the editor) in ever increasing size and see what it does.

  1. Cache: the operation will go smoothly until there’s a jump in sluggishness
  2. Library: Response time will worsen in exponential manner.

I personally ran into the second issue on my Google Doc, where I notice slowdown starting on page 100 and get progressively worse until it became intolerable.

Another note is that I ran into sluggish editor, not due to the editor, but due to the windowing system. The slowdown would be of constant time. For some reason, the display was set to Smooth Font, and that’s the difference between slow and fast. The problem immediately disappeared when I turn off that option. This setting can be found both in OS desktop and IDE. So, it bears checking on all settings. I doubt that is your case, since it’s fast if you turn off syntax highlighting.

So, if you want to know what causes it, check for memory, and whether the slowdown behavior changes when the file size is different, and in what way.

Another note: does the editor uses regex for syntax highlighting? Some languages/libraries are notably slow with those. I don’t see why it would work on some, but not the other, though. Unless it’s a dynamically linked library.

I can reproduce this with my Cragne Manor contribution code, but not in a new project, so it obviously (and unsurprisingly) is related to source code length.

This is Inform 1.68.1 on Big Sur 11.3.1 on a 2016 MacBook Pro (2,6 GHz Intel Core i7) with 16 GB RAM and Intel HD Graphics 530. Those of you who cannot see this, what are your specs?

EDIT: Another possibly unrelated IDE bug: Clicking the “Restore default settings” button makes Inform beachball indefinitely.

Dabbling around in the profiler, I have a suspicion that the slowdown might be related to the handling of the touch bar:

Towards the bottom of the visible trace, there’s a function labeled -[NSTextView(NSTextView_TouchBar_API) updateTextTouchBarItems], and then heaps more calls related to the touch bar that didn’t fit in the screenshot. Those calls (and indeed the slowdown, for the most part) aren’t happening on my desktop Mac.

So if @zarf was testing on a desktop Mac, or an older MacBook without a touch bar, that might explain why he didn’t experience any slowdown.

As for the underlying problem that causes this… I have no idea.


Good spotting! You are correct; I tried testing on my MPB (with touchbar) and it was very slow. On my desktop iMac it’s fast.

Actually, even with syntax coloring off, editing gets a bit slow with a large source file on the MPB. Not slow enough to impede work, but it’s slower than editing should be.

(I looked around for a large single-file I7 source file for everybody to test with, and came up with . That’s old I7 code, so it doesn’t compile on 6M62, but it suffices to demonstrate the syntax-coloring problem.)

If you add the lines

- (NSTouchBar *)makeTouchBar {
  return nil;

somewhere in IFSourceFileView.m and build Inform from source, the problem goes away.

EDIT: When the project is opened in Xcode, the file is at Inform > Source > Project > IFSourceFileView.m

EDIT 2: The code to disable the touchbar is “borrowed” from Yazmin.


Would it be out of line to put up a fixed unofficial build on Github?

1 Like

That should be fine. I’ll ~create a bug report~ update the existing bug report.

For what it’s worth, I think that the problem is not that the TouchBar call is taking forever. It’s that the whole “display layer” sequence is being called thousands of times per keystroke.

1 Like

Right, there probably is a better fix, then.

Until then, try this and see if it works:


Thanks a lot!
I’m using a Mac with TBar, and the new release worked wonders!
The Dark mode fix is also great as I had already to re-install Inform a couple of times because the preferences fix wasn’t so stable.


Works for me as well. Thanks for doing the detective work and providing an interim fix.


Thanks! I had been struggling with this issue since I got my new Mac last October. Works very well.