[choeger]

I entered this at the end:

  Emacs is a good text editor and I run it for every text file I read or write. As a text editor however, emacs can never handle things like project-management, software development and testing in the same way as an IDE. Yet, it has all the features of an IDE available in some melpa repository. Unfortunately, one is always forced to configure the editor and tweak it here and there to get maybe 80% of what would be possible. And then your settings break your workflow in *that other project* or for a simple plain file. Emacs should finally acknowledge that projects are a thing and support them out-of-the-box.

  I would wish for an emacs daemon that considers itself responsible for a single project and manages the language server, version control, compiler and all the other project settings. Whenever I open a file in the scope of that project, the daemon should then configure my emacs instance accordingly to work well in the context of that project.

[cjauvin]

I manage all my projects using a constellation of flexible (and hand-picked) tools it offers: magit for versioning, Org for documentation, note taking and time tracking, blacken, isort and prettier wrappers for my code formatting, ivy, counsel and dumb-jump for searching stuff and moving around, and I could go on and on. I understand that Emacs doesn't feel as "modern" as PyCharm or VS Code in a sense, but I don't think the "it's not an IDE" argument holds. It can be (if you want and take the time for it) a very powerful IDE, customized to exactly your needs. It can also be a lot of other things in addition. It's a difficult to classify tool, in a category of its own.

[BeetleB]

The problem is that everyone wants something different in an IDE (and the same person often wants different stuff depending on the language they are programming in). Whatever default Emacs can provide will be suboptimal for most users and cause additional dissatisfaction. People have a more open mind when when they know it doesn't include an IDE and may have to work to get one up and going than if they simply see the default one and think that's the best they'll get with Emacs.

To give you an idea, I used Emacs as a programming editor for a decade, and only about 2 weeks ago did I first set it up as some kind of IDE (or rather, I just installed elpy and it did it all for me). I was perfectly happy without using it as an IDE - knowing the constraints that come with it.

[DoingIsLearning]

> and I could go on and on.

Please do, I just learned about dumb-jump, any more suggestions of things that worked for you?

[cjauvin]

Some other packages I can't live without: expand-region, git-link, pass, treemacs, vterm.

[ywei3410]

Have you tried Lispy [1] and it's derivatives (Lispyville if you're a vim user)? It single-handedly changed how I felt about Lisp editing.

[1] https://github.com/abo-abo/lispy

[d0mine]

It looks like we have a similar taste in packages. Would you mind sharing a link to your dot emacs?

[Jtsummers]

If it helps, maybe not the solution you want but what I do:

I launch a different emacs server for each project I'm working on, and make any modifications necessary there. Usually I only have one project per language open at a time, but suppose I have two lisp projects (unrelated) and don't want a cluttered up set of buffers that all look almost the same (by name, some getting a number appended if they were the second opened). I'll launch a named daemon from inside the project's root directory (emacs --daemon=foo, or with my .zshrc it's just emacsd foo). Then I can access it using emacsclient -s foo (or e -s foo with my .zshrc).

If you really want it customized per project you could probably add some logic to your .emacs file or elsewhere that would run custom elisp per server, maybe check to see if the directory it was launched in has a .emacs file and evaluate that.

[testaccount119]

> maybe check to see if the directory it was launched in has a .emacs file and evaluate that.

Yes, or use .dir-locals.el like civilized ;)

[Jtsummers]

For others:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...

Good to know, I've used file local variables but never thought about directory local variables.

[pmoriarty]

"one is always forced to configure the editor and tweak it here and there to get maybe 80% of what would be possible"

What specifically do you think is lacking, apart from having a ready-made IDE out-of-the-box in Emacs?

[zests]

Specifically, emacs is lacking up to date examples of how to do basic IDE functionality with emacs 27//28 and 2020 versions of packages. I don't think someone can build their own IDE without being an emacs intermediate and/or already immersed in to the emacs community.

Can you find me an example of a modern emacs config that creates a barebones python editor that does code completion and isn't significantly slower than jetbrains code completion? Most of what I can find is significantly out of date or just doesn't work. If its not possible or easy to find some barebones skeleton to build off of, I think the editor as a whole is too difficult to be worth using.

I tried doom but got something slower than jetbrains that also didn't work. I haven't yet found the time to invest into debugging/retrying. My next attempt will probably be me restarting, spending a few hours reading about how to use/debug packages and also getting something that does not really work. Is this really worth it?

[MikeTheGreat]

At one point I was trying to get emacs server to work, so that I wouldn't have to wait a long time for emacs to start (to be fair, part of the problem was that my config file had a pile of stuff in it that I didn't really need). After spending waaay more time on it than I really wanted to I got it working here on MS Windows.

Of course, since MS Windows doesn't have emacs daemon processes one needs to keep the emacs window open in order for it to be used to open more files in the future.

In other words, I spent a ton of time to set up emacs so that when it's already open new files will be opened in that already running instance.

On the one hand it was kinda fun to fiddle with and I was happy when it was done. On the other hand I spent a ton of time getting something to work that most other editors do automatically out of the box.

In a way that kinda sums up my experience with emacs - fun to fiddle with, but takes a lot of time to set anything up.

That said, org mode is awesome, and like single-handedly keeps me using emacs :)

[Jtsummers]

I'm curious what made it so fiddly. I set up emacs server on Windows maybe 6-8 years ago so perhaps I've forgotten a lot. But as I recall I just made a shortcut that would send the right command line arguments to emacs on launch, and a second one that I used for the client.

[MikeTheGreat]

This is gonna sound dumb (because it is :) ) but it took me a while to realize that on Windows there's no daemon process so you gotta keep the emacs window open.

I kept closing emacs and expecting the next startup to be super quick and it wasn't. It was clearly starting up from scratch again.

I think the server stuff on Linux / MacOS does start a daemon, but I spent a bunch of time trying to get it to work (quick startup with no visible instances) before I happened to read that one needs to keep the first instance open on Windows.

Separately but related, sometimes emacs doesn't remove the text file that it uses to figure out if there's already a server running or not when it exits. Any further instances assume that another instance is the server and they don't take over as the server themselves. Thus, the zombie text file ensures that the server functionality stops working until you delete the file yourself, manually. I was half thinking about writing an emacs function to check if the pid identified in that text file is legit (i.e., is there a running process with that pid?) and if not then delete the marker file. Somewhere around there is when I decided I didn't want to fiddle _that_ much with my editor :)

[Jtsummers]

Yeah, on macOS and Linux it starts a proper daemon. On Windows, I used org-mode so heavily that the idea of closing it during the workday usually meant I was preparing to reboot for IT's 25th update push of the day.

I actually do recall the lock file not being deleted properly a couple times. It didn't happen often, probably why I had mostly forgotten about it.

[BeetleB]

> In other words, I spent a ton of time to set up emacs so that when it's already open new files will be opened in that already running instance.

Isn't this just a matter of associating files to the right Emacs executable (emacsclient)?

[MikeTheGreat]

It's been a while and I've forgotten a bunch, but I think I tried that and it didn't work. Maybe there were some command line parameters, so I needed to associate it with a batch file.

Plus, I wanted to press the Windows key, then type "emacs" and have that work.

I'm probably doing it wrong, but i couldn't find clear, easy, step-by-step instructions for doing this otherwise.

[choeger]

Integration. If I want to open emacs inside a Cmake c++ project, everything it needs is already there. But I have to configure all the tools myself. Then I switch to a python project and the same stuff has to happen again.