.emacs.d VS esup

In my Helm, I have to actively choose the candidate to confirm it. So I can type in both paths that are shorter or longer then existing ones. I even made a video to demonstrate it, the thread was relatively recently up I think. My Helm setup is here it if helps you, find Helm in the list of packages.

I also use Helm, and I have no problems. Just keep typing, once you typed a letter that does not exist in a path name it will stop completing. I don't know if I have some special option enabled/disabled; I don't think you need it, but you can see my Helm config (just scroll down untill you find "Helm").

When all deps are installed,my config is over 200 packages. On my Arch Linux desktop I built in 2016, with i7 4.6k (haswell) it starts ~0.7 secs, but init time will be anything between 0.5 ~ 0.8 secs, i guess depending on what system does. So all things same, init time will vary.

I am using it in my literate org-config. If you scroll down, there is a big list of packages, and I have done a small wrapper around helm-imenu, to jump to a package configuration. Looks like this.

That does not work for completions, at least not for me. It works for keymaps, so you can have mode specific (or really any) keymap in src blocks. I have been using his method myself in my init file generator for quite a while now. If you (or anyone) knows/have an idea how to expand it for completions and eldoc, I would be really happy to hear.

I don't know what if it is more robust but I use more or less plain dired with just some options turned on to make it less noisy to look at, but I don't "manage" my files so much to be honest. I do use some extras from dired-hacks, and my own dired-auto-readme, but that is about it. You can check my setup if you wish, look at "dired" under packages and in Lisp folder for "dired-extras.el".

I personally put all custom lisp in a special directory and scrape autoloads myself. If you are curious, you can check under "generator", functions generate-autoloads and collect-autoloads, but there is nothing special, just plain text search and copy-paste programmatically. I don't recommend to use it though.

Probably the best way to figure out what's going on at startup time is ESUP (Emacs Start Up Profiler): https://github.com/jschaf/esup You could run it on the old config and the new. Although I suppose the processes may be different enough that there's nothing meaningful to compare.

I agree with you. For startup profiling, use-package-report and https://github.com/jschaf/esup can help too.

A very useful tool for achieving faster startup is esup (https://github.com/jschaf/esup) which times each code block that runs in the emacs startup.

Have you tried running M-x esup with https://github.com/jschaf/esup to see what is taking up the start-up time?

Are you on Emacs 28? Native-comp is enabled by default and it's Just Worked™ for me. Or are you on at least Emacs 27? Emacs 27 added native JSON parsing; stuff like lsp-mode works a lot better now.

(Personally running Emacs 29 built from source on an M1 Pro; everything is instant! Even on my old dumpy i5 machine, everything except startup was pretty snappy, with the exception of startup which took ~4 seconds.)

If it's startup you're concerned about, try the esup[1] package to figure out what's taking so long.

[1]: https://github.com/jschaf/esup

If you're really interested what happens on startup, you can play around with the startup profiler( https://github.com/jschaf/esup ) or similar packages that time the execution of your .emacs.

I used the Emacs Startup Profiler (ESUP) https://github.com/jschaf/esup which identified several culprits in my init files. Removing or deferring the loading of those packages took my startup time from ~15 seconds to about 2.5 seconds. (Still room for improvement!)

GitHub - jschaf/esup: ESUP - Emacs Start Up Profiler

Try out esup