I use emacs and have for a really long time. Unfortunately, I don't recommend it to anyone because I think the costs of learning it outweigh the benefits. When I read this article, I was surprised that my gripes don't overlap much with those listed in the article. I do really like the idea of "new user detection", which would take a user through a short configuration process if the .emacs file was missing. I think my…
Choosing an editor like emacs or vi is a major decision which will have long-lasting effects. I love vi, and the homerow movement keys are now hard-wired into my brain, so much so that using 'normal' applications is noticeably frustrating. Sure, I can try to add plugins to everything, but that only goes so far and requires a lot of setup work on every new computer or VM. That said, the old school editors bring plenty…
Making Emacs Popular Again
361–370 of 782 posts
Re: Making Emacs Popular Again
#362Earlier quoted context omitted.
Emacs is not an editor, it is rapidly-programmable-at-runtime-evolvable software that is designed to: + Help you realize how _you_ best deal with information. + Help you manifest your realization through _rapidly_ molding Emacs into your conceived model. It is also the closest thing we have today to the Lisp Machine paradigm. I wrote this earlier today: You'll get the most out of Emacs if you treat it as an investmen…
At what point does this get in the way of your programming? If there's always more to learn about the tool, I think that would bother me. I would like to like emacs, but the couple times I tried it it gets in the way because I don't know it well enough. Vim seems more appealing because there is less to know up-front, but it is still extensible
A few times a month, I'll do more extensive work, focusing on a number of long-term projects or exploring various ideas I've had and put down in my notes. All this work is geared around helping me manage information more effectively. I'm an information junkie, hopelessly addicted to the Internet and that's by choice. I wouldn't give it up for nothing.
Emacs is the tool that makes the difference since this continuous feedback loop of me adapting Emacs to help me deal with more and more information, allows me to keep up. Being an information consumer is easy today, you simply sit back and absorb what's being blasted at you. Being plugged into numerous signal sources and managing that information _on your own terms_ is the tricky bit and where Emacs shines while most other tools fall flat, since they're either too constrained or lack the necessary programmability.
Re: Making Emacs Popular Again
#363I've used emacs for maybe 18 months solid. I never found it had a single feature that my other editors didn't have (not saying it doesn't, just staying I didn't run into them). My other editors can be extended via scripts. My other editors (mostly) have keyboard macros, repeat, etc.. My other editors can be used efficiently keyboard only. My other editors debug various languages. My other editors open shells in the e…
With that said, even if we ignore Magit and Org, and just look at dumb code/text editing, Emacs has some pretty rare niceties. I've gotten used to undo-tree, and now I find it sorely lacking in literally any software that can "undo". The interactive insertion and inspection of unicode characters is also nifty.
Re: Making Emacs Popular Again
#364Earlier quoted context omitted.
Emacs is not an editor, it is rapidly-programmable-at-runtime-evolvable software that is designed to: + Help you realize how _you_ best deal with information. + Help you manifest your realization through _rapidly_ molding Emacs into your conceived model. It is also the closest thing we have today to the Lisp Machine paradigm. I wrote this earlier today: You'll get the most out of Emacs if you treat it as an investmen…
At what point does this get in the way of your programming? If there's always more to learn about the tool, I think that would bother me. I would like to like emacs, but the couple times I tried it it gets in the way because I don't know it well enough. Vim seems more appealing because there is less to know up-front, but it is still extensible
Deep diving into emacs is not a productivity booster - its a hobby that one does for its own sake, if that's the kind of thing that floats your boat.
Re: Making Emacs Popular Again
#365Re: Making Emacs Popular Again
#3661. Install VS Code
2. Click extensions and install language specific plugin
3. Work
New employee 2 workflow at company X:
1. Install emacs
2. Try to install some source code indexing tool
3. Tool is missing 13 dependencies, so spend 4 hours finding, installing and configuring the dependencies.
4. Spend another couple hours reading non-existent to terrible documentation (documentation so bad in places that even Stallman finds it useless) across 3 packages and editing .emacs to configure an otherwise unusable result. It looks like source code indexing is working! It isn’t...
5. Go home
6. The next morning, find the default color theme garish and spend another 4 hours installing themes and theme managers, reading more terrible documentation, and finding that obscure TTY settings must be tweaked for emacs to decide that it can use a theme (even though it has no problem displaying the colors in the first place)
7. Spend the rest of your tenure constantly hitting code indexing and highlighting bugs that need constant tweaking and workarounds. You often find yourself using find/grep because it’s often faster than debugging the latest indexing bug.
8. Discover that the vaunted ‘lightening fast editing’ with ‘multiple cursors!’ and this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing.
Emacs is a terrible experience with defaults suitable for a 70s TTY. That you can change it misses the point. The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone.
In a few years, VS Code has achieved better out of the box functionality for working professionals than emacs has in 40 years.
Re: Making Emacs Popular Again
#367Earlier quoted context omitted.
Emacs is not an editor, it is rapidly-programmable-at-runtime-evolvable software that is designed to: + Help you realize how _you_ best deal with information. + Help you manifest your realization through _rapidly_ molding Emacs into your conceived model. It is also the closest thing we have today to the Lisp Machine paradigm. I wrote this earlier today: You'll get the most out of Emacs if you treat it as an investmen…
At what point does this get in the way of your programming? If there's always more to learn about the tool, I think that would bother me. I would like to like emacs, but the couple times I tried it it gets in the way because I don't know it well enough. Vim seems more appealing because there is less to know up-front, but it is still extensible
The best way to approach things is incrementally. Find some pain point in your current workflow and write a little bit of Elisp to automate the painful bits. Let's say you're running manual UI tests and then eyeball-grepping the logs in your backend. "But nobody does that!" you say. "Why would anybody do that?" Heh. You'd be surprised. Anyhoo, thr crank has to be turned on a prod deploy by COB Friday and you've got no time to investigate Nightwatch or the other UI-testing libraries out there, let alone integrate them with a log watcher.
Thankfully you're an Emacs user! So you write a little Elisp to start the back end, capture its output in a buffer, and count the number of occurrences of the log cookie that represents a successful (or failed) row insert, etc. You haven't automated your whole process, but you've automated part of it, and that's saved you considerable pain. And it took maybe half a page of Lisp, if that.
Recently I was confronted with an ancient web service whose only integration test process was "manually hit the endpoints with Postman, then check to make sure the records hit the database". So I wrote Emacs Lisp code to send the requests, run the queries, and even manage the Docker container where the service lived. This let me run the whole process much faster with a few M-x commands. It was nothing fancy, either, I just wrote code to spin up curl, Docker, and SQL*Plus and capture and examine their output, sort of using Emacs as a powerful full-screen shell. Rather than get in my way, it became a versatile tool I could apply to the task to get things done much faster.
Again, this is the difference between an extensible editor and a completely malleable one. VSCode, JetBrains, or Eclipse cannot be extended as incrementally and on-the-fly as Emacs.
Re: Making Emacs Popular Again
#368Outside of the text editor, I think native emacs keybindings like (C-n, C-p, C-a, C-e, C-k) on OSX are great and I hope they never get rid of them.
Every time I work with Linux or Windows, when I open a Chrome tab and I want to go down to a history completion, I hit C-n multiple times and it ends up with many new windows...
Re: Making Emacs Popular Again
#369Earlier quoted context omitted.
At what point does this get in the way of your programming? If there's always more to learn about the tool, I think that would bother me. I would like to like emacs, but the couple times I tried it it gets in the way because I don't know it well enough. Vim seems more appealing because there is less to know up-front, but it is still extensible
I've been using and programming Emacs for ~12 years. After all this time, I am at the level where it really feels like an extension of myself, almost like a cybernetic extra sense that I can put to use as I see fit. Practically, as I go about my daily programming, if I feel something is off and could be improved, I have a pretty accurate idea of how long it'll take for me to implement it. Usually it's not that long a…
The problem is that these days, you could use vscode or atom for a month or two, and get that same feeling. Emacs from scratch is not a great use of time anymore.
Re: Making Emacs Popular Again
#370It would be cool to have package statistics to know which packages are more popular/used. The community is too fragmented at this moment, and there are too many competing packages. While it's good to have diversity, having package statistics will make it easier to choose the best packages for end-users and package developers will focus on improving the most used packages. It will also improve compatibility between pa…