This seems to be missing the elephant in the room - elisp doesn't suck, it is just a lisp. It is annoying having to learn a specific lisp just to edit Emacs, but whatever. Other lisps are better if you want to add lisp to your application.
The Emacs data model sucks. There are APIs that do who-knows-what combined with your personal extensions that modify behaviour who-knows-how, figuring out how to describe UI components is no fun, text editing is surprisingly hard from a programmers perspective, there are decades of accumulated different ways of doing things and it is unclear where to start or what has been obsoleted. The names made sense in the 70s but unfortunately it is 2024 and "Windows" means something different now. I wouldn't even exactly blame Emacs for any of this since some of it seems to be essential complexity of the domain.
(defun cider-tramp-prefix (&optional buffer)
"Use the filename for BUFFER to determine a tramp prefix.
Defaults to the current buffer. Return the tramp prefix, or nil
if BUFFER is local."
(let* ((buffer (or buffer (current-buffer)))
(name (or (buffer-file-name buffer)
(with-current-buffer buffer
default-directory))))
(when (tramp-tramp-file-p name)
(with-parsed-tramp-file-name name v
(with-no-warnings
(cider-make-tramp-prefix v-method v-user v-host v-port))))))
Here is a random function from CIDER. The code is simple enough, the lisp is no problem. Immediately we see we're interacting from one extension to another, have to understand Emacs buffers, need to know how warnings are displayed, have to understand parsing as a domain, and appear to have a network involved. That is a lot of work to debug one function when something is misbehaving. Not an unreasonable situation, but nonetheless a barrier. Then on top of that I have to go look up what let* is and why it is presumably different from let. One more thing I don't want to do. Emacs lisp sucks.
EDITEDIT Tramp isn't an extension, it is part of core emacs. We live and learn.
EDITEDITEDIT Spoke too quickly, it looks like it is a GNU-supported extension. This is the sort of trivia that got me using Doom Emacs.
More than that, it actually communicates to the reader that there is a dependency between some of the variables being declared. That is, it is actively useful.
Your complaints, while being understandable can be addressed with simply reading of the manual and source code. There are various lips out there and as soon as I know Emacs has its own, I would seek the manual for that. There are wealth of documentation on emacs and its ecosystem, and it predates a lot of standards. The terminology can be strange, but you can readily find some glossary.
> Your complaints, while being understandable can be addressed with simply reading of the manual and source code.
I don't think they can, my complaints are that I have to spend too much time reading the manual and source code. Reading the manual and source code will not help resolve that.
There isn't anything profoundly wrong with Elisp. Emacs needs a programming language, Elisp is a programming language and that is the end of the story, more or less.
You can level complaints against Elisp. You can level complaints against anything. They aren't a big deal - Elisp supports variables, loops and if statements and that is enough to implement a text editor to a first approximation.
If the slate was wiped clean, the Emacs community would probably prefer that Emacs was written with Common Lisp. Then Emacs wouldn't need its own lisp reference manual.
I can't speak for the Emacs community, but like to caution that Common Lisp is a large language and IMHO would be too much a burden to learn for someone just to customize or extend the editor. I'd rather think it's the Common Lisp community who would prefer Emacs to be written using CL ;-)
Emacs Lisp gets there anyway, somehow. Just decades later.
Examples:
Lexical binding. SCHEME in 1975, Common Lisp in 1984. GNU Emacs in 2012.
Native compiled code. LISP 1 got that in 1960. There are now native compiled code builds of GNU Emacs since a few years.
Cooperative threading. Common Lisp had that in the 80s. Other Lisp dialects probably earlier. Now concurrent native threads would be a thing, so that Emacs Lisp too can take advantage of preemptive single and multi-core threading.
But (setq variable var) looks the same in CL and ELisp, so it takes the same amount of learning to customize, right? It is not more to learn just because there exist more possibilities in the language.
> Then on top of that I have to go look up what let* is and why it is presumably different from let. One more thing I don't want to do. Emacs lisp sucks.
Don't modern languages require you to also look up definitions of functions. Learning peculiarities like this in Common Lisp (eg equality) really opened my eyes to how much "magic" there is modern high level languages. Personally I dont like magic and lisps tend to be the most magic free high level languages
Sorry but picking out let* as a problem just shows that you don't know some of the most basic Lisp forms. You say that you don't want to learn a specific Lisp, but starred let is in both Common Lisp and Scheme. So what Lisp have you actually taken the time to learn? The impression you give is precisely ().
The language used to manipulate the data model is almost irrelevant. It's probable that the initiates within the priesthood know it all, but the hoi-polloi certainly don't; and we probably don't have the time to find and read all the docs just to use an editor with a simple customization. It's exclusionary and there's an immense barrier to entry, whether it's elisp or bananas-lang.
The Emacs data model sucks. There are APIs that do who-knows-what combined with your personal extensions that modify behaviour who-knows-how, figuring out how to describe UI components is no fun, text editing is surprisingly hard from a programmers perspective, there are decades of accumulated different ways of doing things and it is unclear where to start or what has been obsoleted. The names made sense in the 70s but unfortunately it is 2024 and "Windows" means something different now. I wouldn't even exactly blame Emacs for any of this since some of it seems to be essential complexity of the domain.
EDIT Example, picked completely at random:
https://github.com/clojure-emacs/cider/tree/master/dev
Here is a random function from CIDER. The code is simple enough, the lisp is no problem. Immediately we see we're interacting from one extension to another, have to understand Emacs buffers, need to know how warnings are displayed, have to understand parsing as a domain, and appear to have a network involved. That is a lot of work to debug one function when something is misbehaving. Not an unreasonable situation, but nonetheless a barrier. Then on top of that I have to go look up what let* is and why it is presumably different from let. One more thing I don't want to do. Emacs lisp sucks.EDITEDIT Tramp isn't an extension, it is part of core emacs. We live and learn.
EDITEDITEDIT Spoke too quickly, it looks like it is a GNU-supported extension. This is the sort of trivia that got me using Doom Emacs.