I don’t know what is the problem with cl-lib been loaded in Emacs core. RAM is cheap nowadays. I am loading the entire cl-lib in my Emacs when I build Emacs, no problems noted (been doing this for a while):

In my loadup.el I do this:

;; This file doesn't exist when building a development version of Emacs
;; from the repository.  It is generated just after temacs is built.
(load "leim/leim-list.el" t)

(load "emacs-lisp/gv")
(load "emacs-lisp/pcase")
(load "emacs-lisp/easy-mmode")
(load "emacs-lisp/cl-lib")
(load "emacs-lisp/cl-seq")
(load "emacs-lisp/cl-macs")
(load "help-mode")
(load "emacs-lisp/cl-extra")

In conjunction with this, I have also patched cl-lib.el to remove some unnecessary loading when bootstrapping:

(provide 'cl-lib)

;; (unless (load "cl-loaddefs" 'noerror 'quiet)
;;   ;; When bootstrapping, cl-loaddefs hasn't been built yet!
;;   (require 'cl-macs)
;;   (require 'cl-seq)
;;   ;; FIXME: Arguably we should also load `cl-extra', except that this
;;   ;; currently causes more bootstrap troubles, and `cl-extra' is
;;   ;; rarely used, so instead we explicitly (require 'cl-extra) at
;;   ;; those rare places where we do need it.
;;   )

The reason is I just prefer to have it in loadup.el explicitly so I can see it and comment/uncomment if need be, instead of perhaps forgetting cl-lib.el does it on the bootstrap.

You can make those as patches and apply patches automatically when building Emacs.

File mode specification error: (file-missing Cannot open load file No existe el fichero o el directorio cdlatex)

The problem is probably elsewhere in your config. Something somewhere is loading cdlatex, which you seem to be missing; soy no hablo Español, but I think that is what the error says.

Either install cdlatex package or fix your setup. Read the manual, about cdlatex and one that comes with org mode. You probably need to sort out your requires and package loading. Have you tried to run Emacs with --debug-init flag?

but the snippets seems to work !

Because cdlatex is not needed for those snippets to work?

Is this even “viable”, or advisable? Should i be looking at common lisp instead? Or would you say that’s a pretty dumb idea and i should rather learn it in a different way?

You could have just tried any of previous years of AOC. Just go to their webpage and start doing them.

You can do them in both elisp or cl or any other programming language, including bf. I think elisp works rather well for AOC, but it will really depend on your skills.

You can look on their reddit and see if you can find elisp solutions from previous years to see if anyone has done some AOC challanges in elisp.

How you will learn elisp depends on you. If you are discussing about learning it, you ain’t learning it, you are discussing. Programming is very similar to learning a new language, playing music or learning any other new skill. Just go and do anything, and you will learn something.

How can I become a more “proficient” Emacs user?

Just use it. It is that simple.

I also suggest being patient and looking up the documentation and the built-in help whenever you have a problem.

Don’t fall into some of the common pitfalls I see people here do often:

Don’t insist on super customized Emacs according to your liking from the early beginning. Be patient, and do stuff Emacs way, or live with some more irritated moments, and leave minutiae customization for later, when you are more familiar with Emacs. Emas is to be customized by each and every one and bent to your needs and personality, but it may take some deeper knowledge of Emacs in some areas, so to save yourself some frustration and lots of time, proceed gently at customizing Emacs in the beginning. This will probably be a somewhat controversial tip for some people, but what I mean is, prefer to do the work you have to be done, over how you do it in Emacs. In the beginning, bend yourself around Emacs, and keep in mind, that the more you are used to Emacs, it will be easier and faster to bend Emacs around you.

Yes, there are many tips and stuff accumulated on the Internet, but you can not learn everything at once. With the amount of information available, it is probably better to concentrate on using Emacs to do your work, and focus on exploring only those topics that give you the most in terms of how you perform your work; for example to solve some very irritating thing or to automate something, etc. You don’t have to start using Emacs for everything immediately, let it come with the time as you are getting more and more used to Emacs. What might be a killer feature for someone, might not be a killer feature for yourself.

Being popular does not always mean very good. Popularity goes in waves. You can spend all your time just re-learning “popular” frameworks and things. Instead of focusing on which package you should use for this or that; choose one and just use it. Once you find some true shortcoming that irritates you, than look for another package or for tips on how to change it, etc. If you are using Doom, I am quite sure they have already included something that is good for most people. I personally just use whatever is default in Emacs and have had no issues with it; for like 25 years now, or something there and counting.

if you have to understand (exactly) what is happening under the hood of an abstraction in order to use it correctly, then it’s not a good abstraction.

Nobody says you have to understand it exactly, but you have to have an understanding of what is going on. You also have to have an understanding of the abstraction itself, of what are you using. Have you even read the use-package documentation? I don’t recall ever that use-package was meant to hide away the Emacs itself, but to help you write more structured setup. If you don’t like it don’t use it, it is not harder than that. I don’t use it myself. But your problem is neither Emacs nor use-package. I personally can’t care less if you use or not, but you are now blaming the missunderstanding on external factor. Lots of people are using use-package and find it useful. Perhaps you should reflect over if it is the software or the user :-). I don’t mean to be impolite or arrogant, but sometimes things feel difficult when we are not ready for them. Nobody promised that use-package should be trivial, albeit I personally don’t think it is very difficult tbh.

You have two packages: X and Y. You want to do something with Y if X is loaded, but sometimes you want to just “jump” into Y without loading X, and than wonder why your X based setup will not load. In Emacs your vanilla option is to always load X whey you load Y, or cook your own thing. In your particular example, your option is to load project.el whenever you load Magit, it is not harder than so. Just require package.el in your Magit configuration.

requires me to more-or-less just macro-expand all of my declarations to see what they are actually doing.

Welcome to Lisp :-). You can compare that to C++ where you more or less have to look at assembly output if you care about efficiency and what your compiler does behind your back. I think you should actually be thankful you can do that. Try to do that with Python, JS or you name it.

The fact that so many people struggle with it gives credence to this as well.

I would rather care how many people do not struggle when looking at the big picture of how many people actually use use-package.

Frankly, Emacs is complex and complicated.

Sure, but so is any piece of software that does non-trivial tasks. If you find Emacs too complex and complicated, to the limit that it causes too much frustration and time loss, don’t use it, nobody is holding your hands.

It has lots of legacy baggage and idiosyncrasies

Sure, I agree. I personally use to say that Emacs is a hack over a hack. And I am really surprised how well it runs and does what it does, how hacked together the source is. But is to expect of 50 year old software. It is developed by many people with different backgrounds and different goals, mostly by hackers who just wanted to bend Emacs to do their own thing. It is a hackable editor made for hackers.

I would expect people to get their with-eval-after-loads wrong or their keybinding syntaxes wrong

I wouldn’t. Mostly because those two particular things are incredibly simple to get correct.

use-package seems to hurt as much as it helps

I think it is individual. What you did wrong in your example is that you haven’t required project.el in your Magit configuration. Do it and your problems will be gone. Simple. Nothing wrong with use-package.

I can also tell that you can just use with-eval-after-load and mode hooks to achieve the same lazy setup if you prefer not to use use-package. I don’t think it is that hard; I have done it myself and I was not even an experienced Emacs user or Emacs Lisp programmer at that time.

I can understand your frustration; I have been there myself, and my best tip is: start reading the documentation and built-in help. It is a best first step towards understanding Emacs or user-package one can take.

I think your problems are due to not understanding how Emacs works under the hood. To me, the only problem with use-package is that it hides those details and makes people learn a DSL that use-package is, instead of learning simpler mechanisms of with-eval-after-load and hooks which are used to implement the functionality of use-package under the hood. In past years I have seen many questions here on Reddit and on SX related to use-package because people don’t understand Emacs under the hood. But that is about it; I see no other drawbacks than that.

Personally, I have stopped using use-package after about 2 ~ 3 years ago. Been using it for a few years before that. The reason why I abandoned it was actually because I wanted to learn how such a thing was implemented and how Emacs worked under the hood. Another reason was that use-package was not included in Emacs back in time. However, I am not going back to use-package, just because it got included. Partially I am too lazy to rework my setup again, and partially I personally don’t need it.

To be clear, I don’t agree that use-package is wrong about anything or poorly written or anything like that. On the contrary, use-package has its very good points. One of them is that everything related to a single package is condensed into one place. At least configurations that are built around the use-package tend to be well structured. That part itself is a very good reason to use use-package, unless you have the very good discipline or come up with a system to organize your init file.

when I use dired to follow a Windows shortcut it still opens it as a file

Have you enabled parsing of lnk files; as they say in the docs, you have:

 (customize-option 'w32-symlinks-handle-shortcuts)

You can just

(setopt w32-symlinks-handle-shortcuts t)

However, when I tried it, they don’t seem to parse correctly the name; the last part of the name is surrounded by ‘#’ characters for some reason, so Emacs reports no such file found. I haven’t looked in depth at how they parse stuff and where.

Is that just hyerspec?

You could alternatively install info version from an old Wiegley’s thing called ready-lisp. Then you have it directly in Emacs, working as any other info manual.

Another option is to open the web version of files in eww. It is then still in Emacs, so you skip the web server and to switch between Emacs and web browser; if that is a feature for you.

I suppose that melpa downloads can be used as a measure of usage.

Not necessarily; lots of people would test some stuff and than perhaps not use it, or after some time go over to something else and so on. I wouldn’t rely on download stats.

which extensions are used often in users setup

It would be certainly possible to monitor which files are required in your Emacs session, and you could setup a public server somewhere on the Internet where such stats are uploaded, putted together and published for viewing. But what would that matter to you what I or some other Joe are using? Learn a thing and build on it instead of switching and trying. As long as it solves your problems who cares what others are using?

What I tried is to feed to minibuffer word string.

So you have called:

M-: (type-of (read)) RET string RET?

You have just created a temporary symbol named “string”. You can try this to see for yourself:

M-: (symbol-name (type-of (read))) RET

If you want a string object out of “string”, you will have to quote it in the minibuffer too:

M-: (type-of (read)) RET "string" RET?

I think you should have not downvoted /u/lispm below (or whomever it was); he has given a few very good questions to get you going on in exploring those things on your own.

inside one file, I have difficulties going quickly up function by function

helm-occur

Just start typing and it will show you occurrences in a file; you can use C-n/C-p (or whatever you bind it to), and it will move the point in the buffer and show you the occurrence so you can see the surrounding text. If you C-g the point is left where you were, and if you just press enter your point will be placed at the occurence.

inside one file, I have difficulties going quickly up function by function

helm-occur

Just start typing and it will show you occurrences in a file; you can use C-n/C-p (or whatever you bind it to), and it will move the point in the buffer and show you the occurrence so you can see the surrounding text. If you C-g the point is left where you were, and if you just press enter your point will be placed at the occurence.

If you use Magit, LSP and Projectile to code Rust, have you tried to clone the repo(s) you are working on to your local computer and enable git server on remote so you can push your changes. Or if you don’t wish to enable git server, transfer files from the work machine to remote via some other means (sftp) and just commit when you know you are done. It would remove the latency for the most part. Otherwise you are perhaps better off running Emacs on the remote and forward X to your work station, have you tried? Or probably even faster, just ssh into remote and run Emacs in terminal.

I am not sure if it is tramp problem; it is probably that you are just generating too much traffic if you are using Emacs on a remote as if you would be using it on your workstation.

It is painfully hard for a new user to start out on GNU Emacs and get everything they want running and if they are not patient, they will outright quit.

I don’t know man; I started some 20+ years ago with vanilla and for the first like almost 20 years I had no more than perhaps 20 - 30 lines of elisp in my .emacs file.

I used it so until some ~3 - 4 years ago when I got more interested in Emacs and started to learn Elisp and tinker around with it.