I’ve fallen into something of a cycle of adding packages until I’m annoyed by things breaking which results in me cutting back down to the basics.
I’m always amazed, once I get back to bare emacs and mostly elpa packages: everything works so well.
Dependency hell is very real and doesn't just affect Emacs. I simply version my entire Emacs (back since when Mercurial was a thing) config so any SNAFU that'd happen when I try a new package is one checkout away: I just reset to the last known good state and call it a day (for that package).
I've got about 3 000 lines of custom elisp code and everything works fine.
I don't disagree that bare Emacs and Elpa works well. Now that use-package is shipped with Emacs I eventually switched to it. Took a while but it's been smooth sailing.
I really heartedly recommend people to version their entire Emacs config in Git. Some shall go further and recommend to version your entire home directory for that matters. Or to use something like Nix.
I'd say any of these options is fine as long as "going back to the last working config" is one command away.
;; -*- eval: (git-auto-commit-mode 1) -*-
You either start trying to cram every possible task into that tool or try to find other software that was developed specifically for users of that tool (eg: Nyxt and Qutebrowser).
It feels like a very natural thing to do at the time even if it sometimes results in subpar results like what you're describing. I've personally declared "Emacs bankruptcy" multiple times and even go through periods of completely changing workflows if I get annoyed enough.
Same for computers at large. Let parents or kids install whatever, and expect woes.
Emacs can feel worse, in this regard; but, I for one love how open it is to extend. Literally a defun and you've extended it.
Which is how all (or at least most) of our computing systems should work. The inability to easily extend programs is what leads to the "need" to replace them so often with other programs that satisfy unmet needs or capabilities. Which ends up mostly creating churn, not value or utility.
Sorry, but it has to be said. Using a more sane language would cut down on the bugs and dependency problems in Emacs in a huge way.
P.S. Been using Emacs for over 25 years.
But unlike JavaScript (and Node.js), I don't know of anyone who uses Emacs out of the belief that Emacs Lisp is a language with which they should be building large-scale applications. It is strictly a client-side language and it is used as such.
In fact, Emacs Lisp is actually a pretty good client-side language. Not that it is perfect, but I find it more enjoyable to use than JavaScript.
Strongly disagree. With lexical bindings it's on par with contemporary strongly typed dynamic languages like python. It does even have fancy pattern matching with pcase library built in, plus lots of fancy stuff for editing like thing-at-point.
Personally I would also think that a standard OOP system would be useful.
I can't imagine the maintenance of a Lisp system where several ten thousand names are flat in one namespace. For example: there is no way to browse those just looking at names with prefix parts. Textual name prefixes are a poor substitute for a proper "first class" namespace system. What parts of the symbol name are actually a prefix?
"CL-CADDAR" -> that means that I can't load any CL source code into Emacs, because every operator has been renamed. What? There is a subset of Common Lisp in GNU Emacs, but with all operators and variables renamed?
40 years ago Zmacs and the surrounding libraries on a Lisp Machine were already better structured.
> cl-defstruct or eieio
It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders.
Not really sure what you mean. These are not "add-ons" any more than standard libraries are add-ons to other languages. They are fully integrated into core of Emacs, and has been that way for decades already. The naming situation might imply otherwise, but "cl-" namespace is by no means a second class citizen and I think there are practical value in keeping that naming scheme. In any case they are pervasively used both internally and in the community.
does not look like it is fully integrated into the core.
> I think there are practical value in keeping that naming scheme
To prohibit reuse of existing code? Where is the practical value? If Emacs Lisp had a namespace mechanism, this would be no topic and nobody would argue keeping a strange naming scheme, where operators are named incompatibly to the language where they were coming from.
Let's define most of Scheme features, but rename all the operators. That's really really strange to argue... I makes the reuse of millions of lines of existing code impossible from day zero.
1. The implementations of many functions are subtly different anyway, much like you can't expect Ruby's string join to work the same as Python's string join, down to an identical argument order and everything. That would be crazy to expect, right? You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
2. Even if you wanted to do this, the name of the function would be the easiest part of the migration: it takes one round of search-and-replace. So the namespacing is not the problem, and it's barely a problem at all.
I'm not really understanding you, maybe. Why would you expect Elisp to be able to run CLisp code verbatim? And why would you ding a language for its inability to fulfil such an uncommon use case?
Just go into a different namespace and load the code. The Lisp Machine I use has several different dialects of Lisp in one image. I can tell what dialect to use and it reads and evals code from that dialect. I can have two REPLs for different Lisps running side by side in one Lisp world, where I can call all operators from all other dialects.
That's basically also what was imagined for a GUILE-based GNU Emacs: it would run all of Emacs Lisp, but would also additionally understand Scheme.
> You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
Sure I can. Here I have loaded SCHEME into Common Lisp. The namespace is called SCHEME.
I'm in the CL-USER namespace:
CL-USER 8 > (scheme::define (scheme::foo1 x) (+ x 22))
foo1 defined.
CL-USER 9 > (scheme::foo1 20)
42
CL-USER 10 > (in-package "SCHEME")
#<The SCHEME package, 774/1024 internal, 0/16 external>
SCHEME 11 > (foo1 20)
42
SCHEME 12 > (define (foo2 a b) (+ a b 22))
foo2 defined.
SCHEME 13 > (foo2 9 11)
42
I'm not just talking about migrating code by converting it. I'm also talking about using the same code from one file.
> And why would you ding a language for its inability to fulfil such an uncommon use case?
It's only uncommon because you are not used to it. In earlier times even very complex source code was shareable between similar Lisp dialects.
If one adds to a Lisp lots of operators from a slightly different dialect, then it would be useful to do it in such a way that the dialect is integrated in a way that original source code written in that dialect can be shared with only a minimum of work.
Still, I don't want to just turn to nitpicking the examples. I asked, you gave. I'll think on those some.
I stand by my assertion that the abstractions are good for what emacs needs. As evidenced by how well it does keep up, all told. Does it do as well as a staffed resource to build some resources? Probably not. More, it is unlikely to ever be able to make a feature that nothing else can do. By virtue of it being open. If something is amazing from it, others can emulate it.
But, the amount of synergy between modules speaks volumes. Tramp alone is quite amazing at how many modes "just work" with it. With no prior planning on having to expose internals or special methods.
I also confess I expected threading to be mentioned. Another thing which I have seen cause as many errors as it typically helps. Effectively the "goto" of application development. Often best avoided, but also often required.
I would think that each Zmacs instance from 40 years ago already ran in its own thread.
Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.
My Lisp Machine emulator for Symbolics Genera is still responsive for the same code snippet, entered in a Listener window.
Edit: For amusement, I was trying to see how bad it could be, so I made a loop to get the 90000th fib. Which, wasn't enough to see here. Hard to really appreciate how fast computers have become.
But in a Lisp application to not be responsive at all is kind of rare. Most Lisp application runtimes will be able to process interrupts and/or switch "green threads" or "native threads".
every single game with 'mods' has the same issues that the vast majority of extensible applications have.
the core developers (hopefully) care and understand about the cost of a cycle, whereas the mod/extension developers tend to care only about how their addition works and expresses itself to the user.
the mod/extension developers (generally, not in the case of foss projects) usually lack the scope to understand how their coding decisions affect the rest of the code base, or in the worst cases they lack the understanding needed to optimize something to the point of usability -- so they achieve their small purpose by any means possible, often times in fairly brutish manner, which kills app performance all together.