emacs without packages?

I’ve been using emacs for about 2 years now and I’ve always relied pretty heavily on packages. Is there any reason to not use external packages and instead just work with and customize the built in functions and features?

Back in the day before emacs packages existed, we used to trade raw elisp files and keep them tucked in our ~/.emacs (or somesuch) directories, followed with personally crafted loading and configuration. It was kind of fun but I'm grateful that I don't have to do that anymore. We have package-management. To answer your question, unless you are enjoying the emacscraft or are working in a restricted/airgap environment, in my opinion, the answer is no.

One argument would be that built-in features are more likely to continue being maintained. There are more people working on Emacs itself than any external package I can think of. And there is constant public discussion around its development. But there are a lot of really excellent and useful external packages. The idea that one should draw a hard line against using any of them seems contrary to the philosophy behind Emacs.

Jesus I can't imagine living without helm.

I only used built-in packages for about a year or so (other than installing major modes with package.el) and it was honestly quite usable, but there's definitely a small handful of packages that just offer massive value -- Magit being the clear first among them, and probably a completing-read replacement (ido/icomplete/fido exist, but IMO are greatly improved upon by pulling in something like [vertico](https://github.com/minad/vertico), probably the most minimal completing-read replacement I'd enjoy using). Other than that, combing through my config, I honestly don't see anything I absolutely *need*. That's a small enough set of dependencies for a emacs config that you could pretty easily just vendor the dependencies into your user-emacs-directory for sure, but I imagine the main point of difficulty would be having to vendor in the major modes for every programming language you want to work in that doesn't have a major mode already built into emacs -- definitely doable, probably quite possible to make easy with a bit of automation, but probably easier to just use a package manager for.

This might be out of the scope of what you want but I guess I'll say what I have to say, Instead of confining yourself to work with the built-in features, why don't you extend Emacs? The built in features won't give you everything you desire, it'd be a good exercise for you and you'll get to expand your Elisp knowledge instead of **presumably** roaming around in the dark and having to rely on external packages There's nothing wrong with using packages but if you have a package that you use quite often, maybe try making a clone of that package, obviously not to make a competitor package but as I've said before, as an exercise for you. The only external packages I have installed and use intimately in my code are restart-emacs, f, and org-bullets

Agreed. There's no way i want to go back to the days before Emacs packages; i much prefer not having to manually check for updates to individual files or file collections, and then having to manually do each update if necessary. Whereas doing regular bulk updates via the package system is trivial. (That said, i also feel no need to move across to a prepackaged configuration - after using Emacs for around 25 years, my config sets up Emacs for my needs/workflows, tweaking it is not an end-in-itself, and i mostly only make changes when using a new extension.)

There's a lot of functionality in packages that doesn't exist in the core, so if you need lsp-mode to do your job, it might not be a good idea to try this at work. I think it's an interesting experiment, and would encourage any Emacs user to try it — keeping in mind that it's an experiment. Emacs ships with *a lot* of stuff, and plenty of folks (myself included) used it for years and years before any of the crop of impressive, modern packages existed. In short, I think it'd be a good exercise to better understand how Emacs works, what comes with it, and how to make that do what you want. If you have the time to explore that, I think it'd be a positive experience. Even if you go back to using a bunch of packages, you'll have gained a better understanding of Emacs itself.

Emacs is all about being customizable, and Free/Open Source software is all about sharing work. So I'd say that packages are about as Emacs-y as it's possible to get! :)

I would guess a good reason may be generalization for a wider audience (to more easily allow a peer to get things done on your machine) but that is a tricky one to deliver on (even even possible). It seems that different users will find different similar packages serving their needs and peculiarities. I need evil mode, coming from vi* like editors and having developed a bad bout of "Emacs pinky" in college but many of my colleagues don't share that history or pain. Without packages, I would like be a bit less optimal in my use of Emacs and perhaps so much so that I could have spun up Neovim more often than I do now which would be a bit of a loss. I think that Prot goes about this from an interesting angle: trying to use packages mindfully and under the precondition that they use built-in Emacs facilities (like the completion system) well to simplify integration. Another reason may be lumped into stability/longevity of a config. But in the same breadth one can argue that the use of packages may be helpful for continuity/longevity of the ecosystem/evolution: some stand-alone packages find themselves evolving to the point that they become almost core parts of the ecosystem. Your use of different packages may lead to bug tickets or patches from your end that make the ecosystem better. Who knows how these things influence core Emacs -- I wouldn't even know how to characterize what core Emacs is? Org-cite may be part of core Emacs now but I would argue that Kitchin's work on Org-ref has helped shape that package. Furthermore, different packages can compete and survive each other for reasons that are hard to anticipate. For this reasons, it may be helpful to try another tool once in a while to figure out if it offers some gains that you've been "missing". Feel free to find your balance. Somewhere between the minimal wasteland of default Emacs and a makeshifty convoluted cockpit with many bells and whistles would be a good place to optimize for. Pick your place on that spectrum depending on how much of a minimalist or nutty professor you are from a personality perspective. 🤷🏿‍♂️ I keep mine relatively "light".

