emacs lockup

[JohnC32]

On a large (15+ MB) *.xml file in nxml-mode, when highlight-indent-guildes-mode is enabled, emacs locks up. Is there something that can be done about this? If you need a reproduction case, let me know and I'll see about writing a small script that generates a large *.xml file.

[feng-li]

Same here. It is very slow to navigate and type with (not so) large C code files (ca 1k lines).

[DarthFennec]

I can't seem to reproduce. If you can both provide example files (or that generator script) that trigger the issue for you, that would be fantastic. A handful of people have asked about slowdowns/lockups like this, concerning interactions with specific file types or modes. Sometimes there's an underlying problem that can be solved, other times there doesn't seem to be anything at all, so we'll see for your cases. Thanks for opening the issue!

[ChuckFoo]

I believe I've been seeing this same issue for a while now with a (~1.8MB) org mode file I use as a work log (both in Emacs 26.3.1 and Emacs 27.1). I use your mode along with other modes as well (various programming language modes) but the issues I've been seeing have primarily been with my org mode file.

Seems to be triggered for me by typing some "double quotes". Typically huge pregnant pauses sometimes happen when I open with the first quote and/or close with the second. Hitting ctrl-g when this happens will generally get things back to normal for a little bit (esp if I've already typed the closing quote first, it appears immediately then) but the indent highlighting is generally a little wrong at that point, and more quotes later will trigger the slowdown again.

So, I just tried creating a testcase for it (~113KB) foo.txt which I've attached (although I renamed it from foo.org to foo.txt because apparently github only has a small set of "supported types" it allows to be uploaded). I wasn't 100% successful in reproducing my version of this problem with this testcase as I didn't get the super huge pauses, but I definitely did see a slowdown in typing when opening a quote and typing, which seems to get worse over multiple lines, and I'm guessing is related to the worse behavior I'm seeing with my real file, as well as the two similar problems reported here.

The text is mostly repeated lorem ipsum, but in the first bit of real text I started typing what I was doing and what I was seeing while doing it (including behavior changes I was seeing with switching in and out of h-i-g and org mode). This was done in an Emacs 27.1 started with -q so it didn't have any of my other customization in it, and I manually loaded your mode and evaled the buffer to be able to enable it in the otherwise "clean room" test case.

For some reason I am having troubles getting debug-on-quit to put me into the debugger when ctrl-g-ing out of these pauses, otherwise I'd try and get more info to you that way, but hopefully this will be sufficient for you to reproduce the issue.

Thanks!

[ChuckFoo]

And I just tried copying the above test file contents 9x over to make a ~1.1MB test case and continued typing where I left off the first section (after "so I wasn't able to...") and the problem was definitely worse, much closer to what I've been seeing.

And I forgot to mention, my pattern of editing this file is to add new sections to the the top of the file, my real file is a daily work log with patterns like so:

* 2020
** 202010
*** 20201016
    - stuff I did that day

    - more stuff from later that day
*** 20201015
    - stuff from the day before morning

    - stuff from later in the day the day before
...
** 202009
....
* 2019
** 201912
...

And that's how I was editing this testcase too. So I just went to the bottom of the (now larger) testcase and the multi-line double quote slowdowns didn't seem to happen while editing down there at all...

[DarthFennec]

Hi @ChuckFoo! The quotes thing is a known issue, actually (see #33). Here's how things go down:

1. You change something in the buffer
2. The mode checks to see if anything relating to indentation has changed
3. The mode propagates indentation changes downward until it reaches a point where no more guides need to be changed (this can just be a line or two, the rest of the block, or the whole file)

Anything within quotes is considered a string, and whitespace within a string is never considered indentation. Otherwise you might get indentation within a string affecting guides in the lines following the string, which can be confusing. The same is true for comments.

When you add an open quote without a close quote, it treats the rest of the file as a string and has to delete all the indentation guides. This takes longer for longer files. Similarly, when you add a closing quote it has to calculate and add all those guides back in. This is why you're getting this slowness. This is also why it's not as bad at the end of the file, there isn't as much to recalculate down there.

The way I solve this, and my recommendation to you, is to enable electric-pair-mode. This will close your quotes (and brackets and other things) automatically without giving the indent guides time to start recalculating, eliminating the long hangs. In addition to solving this problem, it's also just really convenient feature.

[ChuckFoo]

Hey there @DarthFennec, thanks for the info, although I had already guessed at most of it, and the fact that it doesn't have that problem every time I start w/ a new open quote in that same file is still a little puzzling to me (since as I said I'm pretty much always editing it near the top).

Honestly I normally hate editor behavior like electric-pair-mode but perhaps for this particular situation I can make an exception and perhaps it's a good enough workaround for now. And if not...it's been a long time since I've written any elisp but maybe I can dig a little deeper and try and get some hints on why the behavior doesn't seem to be consistent at least.

Thanks!

[DarthFennec]

Huh, yeah I feel like it should be happening consistently every time. I love electric-pair-mode, it saves me keystrokes and makes it harder for me to accidentally miss a closing bracket, but I guess I get wanting to do it yourself. I'd recommend something else but there aren't any other good workarounds that I'm aware of, nor is there a good way to fix the issue that I've been able to find.

[tedlava]

This bug also affects macros that insert quotes around existing text too. It essentially doubled my runtime for a macro over a not-so-large file (330 lines). Granted, it also looks like there's a bug in having C-n in a macro too (which is a separate bug), but running the macro with highlight-indent-guides-mode enabled takes about 1 minute and 18 seconds on average for just 330 iterations! With highlight-indent-guides-mode disabled, it takes 41 seconds to complete!

[DarthFennec]

@tedlavarias Thanks for bringing that up, I'll have to look into that.