63ace3ca makes Neovim startup slow and brittle

[seflue]

Describe the bug

It is a bit hard to describe, but with the change done in 63ace3c I got two problems:

First without mitigation starting more then one Neovim instances get's an adventure with surprising effects. Because I am an org-roam user I have hundreds of little org-files. For all of these orgfiles now I get a swap file created on startup and when I start a second instance, it complaints (in Org-Roam) about those very swap files. But Roam is only the messenger here, the issue is Orgmode and one of it's API functions which got changed by this commit. This effect I found a one-line solution within orgmode, which basically disables swap file creation when loading org files over the API.
The second one is that startup get's really really slow (multiple seconds) and I got strange glitches and multiple notifications (Hardwarp enabled). For this I didn't find a solution.

I pinned down the causes of these effects to this very commit and reverted my local instance to the commit before to be able to use Neovim and Orgmode productively.

Because I am very busy right now I wasn't able to provide a deeper and more detailed analysis of the problem. But this commit breaks my daily workflow, so for me it is quite severe.

checkhealth

orgmode: ✅

Orgmode ~

• ✅ OK Treesitter grammar installed (version 2.0.0)
• ✅ OK Setup called
• ✅ OK org_agenda_files configured
• ✅ OK org_default_notes_file configured

Steps to reproduce

Open neovim.
Open neovim somewhere else.

Expected behavior

Same startup behavior as before commit 63ace3c.

Emacs functionality

No response

Minimal init.lua

-- Enter your minimal_init.lua here

Screenshots and recordings

No response

nvim-orgmode version

All commits since 63ace3c

OS / Distro

Arch Linux

Neovim version/commit

v0.11.4

Additional context

No response

[kristijanhusak]

@seflue I pushed a change to disable swapfile creation for these buffers. Regarding everything else, you can follow #1049.

[seflue]

@seflue I pushed a change to disable swapfile creation for these buffers. Regarding everything else, you can follow #1049.

This is exactly the change I did in my local working copy to prevent the swapfile explosion. This is a quick band-aid, but the performance implications are so severe, I prefer to use my local version with those changes reverted, because I am not willing to trade my workflow performance because of half-baked changes in nightly Neovim, introducing heavy performance regressions. I already saw, that Orgmode was not the only plugin affected by this.

Would it be possible to maintain a version for non-nightly users of Neovim, which doesn't switch to the scratchbuffer-based solution? I would expect most users of Orgmode are not running nightly Neovim. And we affect users of stable versions quite heavily by a patch which basically works around a bug in nightly. This feels a bit against my values of proper software maintenance. And I don't know, how long it would take to reintroduce a string-based treesitter parser.