Hello fellow Emacs enthusiasts,

I’m reaching out to see if there’s anyone here who’s successfully integrated a modern development environment within Emacs for Python programming. Specifically, I’m interested in a setup that incorporates eglot, tree-sitter and company.

I’ve encountered a significant issue: whenever I enable python-ts-mode, Emacs consumes all my system’s memory and crashes. While I’ve managed to use a more basic setup that limits tree-sitter to syntax highlighting only, I can’t shake the feeling that I’m missing out on some great functionality.

To help with investigation:

  • I am running on a Mac
  • The bare minimum to reproduce this problem is on the following gist: https://gist.github.com/hnarayanan/a6397d6723fce19e2802d4305071e611
  • I happen to use Emacs from MacPorts, but to double-check, I also attempted to download it from https://emacsformacosx.com and it crashed in the same way
  • This seems to happen independent of the language server used in the backend. I intend on using python-lsp-server, but it fails even if I don’t have it installed.

Has anyone faced a similar problem and found a solution? Perhaps I am doing something very wrong with my config? I’m eager to learn from your experiences and would greatly appreciate any advice or tips you can offer.

Thank you!

  • rileyrghamBEnglish
    1·
    1 year ago

    I’d doubt it’s treesitter. It could be, of course. The LSP server more likely. If using Linux run htop or something and check memory usage. Edit: Mac. Find the htop equivalent.

    • copingbearOPBEnglish
      1·
      1 year ago

      Thank you for the hint. It is even prior to the LSP (I think), because I run the LSP within a virtualenv that I can choose to not activate. And in either case it is Emacs taking up like 30+ GB of memory until I force kill it: https://imgur.com/a/F6liREU

      • fragbot2BEnglish
        1·
        1 year ago

        Several comments:

        • based on the CPU utilization, I’m guessing there’s an error condition that causes a spin that continually tries to allocate memory.
        • in my experience, things like this are often visible if you trace the executable. Unfortunately, OSX makes this unpleasant: https://www.shogan.co.uk/devops/dtrace-dtruss-an-alternative-to-strace-on-macos/.
        • if you send a kill -11 to the process, you should get a corefile of the running process. Running something like strings or hexdump against the resulting image (you’ll want to remove it when you’re complete) might make the problem obvious. There should be a way to start the process with limited memory to avoid generating a 30GB core file.