After using Emacs for 10+ years, I've switched to VSCode for a really simple reason: fuzzy matching a file in a project. I've tried so many different plugins and hacks to get it to work, but it never did quite work. Searching for a filename either matches the wrong file, or new files that were freshly added are no longer there.
I’m a vim user, but I imagine there’s a similar way to do this in emacs... The secret is piping fd into fzf and opening the selected value from fzf. You can probably write a 2-liner in elisp that shells out. In my experience, this pipeline provides a faster and better matching experience than any IDE. Once I got this working, I never went back to VS Code. :)
Toward a “modern” Emacs
351–360 of 539 posts
Re: Toward a “modern” Emacs
#352Emacs has a lot of cruft on the code-level.
The worst part is the lack of separation between "backend" and "frontend".
There is support for many different "frontend" architectures: Win32/MacOS/Gtk/
But a lot of code was just duplicated when a new frontend architecture was added. And started to grow into different directions. The code is littered with #ifdef and there is no clear API for the fronted architectures to sit on top of.
For example, font handling is different for most frontends. And this difference leaks into the core part of Emacs where line-breaks are managed, etc.
There is work towards a "pure GTK" that uses Cairo as a drawing surface.
https://github.com/masm11/emacs
Imho the Cairo "drawing surface" and font handling should be the only implementation for what it does and reused for all frontend architectures. With the exception of terminal sessions...
But, Emacs devs are very conservative when it comes to "modernize". In my experience, it is a lot easier to add stuff than to clean up. That also explains the forest of #ifdef and accumulation of cruft.
Re: Toward a “modern” Emacs
#353Earlier quoted context omitted.
Yes, it's wonderful the community is small and technically capable.
A community can be technically capable without being full of elitists. Just look at Clojure.
It helps to have a lot of very visible brackets when people sign up, it scares away the majority who won't cut it.
Emacs is in that unfortunate position that you can learn the shortcuts and 'use' it for months before you even see your first bracket and end up thinking the brackets are the problem, not you.
The number of times I've heard people demand the scripting language change to python...
Re: Toward a “modern” Emacs
#354Earlier quoted context omitted.
I don't really get what you mean. Sure, setting up MELPA is a bit annoying, but after that trying a new package is trivial. You go to the package list and install the package, then you trigger whatever command you need. I agree that fuzzy search is a great thing though, and I think something similar to Ivy should be included by default.
> then you trigger whatever command you need how do you do see? How do you get to the list of commands? How do you search for a command? How do you remember a shortcut if you run a command manually? I've been using emacs for quite some time and I still get stuck there.
To run/search-for a command: M-x
If you have installed and configured helm (I assume the same for ivy) you'll get a list and the search will be fuzzy)
In helm: shortcuts are shown in the result list:
M-x replac|
replace-string
replace-regexp
query-replace (M-%)
...
Re: Toward a “modern” Emacs
#355Earlier quoted context omitted.
use-package has basically solved the package management problem for me in Emacs.
use-package can make package management easier, but using it s not beginner friendly. As an advanced Emacs user, when I read its docs, there were too many subtleties that can trip up a beginner. Indeed, just yesterday I stopped using use-package for one of my packages as I couldn't figure out why it wasn't behaving properly - reverting to require solved it.
The Emacs docs are absolutely horrendous, they read like they're written for the core dev team. Useless as an introduction, everyone ends up on Xah Lee's site.
They could be completely fixed by just providing examples of all these esoteric elisp functions.
Re: Toward a “modern” Emacs
#356Earlier quoted context omitted.
Doom Emacs is much more polished than Spacemacs, and yet lighter weight.
But Doom Emacs presents itself as: "Doom is a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better). It can be a foundation for your own config or a resource for Emacs enthusiasts to learn more about our favorite operating…
Ignore that, it's just bad marketing. Doom is a packaged distribution and it's waaaaay better than Spacemacs (and much easier to modify). Spacemacs is a very poorly written piece of software in comparison. Doom is moving much faster as a result.
Re: Toward a “modern” Emacs
#357Earlier quoted context omitted.
I have used emacs since I was an undergrad, 25+ years ago and I have no plans to switch. That does not stop me from recognizing the fact that VS Code does almost everything that emacs does, often better, has orders of magnitude more users, is much more approachable and is being improved at a much faster rate. As they say, "this time its different".
I've been using Emacs for an entire 1 year and I have to say - I only like OrgMode. I've barely tried out Magit, so maybe that's another killer feature. But for programming, I think that Emacs is too steep a hill to climb when VSCode and JetBrains' IDEs offer so much out of the box or just a few clicks/commands away. In Emacs, you can can, in theory, do anything you like. And it is so impressive when you customize it…
You are totally right. Being an emacs user for 10 years, I suggest vscode when people ask what editor to choose.
While preconfigured Spacemacs, Doom and others are doing a good job in turning emacs into OOB editor, they still require some tinkering with lisp, while in vscode you just install plugins and you are done.
Re: Toward a “modern” Emacs
#358I love this: “Or, as Richard Stallman put it”: ‘It is unfortunate that the people who implemented the newer editors chose incompatibility with Emacs.’ It is interesting to see a comment that is 100% at odds with the brutal evolution of ideas that occurs in a good ecology of software. If the same mindset applies to the rest of emacs then they really stand no chance or real progress. (edit: the rest of emacs, and not j…
Yes, what really pisses me off about emacs is the mind-numbing arrogance - they're basically saying "people ought not to have broke from our button scheme, so we'll just ignore it to our users' detriment!". There's this implicit argument that convention is some sort of monarchist hierarchy where the successor mustbenamed as heir first, and what convention is most common is somehow irrelevant. It's infuriating.
Emacs has lasted 40 years with a stable (but small) market share. It's outlived every other editor with the exception of Vim. It will probably outlive Atom, and it looks like it's going to outlive Netbeans.
I'd argue stubborn resistance to most new concepts regardless of their sheen is a contributor. I think people underrate that as a trait. You want some bastions. Loads of it is insane but they also don't make many new mistakes.
Re: Toward a “modern” Emacs
#359I don’t know. I read the whole article and it seems the suggestions boil down to emacs needing to be more “modern” by defaulting to dark mode, making color theming easier, changing right click behavior, the menus, and changing the shortcuts. And the author of the article would like the development process to be more “modern.” Emacs is one of the most successful text editors of all time if not the most successful. It…
The main problem with emacs is that while it's praised for being a programmable lisp environment, it's not a really good one.
It doesn't have widgets, decent rendering engine with scene graph and hardware accel, it's single threaded, the language is clunky. You really can't make decent applications in emacs, only text with embedded images and primitive buttons, that blocks and stalls all the time.
It really needs some major update.
Re: Toward a “modern” Emacs
#360The Emacs community should start by perfecting lsp-mode so that it can compete with VS Code in terms of functionality. That will simultaneously keep power users from switching AND bring in people from other "easy to use" editors that lack such functionality.
Is the LSP architecture the way to go, though? In my experience it's quite a bit slower than built in emacs modes. I can't use tools that are slower than me.
Are you on Emacs 27 yet? Below that Emacs encodes JSON in Elisp, which is extremely slow and makes LSP unusable.