Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As a die-hard Emacs user, this is also something that has been occupying me lately. There is too little thought going into the deficits of Emacs; many people I convinced to give it a try went back to Sublime, VSCode etc. Emacs has two main shortcomings, in my opinion. The first is that the visual aspect of programming is completely left out. You can have nice outlines, pop-ups, tree views etc. in most other editors; Emacs completely ignored these. The main argument has always been "won't work in a tty", but there should come a point where tty is deprecated or at least treated differently. The other is evolving the language. Elisp was great for its time, but compared to modern languages its age clearly shows. There are no namespaces, it can be dead slow, support for networking is limited, regular expressions are weird etc. I think there should be more work going into modernizing the language, which can also be used to introduce facilities for GUI elements and networking code, especially async.


I strongly believe that TTY compatibility is a feature which should not be discarded. But that doesn't, I think, prevent the kind of features you mention: they just need to be first-class UI features like the minibar is.

Agreed that Elisp needs to be upgraded. I think that it should just be replaced with Common Lisp, which has namespaces (packages), and is very fast, and whose implementations support networking & threads just fine. Of note, part of why Emacs regexps are so unusual is that they are pragmatic: since they will be used to match Lisp source so often, () are not the metachars they are in other regexp dialects.


> Emacs regexps are so unusual

Parentheses are also not metachars in Vi (and Vim) regexps by default, and are not metachars in POSIX BRE (basic regular expressions).

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

The grep utility, for instance, understands BREs by default; you must use grep -E to get ERE (extended regex) in which ( and ) are grouping characters, or else the deprecated egrep command (not in POSIX).


> Emacs has two main shortcomings, in my opinion.

Eh, no.

Emacs has a shitload of bugs (sorry for the language), and an ad-hoc configuration and package installation that inevitably turns your Emacs installation into a bespoke ball of mud.

(Goes in hand with 'malleability', I guess, but still a very subpar user experience.)


I'm not going to "defend" Emacs here, it's a piece of software and you use it if it suits your purposes, but I find it to be quite stable for the feature set it offers. Also if you put moderate effort into it, it's possible to achieve a reproducible packaging and configuration state. I can check out my .emacs.d (https://github.com/afroisalreadyinu/emacsd/) on any Linux computer, start Emacs and work on it as if it's my own computer.


I spend most my time in emacs; my experience is it's pretty buggy. Probably mostly packages & their interactions than emacs per se, but for me emacs is all about the customizability & the packages...


Yeah there's this dilemma. Emcas, out of the box, seems stable enough (and performs well enough?). But for many of us, the features it offers ootb are nowhere near enough. So you start installing packages and it quickly turns into a clusterfuck and you have bizarre little bugs and interactions everywhere. And it still doesn't work exactly the way you want, even if the bugs were not present.. so you have to spend a huge amount of time trying to figure the clusterfuck out so that you can start working on it and make it right. And figure out why it got slow. Or sigh and give up.

It isn't helped by the fact that some devs insist on using bleeding edge melpa packages and their stable versions are broken. Other devs' bleeding edge versions are prone to break..

Emacs, with its packages, is one of the most chaotic things I've seen. I don't know if there's any hope for me to tame it in a reasonable timeframe.


Ha, yeah, you've captured it nicely. I have a TODO list 25 items long of problems to try to track down; occasionally I'll pick one off, but I think the list is growing faster than it's shrinking.

It's an open question, but I suspect it's not impossible to have both a robust and flexible system...think Emacs, but instead of the wild-west of Lisp as the extension language, something more in the vein of Rust...


Since you use evil.. does term-char-mode work? Can you send C-x or C-z to the application? (without a workaround like (term-send-raw-string "^X"))


> The first is that the visual aspect of programming is completely left out. You can have nice outlines, pop-ups, tree views etc. in most other editors;

What do you mean? Emacs has them too, just not nice ones. Also, emacs is not an IDE, so there is some limit on what kind of interfaces people will build.

But yes, the GUI-parts of emacs are a big liability for future growing. While emacs does has offer all the nice visual tweaks, they also all sucks because of bad implementation and limitations in emacs itself.


I do love the fact that emacs runs on a TTY, though. It means that useful programs in emacs are useful TTY programs. For instance, the ebook reader, nov.el, is the best available epub reader for the TTY right now. It would be awful to lose that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: