Which packages do you want people to work on more or add features to?

Could be built-in or in elpa/melpa

is it time to break lsp up into separate packages instead of one giant one? e.g. some base infra + individual languages? an lsp update with a native compilation binary is a big hit.

I can list things I have issues with, but it will always be that "if I really cared I could fix it for myself". Such is the power and guilt of Lisp. Feature development should be done by people who care about the feature and know what they want. This is the primordial incentive. If you have built everything you want, congratulations - you have achieved success. If you have been given everything you need, congratulations - you have been granted salvation. If you want nothing, congratulations - you have achieved enlightenment. That said https://github.com/alexluigit/dirvish is amazing on one of my computers and broken on the other so if you could fix that and let me know please do.

> some base infra + individual languages? That's exactly what's currently happening, *i.e.* lsp-mode/eglot/... once, then one server per individual language. Or did I misunderstand you?

Maintenance on non-LSP language support. Basic syntax highlighting and indentation shouldn't require running an external process, and actively don't want most of the rest of the LSP functionality about 80% of the time.

Selfishly I want autocompletion for tables/columns etc for working with sql-ms or lsp-mssql, preferably for multiple databases concurrently. Only somewhat less selfishly an optional SQLite back end for org mode and cleaning up so e rough edges (like not being able to clock in to file level property drawers).

Would love to see dynamic tiling for EXWM. Something like Edwina, but I had trouble with it. Also, just less buggy EXWM in general.

My vote is also for EXWM, it is great and my daily driver, but it has lots of bugs and improvements.

Tree sitter is going to be a game changer (merged to master within the last few weeks and will be part of 29.1). Font locking, indentation, linting, checking and intelligent navigation all coming with modes supporting tree-sitter (which is where they will all be going) \*and\* it will be much faster than it is today.

package.el: async refresh.

I'd love for eglot to support multiple simultaneous language servers like lsp-mode does. The author has mentioned it before: https://github.com/joaotavora/eglot/issues/90#issuecomment-443906068, I just don't have the time.

Thread workaround for exwm. I know you can't just add threads to Emacs, but even without parallelism, something that fixed the "emacs froze so the whole desktop froze" would probably get me to use exwm.

Lsp already has this, with the UI separated from the core package

Development pretty much stopped on neotree two years ago leaving only treemacs to provide a decent project tree view. Honestly, I’d like to see a lot more work on speedbar since it’s already built-in, but at this point I’d take anything in this space because it’s all pretty much a dumpster fire.

does it already support imenu? for some reason when i try it i can see the AST with the debug view in a json file but no imenu support when i M-x imenu

Caveat: this is recency bias. Based on the 9.6.0 release, I'd like to see more comprehensive testing for org-mode releases. It had at least two significant bugs: * some people installing from ELPA had an issue starting org-mode. I'm not sure how difficult it would be to write a test for this. * The integration with R sessions in 9.6.0 is buggy. Unlike the previous one, this should be a simple test to automate. **Note:** it's not so much R specific but additional testing for the language integrations in general. Put another way: I don't really want additional features but I **always** want existing features to work reliably.

It's supposed to support imenu but the answer is "it depends". Currently, there is a separate tree-sitter project in addition to the support merged directly into emacs - and they are not compatible. So this is what needs to happen: 1. despite proper support having merged into emacs master, it's still not final - it needs some additional work which is currently happening 2. various modes shipped with emacs will have out of the box support for TS through emacs master 3. the separate TS project supports \*other\* modes and the 2 cannot co-exist (yet). They will need to be ported to support the proper TS functionality in emacs and that project will cease to be. 4. other modes will have to gain support for TS, which is also work in progress So to answer your question, emacs 29.1 will ship with proper TS support for some modes (quite a lot of modes actually) which will have imenu support. All new modes added to emacs will \*have\* to work with TS instead of using regexps. All existing modes shipped with emacs will in all likelihood gain TS support at some point.

The yasnippet package might need some maintenance help as the github repo was last updated over 2 years ago.

Dap-mode could use some polish. The initial setup is quite rough, the default configs did not work out of the box for me (both for cpp and firefox debugging) But the base code does work well. If I had some time i'd love to contribute

You should hunt down every single package blocking Emacs and fix it instead or replace it with a non-blocking alternative. Unlike the whole threads meme, this can be actually achieved and will help people.

As someone whom has only been using emacs for a year I never touched it for this reason alone

