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.

cdlatex is not need it.

The manual says you have to install it:

You need to install ‘cdlatex.el’ and ‘texmathp.el’ (the latter comes also with AUCTeX) from NonGNU ELPA with the Emacs packaging system or alternatively from https://staff.fnwi.uva.nl/c.dominik/Tools/cdlatex/.

The manual I linked you to.

Your stack trace confirms: you don’t have cdlatex installed (or not in your path) when you are trying to turn on cdlatex mode with turn-on-org-cdlatex.

If that is the best user experience or not I leave to the interested party to lift in a bugreport/request to org devs, but it is what it is, and is documented in the manual.

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?

Why did you make three threads with the same content?

the new config is synced to the other machines

I don’t know man; how do you plan to sync those machines? If you have 4 machines involved, there are always problems with machines being online/offline and talking to each other that you will have to solve somehow. If I were you, I would make a public or private repo on Github and use git to version control your content. You can push/pull from each machine when you make changes and need to propagate those changes. You can potentially automate the process of pushing and pulling via shell or elisp script.

Would that work in practice or are there pitfalls I am not aware of?

The most important thing is to keep eyes on your paths when it comes to documents and packages. I suggest keep all your org files in one directory, say ~/documents or whatever you prefer, and keep all of your Emacs config in .emacs.d, so you can just push/pull the entire .emacs.d. Another thing to keep eye in your config on are external programs, ag, ripgrep, etc. Since you are basically in the *nix world, it shouldn’t be too difficult, but there still might be differences where they are found etc; so you might need to keep an eye on paths and which programs you use. You can solve it in different ways, at your discretion, either directly in Emacs setup or in your login shell.

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.

It is not so much about other tools or languages not being extensible; most quality ones are extensible. It is about how easy is to extend it since the text editor, debugging tools, and some other useful stuff like shell integration (process control, I/O), networking for example, are built into the extension language.

It is very easy to write a small tool that automates something, like a say project creation for Emacs compared to for example Eclipse, Netbeans, or VisualStudio. Since Emacs GUI is in essence a glorified console, it is relatively easy to integrate CLI, text-based tools with Emacs.

How rewarding learning Elisp can be?

How rewarding learning anything is?

how exactly can i improve my emacs experience if i learned elisp?

You can program Emacs to do stuff you want it to do, the way you want it to do. It is like asking how can I improve my computer usage if I learn a programming language.

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.

Looks defunct

It is. You can still use it. There is an implementation that byte compiles with just some minor warnings but EIEIO (a simplified CLOS version) is what is available in Emacs as built-in and there is much more available resources to learn from if you want to use an object-oriented system in Emacs.

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.

There is no built-in automatic way; you will have to backup your old values any way you want; create a bunch of new symbols, put them into a hash table, a list, or whichever else strategy you prefer.

a gap buffer is a linked list in disguise

I see a gap buffer more like a generalized std vector in regard to where you insert the items. I am not sure I understand why you think of it as a list, but perhaps we think about different things?

And what you propose is basically what I have implemented.

Mnjah; I am not sure we think of the same thing in that case. What I proposed, or what I asked why you didn’t do it that way, is to keep the “classical” Lisp semantics for lists so that you don’t need to rework many of the existing algorithms based on lists. No idea if that is important or not, but I don’t see a reason why you need to reverse those just because you use std::vector under the hood to store your lists. Where and how you push/pop could be kept just as an implementation detail.

Another thing that I was thinking of is the cost of traversing the list. By generating a new object for each cdr operation and updating reference counters, it becomes quite costly compared to just returning a pointer. Have you done any benchmarks to compare your idea with the “classical” one? Also, have you looked into cdr coding; which is another technique to make list elements contiguous in memory?

To note, perhaps a new Lisp could dispose with car/cdr operations, as long as you have some other alternative to access and traverse lists. After all cons/car/cdr/push/pop as we know them from classical lisp are defined as they are because of the implementation behind them. There is no definition of what a Lisp is, so nobody says a Lisp has to have those operations exactly as they are known in some older Lisps.

Interesting.

The only case, when this structure is less efficient is when you need to insert an element at the head. In this case, we need to move all elements one step forward, which in a buffer is quite simple and efficient:

Have you considered using a gap-buffer instead of ordinary vector?

This solution certainly poses some problems and some traditional Lisp algorithms won’t work as expected.

Since you are using C++, isn’t it possible to implement your own vector with overloaded operators to adhere to Lisp list semantics? In other words, isn’t it possible to make your car/cdr & other access functions access elements from the top of the stack so that ordinary list semantics as in standard Lisps still work as expected? Just a curious question, I guess you have already tried.

