Fix annoying max open files for Emacs

is this also your post https://github.com/d12frosted/homebrew-emacs-plus/issues/487

> the max open files of macOS has been changed to 1024, which is too small to develop with LSP in Emacs. Wow. i haven't yet done anything more than play around with LSP in Emacs, but i find this quite startling. Why does using LSP require so many *open* files?

The issue is not opened by me, but the post in that issue is written by me, but in Chinese, I translate it to English manually in my blog

Depend on how many projects you develop at the same time. LSP will open every dependency file to analyze, so opened files will beyond your expectation.

Parsing package trees can pretty much explode in your face :) Just have a look at what happens in your node\_modules folder when you install a simple nodejs package.. And that's only for libraries.. When completing variables and function names, it gets even worse.. The alternative would be to index your source code, but then you're looking at complaints like "I'm off for an early lunch, I just opened $BIG\_PROJECT in IDEA for the first time" :) It's somewhere between design choices and implementation details :)

\*nod\*

\*nod\* Makes sense, thanks for explaining. i hadn't considered the 'combinatorial explosion' issue; this Brave New World of massively broad and deep dependency trees, as in the JavaScript and Rust worlds, is still quite astonishing to me. (i don't do JS dev, have only ever submitted one trivial patch to a Rust project, and only have nodejs on my system because it's pulled in by the `firefox` and `qtwebengine` packages.)

I think, most people have an idea of what dependency hell in nodejs looks like and that makes it a good example :) I can still laugh out loud, how believable [this story](https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558) is :) But that's just for the classloader, that's relatively simple, you usually just need a package name.. It's a lot more complex for a language server, because the library is only the beginning.. it then needs to look up variables(and their types) and functions(and their signatures) from all these libraries :)

Thanks for the post! I had previously been using `file-notify-rm-all-watches` as a workaround, so I'm looking forward to trying a more permanent fix. u/jiacai2050 I did notice a copy-paste issue in your quoting of the `select(2)` manpage: > The default size FD_SETSIZE (currently 1024) is some-what somewhat what smaller than the current kernel limit I believe "some-what somewhat what" should be replaced with just "somewhat": > The default size FD_SETSIZE (currently 1024) is somewhat smaller than the current kernel limit

How exactly is this related to Emacs's open file limit? The language server is an external process.

Thanks, fixed.

There was some relevant work done in May of this year: Robert Pluim has a feature branch (feature/more-fds) in which you can switch to using `poll` instead of `select` and get a maximum of 10 * FD_SETSIZE files open a time. See https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00115.html I tried this with my lsp-mode workload (a large monorepo of mostly Node packages) and found that Emacs simply became unresponsive.

Heads up that it’s still not _quite_ right. There’s an extra “what”. > is somewhat what smaller should be > is somewhat smaller Again, it’s a minor nitpick. Pointing it out just in the hope that doing so is helpful, not to try to detract from the excellent post. :)

Ooops, fixed again. 😃

LGTM!

> https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00115.html Thanks for the link, will include this in my post.