\`jupyter-emacs\` hopefully not too niche, but I have started to depend on it for my work.

[deleted]

This is selfish because I work through tramp all the time, but more packages with good tramp compatibility/performance. Magit is almost unusably slow under tramp, and lsp-mode and dap-mode don't work at all, clang-format only works with hacks. I'm not sure if the fix here is tramp or the packages using it. However, eglot's amazing support shows it can be done.

Can you elaborate on the former? I’ve been working on some stuff that you might find helpful (that doesn’t really work right now, but maybe soon)

I was coming here to say paradox? [https://github.com/Malabarba/paradox](https://github.com/Malabarba/paradox) But that says that it's not being maintained. (I've been using it for years).

seems like \*dozens\* of language-specific files are part of the base. i'm asking for more granularity.

if it is currently happening, i wasn't aware of it. that's a good thing. i still see dozens of language-specific .el files natively compiled for every lsp update.

How does it compare with `ein`?

Emacs packages tend to be stable, and lack of recent activity is not a reason to ignore a package. (Pinging /u/fragbot2 as well.)

I wish **eshell** was ~~better~~ documented.

Out of curiosity - what is the exact problem that would be solved by increased granularity?

> *only treemacs* :-) What is wrong with treemacs? Isn't it better to have development concentrated on one good package, instead of 1000 small split efforts?

On GitHub there are a lot of issues in the tracker without any reactions. But this also means there are a lot of people using it and its current state can't be that bad, since then there would be a lot more pull requests or forks with more activity.

> The integration with R sessions in 9.6.0 is buggy That sounds like a problem that a small fraction of Org users (which is already a relatively small number of people) will notice, so your wish may be unlikely to be granted unless someone like you steps up to do it. :)

The short answer is that we all want everything. ***EVERYTHING!*** Why do you ask?

> if I really cared I could fix it for myself I'm not sure there. Sometimes I really care that TRAMP brings a significant latency multiplier to ssh connections, but I spent some brief time trying to work out what's wrong and what can be done, and quickly realized it would be a major project requiring getting deep into it, plus for me moving from crude elisp-hacker status to competent elisp programmer. I would actually like to do that in a perfect world, but I'm not even close to having that sort of time.

I'm also curious what is a dumpster fire about treemacs? This is not because I disagree; I'm genuinely curious. My occasional usage of it is trivial so I recognize I am not pushing its limitations. I have always got the feeling it's hackish internally (?), but that's nothing more than a feeling.

TRAMP is my first thought, and really my main gripe is latency. In my experience it has a latency multiplier of >10. On a 60ms ssh round-trip, opening a small file takes about 2s on a warm connection with ControlMaster active. First connection setup does multiple round trips (it seems to try every combo of `test` one by one to work out the remote capabilities). But I don't think that explains a lot of it. e.g. opening a file and watching the logs I don't see a load of round trips going on when tracing it.

But surely they're only loaded as needed? Are you worried about the disk space they use?

Also, isn't it bound up with `lsp-mode`, so a barrier to `eglot` adoption if you want its features.

i update my elpa/melpa stuff frequently, often many times during the day. a native comp rebuild of lsp is \*slow\* and cpu-intensive.

I have a tramp setup that consistently opens files in under two seconds and saves in under a second. The key was cutting out all the round trips. But, that is the crux of it, round trips stack up like this. Another mechanism could batch operations, or provide local like file watchers. Tramp is pretty brilliant in the fact that it has made the shell into your remote server, but shells can't have multiple operations in flight. A lot of people float the idea of a heavy weight emacs server on the remote, but I have wondered about making a minimal server just for batching the kinds of operations tramp does often. EDIT: To clarify what the minimal server could do. First, it would be fully asynchronous. Emacs could start an operation and then do something else. Or start another operation. Part of the reason (I've observed) that tramp seems slow is that it can't do more than one thing over an ssh connection. The operations would be pretty minimal, limited to file stat, monitor file for changes, read/write a file or chunk of a file, and start a remote process. File data should be able to be sent as is without base64 encoding. The server itself would be a tiny C binary, and communicate to tramp over ssh stdout, and its format would be structured to be parsed quickly. Not sure if the best method would be to ouput s-expressions to be eval'd, or json blobs to be interpreted by the native json handler. If json, this should just be a jsonrpc service like lsp, as that protocol already does all the asynchronous handling we'd need. In summary, I don't want to reinvent tramp, it is actually amazing at what it does. I want to optimize around its weakest points while leaving its current functionality as a fallback if this server isn't available. I would do this myself, but I have two toddlers and not enough time to do the job I already have. But it'd be a fun project.

Alternate idea. The key problem is multiplexing. We want to run a bunch of operations semi-simultaneously on the remote. We're currently doing that by running multiple ssh processes over a control master which is heavy and problem prone. What if the aformentioned server listened over QUIC, which has in built multiplexing? One control channel to start remote processes, and any number of multiplexed connections to get remote process output. The only drawback over the earlier approach is that its more complicated than a simple binary that gets started over ssh and communicates over stdout. It pulls in a dependency, both to the server and to emacs. But maybe this has the potential to make performance a non-issue.

Thinking more on this, the challenge would be security. This server is a walking attack vector. If it listens on a UDP port (because having it communicate over ssh defeats the purpose) it opens up anyone that finds the port to just run commands on the remote. And adding comprehensive authentication runs the risk of reinventing ssh and bringing all the weight of it back. This can be addressed but it has to be thought through very thoroughly. Aside, I have apparently been nerd sniped. I'm going to stop now

native compilation on two dozen language-specific files is a cpu intensive operation. lsp is under active development and often updates more than once during the day. i'm lazy. i'd be happier if i could subscribe to just the languages i use and have only those files be updated. to paraphrase gordon gecko from the movie "wall street" - "speed is good!" :-).

I have pretty much everything I want from packages. The only thing I'm *really* missing from emacs is snappy editing of big (250k lines+) files. But apparantly that requires throwing out a lot of internal machinery ( https://nullprogram.com/blog/2017/09/07/ ) and I'm probably the only person using Emacs this way :-/

> some people installing from ELPA had an issue starting org-mode That is something we keep seeing from time to time in different releases. It has been lurking years back and was partially fixed on Emacs side 6 years ago or so. Then, re-surfaced again with straight.el popularity (especially via Doom). Now, there seems to be an issue on Emacs side again (possibly known). The irony is that the ELPA error is partially because of our attempt to fix this problem. Should be better in the next release when that damn macro is available in both old and upgraded Org versions. > The integration with R sessions in 9.6.0 is buggy. Unlike the previous one, this should be a simple test to automate And that's why we have CI testing since recently. That said, we of course can use more tests. Please, step up and write some. https://orgmode.org/list/874k81bsvz.fsf@localhost Note that a test for this particular bug has been written already (alongside with the fix). https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=662e814bc067153c74aeba5f882d547e327db8b4

I am happily editing a 500k+ line file right now :)

Interesting! What emacs build are you on? evil/god/plain? What file type? Syntax highlighting or no? Fancy computer? I'm on a691e811e23dee48674e9e0716429074fdbe3d7b (from Mon Oct 31 2022; typically using an i7-7500U with 16G ram), editing XML files with nxml + evil. Turning off nxml and evil helps a bit, but even with -Q and fundamental-mode I'm seeing slowdowns as soon as I start editing very different parts of the file; I was told on IRC this was due to the underlying gap buffer representation that emacs uses and there was no way around it, but if you are happy perhaps I shouldn't give up hope yet :)

This is an Org file with custom Emacs config. Font locking on. Computer is reasonably fast (few years old; also Core i7 + 16Gb). Note that Emacs 29 has optimizations for files with long lines. Might be helpful for things like XML. Gap buffer should not be an issue. once the gap buffer is moved (you type one symbol), it should become O(1). So, you cannot see slowdowns when _typing_ because of gap buffer. If you see slowdowns with emacs -Q + fundamental mode, it is very likely long lines. Just upgrade Emacs. They solved this problem in Emacs 29.

[removed]

Thank you; I probably would've assumed it was just impossible if not for your comment. I tried upgrading and running with no plugins, and it's perfectly usable on my large xml files :-) In my full config I did have to disable rich-minority for it stay fast, though I don't understand why that package should have an effect on speed (dim.el was a fine replacement).

> In my full config I did have to disable rich-minority for it stay fast, though I don't understand why that package should have an effect on speed (dim.el was a fine replacement). Mode line packages can easily affect performance because mode line is updated very frequently. If a mode line package is careless about optimizing performance, Emacs may be running custom Elisp from that package every time the frame is redrawn.