You don’t need to move files around just to bulk rename them. If you want to do it, sure, you can, but you don’t have to.

In your top level directory:

1. C-u C-x d (alternatively C-u M-x dired)

You will be in minibuffer now. Be sure dired listing switches have -l and -R option; -l is probably already there among anything else you might use; just type space and add -R at the end and type Return (Enter)

Now you will have a Dired buffer with al the subdirectories and files in them listed in the same buffer.

2. C-x C-q in Dired to switch to WDired mode (I have bound it in my Emacs to C-S-r for easier typing)

You are now in “writeable dired” mode where you can edit all file names as if it were an ordinary text buffer. You can also use replace-string for example to replace a part of the name in all filenames at once, regex-replace, etc. You can do it manually, or whatever else you would do in a text buffer.

3. C-c C-c to save your changes when you are done; all files will be updated.

I think it would be a better task for just the CLI

No, it wouldn’t :). You can certainly do it, but it is frankly, easier with Emacs only.

Racket is now on Instagram at

You accepted “beat the egg” challenge?

Somewhere on Autodesk’s site perhaps?

https://www.autodesk.com/blogs/autocad/autolisp-to-automate-your-tasks-part-1-beginner/

I can tell that I’ve noticed some improvements.

I guess you haven’t run your Emacs for a long time, because ~100 megabytes of allocated memory will take its time to GC check. With that amount of RAM, you will probably notice Emacs “stuttering”, like freezing for small periods of time when using it normally. The bigger the gc-cons-threshold value, the longer time it will take for GC to check the memory. Emacs does not have an incremental and multithreaded GC, so your Emacs will appear as frozen to you.

(defun salih/maybe-gc ()
  (let ((original gc-cons-threshold))
    (setq gc-cons-threshold 800000)
    (setq gc-cons-threshold original
          gc-timer (run-with-timer 2 nil #'salih/schedule-maybe-gc))))

Have you even looked at gc-cons-threshold value; after your idle timer has finished the work? Looking at your code, I believe you will be surprised because it does not seem to be what you think it will be.

What is the point of the first setq there?

In the third line, you are setting the value to hardcoded ~800 kb (I think it is the on 64-bit systems, but it is not so important), just to immediately override it with 100 meg as you defined it in the previous code piece (third line of your code), one after the gcmh. Secondly, what is the reason to use gcmh package if you are going to do it all manually :). GCMH will do exactly the same thing you are doing manually in that example if I am not mistaken; I don’t use that package myself, but someone wrote it for the purpose of automating that little hack you are trying to make there. IMO, either use that package and be happy, or do it all manually.

What is the purpose of setq-ing gc-timer to run your function in that let-body (last line) which appears to just do exactly the same - you are again doing the same thing in your salih/schedule-maybe-gc. You are just telling Emacs in an infinite loop to set up a new timer when it is idle. If you believe you are telling Emacs to actually garbage collect something, you are wrong; you are just setting up another timer.

In other words; your code does not do what you believe it does; it is rather plain wrong, in other words, buggy, to put it mildly.

I can tell that I’ve noticed some improvements.

I can tell you haven’t, you just don’t know about it. When other posters here told you to benchmark they were correct.

we are not in an academic seminar, such anecdotal statements should be authentic enough.

We don’t benchmark because of being academics, but because of ourselves. If we won’t to improve something in whatever terms, cpu execution time, memory usage, number of resources allocated (timers, files, sockets etc.) you have to measure. You can’t know for sure if you don’t measure, there is no way. Your computer can be doing stuff, your application can be doing stuff, and so on. Modern computer systems are not deterministic in terms that hardware usage being exactly the same each time you run an application. Execution time is highly dependent on your OS and CPU scheduler(s), memory usage patterns and so on, some of the things your application usually does not influence explicitly.

Without measuring you are walking with a blindfold. However, you seem to have other problems than just benchmarking your stuff; you should really read the manual about stuff you are trying to improve or change, use built-in help; C-h f/v to see what stuff does and try to understand it. Read whichever blog posts you have found again and reflect carefully on what they say and why. Just blindly copying stuff without understanding it results in stuff like your code above.

Finally, to answer your original question, it all depends on how you wish to use your Emacs. What might be fast for one usage pattern, might not be fast for another one. Again, you will have to know what you are doing and to measure for your particular use-case.

the prefix seems to be a common Common Lisp library prefix.

Yes it is, but is that important?

I would think of what is the target audience. If it is a general home automation crowd, for them the programming language used is just an implementation detail, not the major reason to choose the project.

Of course, the name is not the most important thing either, it was just my reflection since the discussion was about it.