On Sun, May 5, 2024 at 3:58 PM Stefan Monnier wrote: > > Is this really the final word on this whole topic? The current > > solution involves a one shot addition to `post-command-hook` in Eglot > > and is really ugly. Can you really really no better solution so that > > Eglot is only compelled to send changes to the server once > > track-changes.el announces it safe to do so (and gives the change to > > send while it's at it? > > Until we've gotten rid of all the code chunks that incorrectly use > `inhibit-modification-hooks` (which will take a lot of time since not > only we have to find them but we have to figure out why they used > `inhibit-modification-hooks` and then argue hard to get the change to be > accepted), I don't see a significantly simpler solution, no. 🙁 > > I mean, a simpler solution is to live with the performance bug, of course. > I don't know that this is a "performance bug". I mean, misleading the server, crashing it is only such a thing if one squints very hard. So while may be "significantly simpler" solution isn't in the cards, I still think some simplification can happen (I don't understand why post-command-hook needs to be used for example). Anyway, I would need to see the quil failure scenario encoded as a test in eglot-tests.el so I can have a clear shot at it. Should be possible, no? > > > Also, tangentially , can we get rid of the fboundp's and make the next > GNU > > ELPA version run the same code as Emacs master's by depending on > > track-changes.el GNU core? > > Yes, coming right up. > Thanks. That's great. It would also help to document your new eglot--track-changes-fetch. I'm afraid I've lost track of how the code is supposed to work after track-changes.el * why is :emacs-messup still a thing? By the way did :emacs-messup solve this very problem too via a full resync? * what exactly does the local eglot--track-changes do and why would it be re-registered in the same buffer (why isn't the typical add-hook enough). * There seems to be a track-changes.el signalling function and the longstanding LSP signalling function that informs the server of things. Why can't it be the same function, i.e. why can't Eglot tell track-changes.el to call Eglot's function when track-changes.el knows it's a safe time to call such a function? The flow of information via the eglot--recent-changes variable is complicated and would seem not worth bringing in track-changes.el at all. Is it only to accommodate Eglot versions when track-changes.el isn't available or is there some deeper reason? > > Also also, can you fix indentation in the function that you recently > > touched in Eglot? (same goes for Philip, but I'll contact him > > separately). > > Hmm... hadn't notice anything wrong. Will take a closer look, thanks > for the heads up. > Not serious, it's just I was misled by the misindentation when reading one of the new if's, thinking it only had a then branch. João