Yeah, working with built-in features helps you appreciate external packages more and you might find scenarios where built in functions work better. You can also find new modes or functions that work with your packages too. I usually work with Ivy and counsel functions but I found out that when working with big files I got faster queries with the classic find file.

> Is there any reason to not use external packages and instead just work with and customize the built in functions and features? no

For many years I only used built-in functions and barely even customized anything. I had a short .emacs file with just a few lines of configuration. Anything more than that and I was afraid that I would get too used to my settings and confused when working with plain unconfigured emacs. Then in 2013 I created a .emacs.d git-repo. Best thing I ever did for my emacs use. Makes it trivial to get emacs configured the way I want to. I have that repo cloned on all computers (and phones) where I have emacs installed. There is a bit of if-else logic in the file to make it work with a wide range of emacs-versions (like when I use emacs in FreeDOS and am stuck with something like emacs 21 because I failed to get the newer versions to run, but I still want the same configuration to work). For a few years I used packages installed from elpa/melpa/whatever, but I realized If I am already syncing my .emacs.d to everhwhere, I can just put all the code I need in that repo. So I just started pulling in all the packages I use, either as files in my git-repo or as git submodules. I only upgrade a package when/if I want to, and I know that the exact same version is everywhere (or versions, for when I need to keep multiple versions of some package to make all my emacs-versions happy).

Sure. And don't install any programs on your OS either; just write what you need yourself. </sarcasm> Seriously, I get the impulse. But no, it's better to stand on the shoulders of the giants of the emacs world.

I seem to recall that Prot has recently been on a mission to use only built-in search and completion, with a view to identifying any advantages and any really significant gaps compared to the popular packages and either raising RFEs or sending patches to improve the built-in packages if needed. Of course Prot doesn't frequent Reddit, for what I'm sure are good reasons, so... anyone else remember this?

I don't think of needs to be binary. There are many packages that work with built in functionality and improve them, instead of reinventing the wheel. Vertico, corfu, templ, embark, paru and eglot all come to mind being smaller, lighter packages that build on built in emacs interfaces. Add to that quality packages within core such as flymake, electric and so on. You can get a very good and modern experience. A shift in focus from *only defaults* to *preferring defaults* is a better way to think about how to go about configuring emacs.

>tweaking it is not an end-in-itself You what now?

Messing around with my Emacs configuration is not an end in itself. i only change it when i need to, e.g. setting up my preferences for a package i've installed.

Miraculous

Y'all're talking about the days before package.el like it's ancient history, and I'm thinking "it wasn't *that* long ago, 3 maybe 4 years?" and holy crap it was more than 10 years ago (24.1 on 2012-06-10).

I think there are good reasons to avoid package.el specifically; I have all my 3rd-party code included directly in the git repo for my dotfiles. The problems with package.el aren't as severe as they were 5 years ago when I started doing this, but package.el (especially with melpa) still does encourage you to install code you don't have a good reason to trust, and it installs it in a way that doesn't encourage you to review it before using it. Worse still, while there is review on packages when they are first uploaded, new versions don't have any review, and it's not common to lock to specific versions so when you check out your dotfiles on a new machine you have no idea what you're getting. So avoiding 3rd party code altogether is giving up a huge part of what makes emacs great, but IMO there are good reasons to handle its installation by hand using git.

When I started with Emacs I was afraid to make my configuration too complicated by adding extra packages, but couldn't resist the goodies and so my Emacs went bankrupt a couple of times, until rebuilding & reorganizing my Emacs config became easier and more fun & fruitful, mostly by generating it with org-mode. I prefer to first learn what Emacs already offers and sharpen the available tools but still struggle with elisp so that I still use a lot of online found code and packages, with the primary [try](http://github.com/larstvei/try), a package to try new packages without installing them. Although installing a new package is often more fun than buying new clothes or furniture etc. do I still think twice before doing it because each one requires reading & remembering new info, and extra configuration that often interfere with other stuff. More than once I forgot an installed package or configuration and asked silly questions why my Emacs didn't do what I expected. After reading \`info Emacs' again I could replace some packages with better configurations of onboard features, that spares me from endlessly reading new info after each package update. Important for me to keep Emacs manageable. When some time ago the developer of Helm announced to stop supporting it, I was scared to loose one of my most important tools, but switched easily to Ivy, and now use both, although Helm rarely and with minimal config. For big configuration changes do I use [Chemacs](https://github.com/plexus/chemacs), for example for my "writers-configuration" [Nano](https://github.com/rougier/nano-emacs). So I prefer to avoid adding to much furniture to my Emacs, but love to change my interior once in a while.

It's certainly possible, but stuff like consult, vertico, marginalia, corfu and [cape](https://github.com/minad/cape), [shackle](https://depp.brause.cc/shackle/) are just nice. Because, well, I'm too lazy to try and make it myself. Shackle especially out of these, but I don't feel like messing with `display-buffer-alist`. I also don't really feel like figuring out stuff for themes for Emacs. There are stuff like [highlight-numbers](https://github.com/Fanael/highlight-numbers/blob/master/highlight-numbers.el) and [hl-todo](https://github.com/tarsius/hl-todo) that I could find a way to write myself, though.