My Emacs Productivity Tricks/Hacks | Hacker News Reader

My Emacs Productivity Tricks/Hacks

mycpu.org

341 pointsmycpuorg203 comments

The one thing I consistently do in emacs that shocks my coworkers -- is running this (custom) function, that I call "arrayify":

  (defun arrayify (start end quote)
    "Turn strings on newlines into a QUOTEd, comma-separated one-liner."
    (interactive "r\nMQuote: ")
    (let ((insertion
           (mapconcat
            (lambda (x) (format "%s%s%s" quote x quote))
            (split-string (buffer-substring start end)) ", ")))
      (delete-region start end)
      (insert insertion)))

What it does: Given a list of strings separated by newlines (commonly, something copy-pasted from a table) like:

  josh
  sam
  jed
  C.J.
  toby

You select the text, and run "arrayify". You can optionally provide a quote character and, in about half a second, get to:

  "josh", "jed", "sam", "C.J.", "toby"

This is incredibly useful for taking lists of IDs, or email addresses, or whatever, and transforming them for pasting into documents, or emails, or "in" clauses in SQL, etc.

It is unbelievably useful.

Doesn't sound crazy at all to me! I do this all the time using multiline editing in Sublime Text. It's the one part of a more modern IDE I have a hard time giving up (transitioning to Spacemacs currently). Will have to try out this script and see if it helps bridge the gap!

If emacs keyboard macros haven't bridged the gap for you, try https://github.com/magnars/multiple-cursors.el

Keyboard macros: https://www.emacswiki.org/emacs/KeyboardMacros

I’ve been using this for a few things, and while it’s a little more unwieldy than Sublime’s it works fine for most of my uses so I’d definitely recommend giving it a go.

Perfect - I'll try this out. Thanks for helping me out despite my newby-ness!

multiple-cursors is AMAZING and i use it all the time, but it does NOT work well for more than a few hundred lines of text. It gets incredibly slow.

I tend to do it in sublime with a regex:

Find/replace all:

  ^(.*)$\n

with

  "$1",

That also works well in Emacs:

    C-M-% runs the command query-replace-regexp (found in global-map),
    which is an interactive compiled Lisp function in ‘replace.el’.

    It is bound to C-M-%, <menu-bar> <edit> <replace>
    <query-replace-regexp>.

    (query-replace-regexp REGEXP TO-STRING &optional DELIMITED START END
    BACKWARD REGION-NONCONTIGUOUS-P)

    Replace some things after point matching REGEXP with TO-STRING.
    As each match is found, the user must type a character saying
    what to do with it.  For directions, type <help> at that time.

Love this. Adding to my `.emacs` now :)

Yes, indeed. You can also do that, and other small variations on it depending on the context, with a macro.

You go to the end of "josh", press F3, add a comma and a space and you delete the rest of the line, until "sam" is now the next symbol after your cursor. Then you go to the end of the line (C-e) and press F4. Your macro is now recorded. To call it, press F4 repeatedly until everything is on one line.

As a bonus, you can actually name your macro, assign a keybinding to it, and can also save it as Lisp code.

Works well for a few dozen entries...less so for a few hundred or a few thousand :)

Emacs keyboard macros can easily operate on thousands of things. Just give it a prefix argument like C-u 1000 <macro-key-combo>.

Or use the C-u 0 prefix to repeat till there is an error, possibly at the end of buffer. And if you don't want to go on to the end of the buffer, narrow to the required region (C-x n n) and widen afterwards (C-x n w).

hell yeah, this is what I'm on about, I'm still learning stuff about emacs tricks here. I love this, thanks for bringing this up!

I am developing a headache now, after trying this out, because I'm remembering all the times I have done this by hand. Or even writing an awk script, etc.

hm, I just select the text and do

     xclip -o | awk '{ print "\"" $0 "\"," }'

find it simpler than 10 lines of lisp but what do I know :p

Once you bind it to a key, though, it's a lot quicker. There is something to be said for emacs as a unified computing environment when compared to the UNIX way of doing things. Instead of wrangling different parts of the filesystem and tying them together with aliases and shell scripts, you can just version-control the productivity software (i.e. your emacs config) you write in the course of using emacs.

And now since I'm sucked into the cult of the helm-o-verse I find I am binding many fewer keys. Just start typing 'M-x ar' and now it's the second item. Add another 'r' brings it to the fore. Less (for me) to remember.

I note this mainly because it took me quite a long time to grok helm. Keep working with it!

You don't need Helm for that: smart M-x aka "smex" accomplished that for me and let me stay with ido, as I find Helm too intrusive.

Oh I really really loved smex. That's probably why it took me so long to get helm. helm doesn't improve on smex for this use case, I think. At least the stupid simple way I'm only going to use helm. But helm improves on other things spectacularly.

I'll be that guy ;)

In vim/unix you can run this command (keybinding not included but simple enough):

  :'<,'>%!awk 'BEGIN {ORS=" "} {print "\" $1 "\"," }

As for a unified computing environment, it is unified with the OS and not a world unto itself, there is no need to have one way of doing things within the editor and another if you want to script something. Both work just as well with version control, plus it gives you the flexibility to change text editor, like from vim to kak.

Speaking of kak, multiple cursors > any of these scripted options.

Yes, vim has a multiple cursor plugin that is useful for things like this: https://github.com/terryma/vim-multiple-cursors.

It's not as good as sublime in my experience, and I haven't used kakoune, but it's very serviceable.

Just put the following in your bashrc and it will simplify everything:

Alias emacs=‘vim’

> Once you bind it to a key, though, it's a lot quicker.

but that's something any IDE in the world can do ?

A lot quicker to do something specific. What if your problem involves text, but is always changing? Then you need general tools and a way to compose them together. Just like general Unix command and Awk which automatically loop through files. I would go crazy if I had to write actual code to do that kind of work 50 times a week.

A difference between emacs functions and awk one-liners is that the former are highly composable. Over the course of weeks you can build whole libraries of custom text-manipulation functionality for your particular domain, all integrated seamlessly into your editor. The thought of calling out to tools like awk for this is really galling. Could just be me, though.

Yeah...I was thinking about just writing a bunch of Powershell or TCL to make an expert shell. Sounds like a similar idea.

Easier: C-u M-| will run a console program against the text.

It's great for running sort, awk, sed, etc.

I've been using Emacs for a very long time, and I do this on a fairly regular basis. I always used macros, but this function wins, hands down. Great job!

I have used Excel's TEXTJOIN function for such cases.

I achieve the same by running two consecutive regex search and replace and a single backspace click

    s/^/"/
    s/\n/“, /

(Change all beginning of line to double pling. Change all new lines to double pling, comma, space)

I don’t even store this as a procedure, I just ctr-f and do it from whatever text editor I’m in (I’m not an Emacs user)

The nice thing about search and replacing your way out of problems is that it works on coworkers machines.

I’m not saying it’s better than a stored procedure or a macro but once you’re into it, it’s easy to regex your way out of all sorts of adhoc problems :)

I also prefer a more universal method. Arrayify is the equivalent of those useless specialized vegetable cutters and carvers in the kitchen that Alton Brown so hates. Search/Replace with Regex is universal.

Arrayify breaks down with the slightest change in requirements.

And then you write some more elisp

That's the whole point of a system like emacs: it enables the users to easily write solutions to their specific problems. It doesn't have to be general, it has to be easy to solve the problem at hand. It's the same with bash and unix tools. Writing general bash scripts is a nightmare, but datamunging particular problems works really well.

arrayify will also work on co-workers machines. You can open files on remote machines with tramp mode, and screenshare via zoom or something

I'd always write a basic macro by hand in such a situation: F3, ", END, ", comma, DEL, space, right arrow, F4 however many times I need.

To run the macro as many times as possible, M-0, F4 (Alt-0, F4).

I have a similar function. I find the inverse also very useful - especially for diffing things

In vim:

    :'<,'>!awk '{printf("\"\%s\", ",$0)}'

or to do the whole file:

    :%!awk '{printf("\"\%s\", ",$0)}'

What I find nice about this approach is that I can use my knowledge of awk in other non-vim contexts. Similarly I can use my knowledge of other text processing commands to do things in vim, like reformat text into columns (:%!column -t) for example.

Of course you could use vim commands to do the same thing:

   0<ctrl-v>GI"<esc>$<ctrl-v>GA", <esc>VGJ

Which would have the benefit of making it more customizable at the expense of....well you can see what you have to type.

> I can use my knowledge

That’s a great point. On the other hand, truly, “What happens in emacs, stays in emacs.”

Of course you can do the same shell thing easily enough with emacs, too.

The way I'd do it in vim is to record a macro of doing it interactively by hand once, then play back that macro. I have space bound to @q to make playing back the macro in the q register easy (using the q register because q is also how you start and stop recording a macro.)

    noremap <Space> @q

These days I do this from evil-mode:

    (define-key evil-normal-state-map " " "@q")

You can use your knowledge of emacs in other non-emacs contexts as well! Elisp is a reasonably capable, if sprawling, programming language and comes with a lot of useful text and code munging stuff, as well as with cross-platform networking and filesystem support, and more esoteric stuff like calendar and symbolic/aribtrary precision math. And that's before installing any extra packages. I've written shebang scripts with Emacs (rather than say python or bash) on multiple occasions. Prior to windows growing linux support it probably also used to be one of the easier ways to write some unixy-feeling but cross-platform scripts; you can even craft a "shebang line" that works for both windows and unix. Having said that, due to general eco-systems advances, writing scripts in emacs has probably become less attractive than it used to be.

I really dig that about emacs. Having a programming language that is geared toward text processing is super useful. Doubly so when your editor is extensible in the same language.

That's fantastic! I'm definitely adding that to my spacemacs setup.

I usually end up doing that in two steps, with the first being a recursive macro to quote each line:

    q y s $ " A , <escape> 0 j @ q

Then visually selecting and replacing new lines with spaces:

    V G :s/CTRL+Q CTRL+J/ /g

I use a VIM macro for this.

Yup, same here. @aI"<esc>A",<esc>j off the top of my head and then something like 1000@a. I'd then just add brackets and remove the trailing comma.

Showing off macros (in my case evil mode, but I suppose it's the same for emacs) is a nice party trick that has impressed some of my coworkers.

Sadly it does not really do so well at actual parties...

Just turned this into a Visual Studio Code extension: https://marketplace.visualstudio.com/items?itemName=Korfoo.a... Always wanted to try making an extension, but never had a good idea, thanks! :)

This is mostly a listing of packages and very known ones at that.

One of the best features I like is undoing regions. That is, if you know the approximate location of the text that you want to undo, you just select a region that contains that location and call undo. It can be used as a quick git alternative. Say you modify the buffer all over the place. If you want to undo some text that you've modified an hour ago but you did other modifications to the buffer in countless other places, you can undo just that region and you don't have to go back throught the whole undo tree.

Another one that I've currently discoverd and I'm very excited about is yasnippet (the modern variant of abbrev). You can define a string that stands for an abbreviation for an expansion. Everytime you type that string, it is replaced by that expansion. The nice thing about yasnippet compared to abbrev is that, among others, you can specify where to leave the cursor after the expansion. One example: "lt" expands to (let ((_))), where _ is the cursor position after the expansion. This also saves typing of all the parantheses. Or "mcar" expands to (mapcar (lambda (_))). You can expand anything to anything, in short. With time, you can type less and faster.

Yasnippet is amazing. Being able to tab through different fields is a game changer. You could make a snippet for every lisp function and never have to enter a paren ever again! The only probablem is that yasnippet can’t handle multiple nested expansions: it only keeps track of the current expansion.

If you set `yas-triggers-in-field` it will work with multiple nested expansions.

> you just select a region that contains that location and call undo.

What the fuck, how did I not know this. I am now glad that I read this thread. So much time lost undoing a bunch of changes, killing the piece I want to restore, redoing the changes and then yanking.

Hahaha! Nice! Exactly the reaction I was hoping to see. I'm really glad that that helped you.

Indirect buffers is another awesome feature of Emacs, that AFAIK no other editor is capable to do. You can basically clone a buffer of the current file and work in two (or more) buffers like they all belong to completely different files.

It's handy when you're writing a function that uses things declared somewhere else in the same file. Instead of jumping back and forth you just clone the buffer and you can collapse and narrow things independently.

I've used Emacs for decades and still feel like I'm barely scratching the surface.

What would really help me with articles like this one is more narrative on _why_ these particular modes are so useful. For example, it took me a long time to learn org-mode because I just didn't know what to do with it! I feel like Helm is similar, I've tried it briefly, but I'm not sure if or how it would fit into my workflow.

I completely agree. I used vanilla Emacs for about a decade before finding list-packages. (I know, I know. I was really behind.) But stuff like org-mode never clicked for me. I had to sit down with the manual and read it to finally get a handle on what it is.

I'm currently drafting an essay on what makes org-mode compelling, rather than how to use it. I think I'll do the same for other tools I use.

Awesome! I love reading essays like what you're planning on writing. Let me know how I can help, for example: I'd be happy to review drafts, be a sounding board, etc - my contact info is in my HN bio. Let me know!

:) Thanks! I’ll ping you when it’s ready for some feedback.

> I used vanilla Emacs for about a decade before finding list-packages.

To be fair, list-packages is a relatively recent addition to Emacs (2012).

> I completely agree. I used vanilla Emacs for about a decade before finding list-packages

I think it helps to think of Emacs as just another platform - and a nice stable one. You may or may not use, or know about, all the "applications" available for it. New stuff comes along that you haven't heard about; you might occasionally want to review things; and it doesn't really matter if you don't.

I've been using it for the usual handful of decades and have gone through phases of using one exciting new thing or another, but I've dropped most of them - I no longer run builds from Emacs (I do recompilation in the background in a separate terminal), nor read mail or use version control software from within it. I don't use evil and my colour scheme is mostly black-on-white. My .emacs has ended up almost back where it was 25 years ago. (In fact it still has references to Epoch and Lucid Emacs in a couple of comments.)

The two additions in the past couple of decades that have made a big difference to me are Tramp (a nice upgrade from ange-ftp) and the ability to set non-integer line spacings.

As an Emacs neophyte and vi vicenarian, I'd love to know why you ended up ditching evil alongside the other goods. I see the ortholinearity of e-mail and vcs in an editor, but evil seemed to me living within the editor, rather than atop it. Appropriately: a minor mode rather than a major. Like, say, editorcfg. Was this not your experience?

Oh, evil wasn't something I ditched - I never used it. I just mentioned it because it's so often cited as a vital thing. (ooh, nice potential pun there in vi-tal... hm) Same goes for the colour scheme. It's the higher-level applications that have come and gone. Sorry to be unclear.

> I think it helps to think of Emacs as just another platform - and a nice stable one. You may or may not use, or know about, all the "applications" available for it. New stuff comes along that you haven't heard about; you might occasionally want to review things; and it doesn't really matter if you don't.

That's one of the best explanations I've heard. Thanks.

Interesting. This is probably a very subjective thing. IMO, this is analogous to selecting a keyboard. You can read all about the tactile feedback from a mechanical keyboard but it's different to find out which one "feels" right, also since I like "test driving" features for a bit and figure how to use it along the way I prefer the 'How' articles. However, I would love to read (and write) more about the 'Why?' behind the features as well.

> For example, it took me a long time to learn org-mode because I just didn't know what to do with it!

Carsten Dominik's Google Tech Talk is probably still the best intro:

https://orgmode.org/worg/org-tutorials/org-screencasts/org-m...

See as well this video for more recent demos (2019) by John Wiegley (the Emacs maintainer) and John Kitchin (a CMU chemistry professor who uses Org extensively):

https://www.youtube.com/watch?v=31gwvApo8zg

helm is a vessel that opens up many other things to shine... swoop is fantastic and uses helm for that, the ability to add spaces to your search and it do a match on two fields independently instead of a rigid string match is great too. many things use helm to show lists of things.

> I feel like Helm is similar, I've tried it briefly, but I'm not sure if or how it would fit into my workflow.

Prefix-based autocompletion is always good enough for you? I don't use Helm, at least not yet, but thought the Helm demo image in the article was enlightening.

There are these series of "absolute minimums" (https://www.youtube.com/playlist?list=PLd_Oyt6lAQ8RgaMN3JnmZ...) centered on Spacemacs (a modified version of Emacs) but they go over helm and a bunch of different things. Should be generic enough to be useful.

Another beautifully designed piece of Emacs software is magit, where the defaults are extremely sane. The package is self-documented and you can learn it all by typing ? anytime. Being able to git log the file you are in is also a huge plus.

Magit made me a better programmer. Learning `git` proper would probably be as good (and certainly get more street cred), but magit was more accessible and more fun to use since I was already emacs-proficient.

The thing I love about magit is that it taught me git. You can hit $ and see exactly what I’d bring run and many of the options are in the pop up.

I'm still not sure there's anything better than magit on the market.

People say org is the killer app, but imo it has nothing on magit. (It's a weird comparison Ill give you that)

I'm thinking of donating again

These days, Magit is the only thing I consistently open Emacs for.

Can't say enough good things about Magit, it is astounding how much better it is than other version control software built into IDEs. Magit feels like it expands what I can do with git, rather than other IDEs dramatically limit what git can do.

For instance interactive rebaseing is so much better in Magit.

Funny, Magit never clicked for me. Maybe because I'm used to the quirks of the Git CLI and have aliases setup that speed up my workflow considerably, I never could reach the same productivity levels with Magit, and I've tried several times over the years.

Magit forces certain workflows because the author and community feel those work best, and stepping outside of that is often an exercise in frustration because you're not doing things "the Magit way". After going through a few issues on their tracker it was clear that there's no place for improvement suggestions unless it aligns perfectly with the maintainers' vision.

It feels very "holier than thou" and the constant hype around it everywhere is a bit off putting. Maybe it's just me, but I prefer using plain Git in a regular shell (Emacs shells are also unusable for me), with shell and Git aliases, and helper tools like scmpuff[1].

[1]: https://mroth.github.io/scmpuff/

I used to think that Emacs is some weird editor with absurd keybindings, until I learned lisp and understood what makes it so special. Now Emacs (Spacemacs[0]) is my main driver.

[0] https://www.spacemacs.org

How did learning lisp help you understand the power of Emacs? Just starting down the Spacemacs road myself (from Sublime Text), and curious to hear more about your experience!

In short, you can add new functionality to Emacs yourself.

And just like in the world of Lisp, after you add a new functionality, it becomes indistinguishable from what you already have. That is, it looks like it has been there all along, from the start. It doesn't look like a 3rd party plugin that you need to take special precautions to install. It just blends in nicely, and naturally.

Or, to put it another way, if you learn (Emacs) Lisp and you start to tweak Emacs to your own liking, you can transform Emacs into your own personal tool, adjusted exactly the way you like it, no questions asked.

Thank you molteanu for chiming in. I would also add, that everything has the exact same interface, meaning I can access every tool in the same way, the consistency is unparalleled. For example: In VSC when I want to use the shell, I suddenly lose my vim bindings and thus drop down to the casual user mode. In Emacs I can treat the shell like any other buffer, apply all my tools and knowledge, so it's nothing foreign or something that wants to be treated differently. For instance similar point in VSC regarding the file explorer, it forces you to abandon the keyboard homerow, I can't use my vim bindings from the plugin, because the plugin is something 'foreign'. Sure you can memorise shortcuts, but it's not the same as using your vim bindings for everything, always.

Yes, indeed. All the tools, all the time, always available. Something like writing a macro in Lisp. All the language is there at your disposal and it's nothing compared with C macros where you have huge limitations, it being actually a different language than C. I feel your pain with the VSC example.

"Consistency" is a good word. The result, for me at least, is that I can actually think about what I want to do with the tool and not how to use it. It gets out of the way, it does not try to fight me.

I think maybe that's one interpretation of the saying "Emacs is an operating system".

Emacs is basically a virtual machine for elisp with a couple of bindings to libraries for drawing things on a screen. Everything else, every bit of functionality, is written in elisp on top of that. For that to be possible elisp has to be a "real" programming language, with all the features you'd expect from a general-purpose language - and it is. It's also a lisp, however, so it has many features not found in most other languages.

Emacs is also an interactive IDE for elisp development. It provides all of the features you'd ever want from an IDE and then some. You get a linter, a debugger, semantic completion, ability to execute whole files or parts of them, data inspector/visualizer, finding definitions and references to symbols, a list of functions in a given file and across many files, shortcuts for common editing tasks, refactoring support, and so on. It's a very featureful, modern IDE with special emphasis on interactivity.

The effect of these two characteristics is that in Emacs you can easily find an implementation of any feature (no matter if it comes from Emacs core or some plugin), then edit it and see the results instantly (without the need for as much as saving the file), all the while having access to all of the IDE-like tools. You can customize every part of Emacs to exactly fit your needs - if there's something you'd like to change, but the feature's author didn't create a setting option for it, you can go locate and change the implementation in a few minutes.

When a computer game comes out, sometimes the authors also release a development kit with things like a map editor, theming support, tweaking AI and so on. Using (most) other editors is like simply playing the game: you can get better at it, but you can't change the rules. Using Emacs is like playing the game with the ability to instantly switch to the dev kit: you can simply play the game, but you also can bend, change, or rewrite the rules as you wish. With (most) other editors you're a consumer; with Emacs, you are the owner.

To really make use of all of that you have to know elisp, which is why knowing it is important. Of course, you can happily Emacs without dabbling in its configuration too much, but in that case, Emacs becomes just another editor with lots of awkward key bindings and a huge amount of cruft accreted during the last 40+ years.

I think there are weird things about spacemacs. It’s probably somewhat good for someone who doesn’t know any emacs because a lot of the emacs defaults are bad. And for someone who wants vim bindings it’s good because it has a lot more than evil mode does. On the other hand I feel like a lot of the layers are developed by people who spend too much time tinkering with editor features trying to make the most complicated thing in the process. And this means they’re not bothered by needing to tweak configs all the time, and they are frequently restarting emacs so they don’t notice things like the terrible performance it can give people who use emacs in the more normal way of opening emacs on Monday morning and not killing many buffers all week.

The complexity can leave you with weird bugs. For example if you use regular emacs (X forwarding over a network) on X displays with different dpis, your text will look the same (physical) size on both. If you use spacemacs it can be wrong on one because of some hack someone added somewhere in that tower of complexity. There are plenty of other oddities in there.

Also as soon as one advances to wanting slightly more customisation, it can be really hard to do it with spacemacs. Whereas with regular emacs it’s quite easy to go from basically zero to some.

I can echo this sentiment.

Spacemacs made my transition from Vim much smoother, and introduced me to many great packages and ways of configuring Emacs, so I'll always be grateful for that. It's a wonderful project.

But after a few months I started noticing those issues it introduced because of the additional layers of complexity, and decided to start from a scratch .emacs.d and add packages I strictly needed. It's surprising how much can be accomplished with just use-package and a init.d inspired loading structure.

The best thing about Emacs is its malleability, and relying on others to do this for you can be helpful, but is usually not what works best. I suppose this also applies to every 3rd party package you depend on, but I'm not versed in Elisp enough yet to _really_ build my Emacs experience from scratch. ;)

Emacs is the spaceship of typewriters. Whenever I try using it, I end up feeling like a centipede who began thinking about which leg it should move first.

I installed Doom[0] and called it a day!

[0] https://github.com/hlissner/doom-emacs

I had a fairly large config and kept running into problems with speed. I gave up late last year and tried doom and haven't looked back. Very fast compared to what I had hobbled together.

Looks interesting, but the main page claims it has support for a lot of languages, but according to this module page it only supports javascript, typescript, and html?

https://github.com/hlissner/doom-emacs/blob/develop/docs/ind...

The TODO is regarding documentation iirc.

All the languages supported are in the init.example.el file seen here: https://github.com/hlissner/doom-emacs/blob/develop/init.exa...

Uncomment them, run doom refresh. Check their module under https://github.com/hlissner/doom-emacs/tree/develop/modules/... for any external requirements that they need or flags that they support.

The comments are hilarious:

;;hy ; readability of scheme w/ speed of python

;;rust ; Fe2O3.unwrap().unwrap().unwrap().unwrap()

;;javascript ; all(hope(abandon(ye(who(enter(here))))))

From my experience, most of the packages listed there with TODOs have basic support with some extras, but are lacking documentation and testing. For example rust, supports syntax, formatting, lsp or racer, cargo and other goodies.

Doom is great. Here are my notes on Doom workflow: https://noelwelsh.com/posts/2019-01-10-doom-emacs.html

It might be a bit out of date now but at least 90% still holds.

Helm-projectile rant is well deserved. I'm often ashamed looking at my colleagues trying to find some file with a mouse in their big fat IDEs.

Mortals. LOL!

All decent IDEs have a file search command.

I like Emacs a lot, but it' definitely lacking most of the advanced IDE features, and the Emacs features that a decent IDE (read: Intellij) implement are usually "good enough" for me.

People who've been using only Emacs for the last 20 years are in no position to comment on IDEs

With lsp-mode, there’s really nothing I can think of that emacs can’t do compared to IDEs. In fact, emacs blows them out of the water. Before LSP was invented, I would have agreed with you. But pretty much all IDE features have been commoditized by LSP now.

I only know about the example of Rust, where IntelliJ is still significantly better and faster than lsp.

The man-or-boy test for IDEs was proposed long ago by Martin Fowler. If the editor can do the ‘extract method’ refactoring, then it's an IDE that properly understands the structure of the code.

More generally and forgivably, I'd say the IDE must know that two variables of the same name may be different variables, and to know which instances are which vars. Funny enough, this benefit of IDEs might rarely be felt with Javascript due to its uber-dynamic nature (at least without classes).

Are there any languages other than C#, Java and maybe Dart that have these features?

As soon as you add any kind of metaprogramming or macros to the mix, IDEs start to break, because they can't refactor code that doesn't exist yet. That's an issue for IDEs for C, C++, Rust, D and probably few other languages.

> Are there any languages other than C#, Java and maybe Dart that have these features?

If you're talking about ‘extract method’, any regular imperative language in the C style should have that―possibly as ‘extract function’. I mean also Python, JS, Ruby and the like. The hard part here is to figure out which vars go into the method/function and which of them must be accepted as parameters or returned from the function―that's where the understanding of code structure comes in.

Sure, fiddling with metaprogramming will break IDE's understanding of the code, e.g. in Python, but you can do that carefully and isolate the effects so that the rest of code is still ‘clean’. That's also why Java integrates any and all features into the type and OOP system (afaik), so the code can always be described statically. I guess Haskell is an extreme example of that, but not sure how IDE-friendly it is.

I use emacs, but I don't think lsp-mode can do all the refactorings which intellij provides:

  Safe Delete
  Extract Method
  Extract Constant
  Extract Field
  Extract Parameter
  Introduce Variable
  Rename
  Inline
  Change signature

Refactorings are great, because you can do safe code transformations very quickly. If you get to know these features, it's hard to do without them.

Emacs's greatness lies somewhere else. Its extensibility is unmatched. IMO there's no other software product ever been created that can be extended like Emacs.

I'm sure if given enough resources and motivation, it's possible to build superb support for the modern programming languages. For example, you wouldn't claim that Intellij/VSCode/Sublime/Atom has better support for Erlang, for OCaml, for Lisp, for LaTeX, would you?

Emacs evolves slowly. Things take time. And yes, there are always IDEs that do things [slightly] better. At a given moment. Remember, though Emacs outlived many trendy IDEs. Relatively not too long ago IDEs like C++ Builder and Delphi Builder, Eclipse, NetBeans were quite popular. And they did have some remarkable features that Emacs didn't. Do you see any HN posts about those anymore?

Now check, for example, Github Language Stats¹ and find there emacs-lisp. Isn't it surprising to see it somewhere in the middle of the list? Isn't it surprising that it made into that list at all? Remember that it is not a general-purpose language; it is not used in the enterprise; it is not used in the game industry; not suitable for writing mobile apps or web pages. And it also a pretty concise language, it's a Lisp. But there's a lot of it on GitHub alone. Who are these people? Who writes all that code? And how the heck they keep doing it - none of them ever have gotten paid for it, aside from some tiny voluntary contributions and hugely successful Kickstarter campaign for Magit.

If a programming language stays relevant for long enough, people eventually will build emacs packages for it, and they'll keep improving them. But for a proprietary IDE, if it doesn't have a feature you like - you have no other option but to submit a request and wait. Sometimes you have to wait indefinitely.

> People who've been using only Emacs for the last 20 years are in no position to comment on IDEs

I moved to Emacs after almost 20 years of using IDEs. If I am still programming 20 years from now, I'm sure it will be in Emacs.

____

* ¹ https://madnight.github.io/githut

Somehow my colleagues who use VS Code or JetBrains IDEs don't manage to learn about those features while all of my vim-using colleagues somehow do. (Haven't worked with anyone using Emacs yet)

I use CLion almost exclusively and I use shift-shift to find things so often that I have basically no idea what file anything is in.

Is there anything free that even begins to approach the quality and accuracy of the JetBrains Rust analysis plugin? If so, I’d love to know about it and start using vim.

I'm sure there has to be a vim plugin for rls

Yes, there is. But RLS is much worse than the CLion Rust plugin, in my experience.

In JetBrains you just double shift and a small searchbar opens to allow you to type in any file name. It autocompletes so you do not have to remember the whole name. It is pretty neat.

Not just any file name, but any symbol.

> All decent IDEs have a file search command.

Yes, all decent IDEs have file search command. But Emacs got SEARCH:

- You can search for all files that contain given string and then open the search results and modify occurrences using multiple cursors and then save it, and it will propagate changes in multiple files;

- You can recursively search for file names, then (for example) mark those that are bigger than 15Mbs, or files that were edited last time in March, and then tell Emacs to show git-log of changes, but only related to those files;

- You can search for a pattern, but also tell it to display it with a context (for example 4 lines before and after the occurrence);

- You can recursively search for a filename pattern, and then among those that you find, you can rename those that match a regexp;

- You can git-grep for a file that was deleted in the repo;

- You can find all the compilation/linting errors and warnings in the code for a given project;

And guess what? All that works the same way for remote machines. You can use the search on a remote computer and open files, just like it was a local machine. Heck, you can even search and open files inside Docker containers.

You think I'm done here? I haven't even talked about searching for stuff using Org-mode.

Seriously, whenever there's an argument about IDEs vs. Emacs - Emacs just beats the shit out of any. "But it doesn't support re-factoring... bleh-bleh." Like everyone who seriously uses Emacs really doing it because they hate refactoring or something. Emacs has better tools and a myriad of ways to deal with code.

Well, not if they use Notepad.

Is there anything like vs-chromium's code search in emacs? After finding vs-chromium I lean on it so hard that when I tried to switch to emacs, helm-projectile was good but wasn't good enough.

Plus I'm on windows and there was enough friction where things kind of worked but didn't (usually environmental things like it couldn't find ag or awk, process lifetime, window drawing, etc.).

Not sure how vs-chromium's search is, but I use helm-projectile-rg for searching, and it's pretty nice (and super fast)

> All the packages were installed from Emacs package Manager. By running, `M-x list-packages` This should bring up a list of packages available in MELPA. Now, don’t worry if you don’t know what MELPA is, just think of it as a repository of all packages, as in, analogous to the Debian Package Repo in Debian/Ubuntu distros.

Article seems to confuse MELPA with ELPA. MELPA is something you have to add via your init file. Not terribly hard to do, but just FYI for anyone who is actually using these tips from scratch.

I use Emacs every day. But only for org-mode which is fantastic.

Besides that I really really tried hard to love Emacs as my go-to editor. However I found no alternative for

decent CSV file support (like https://github.com/chrisbra/csv.vim simply great!)

Inspecting large XML files with syntax highlighting and folding. VIM is also not the fastest here but at least 10 times faster (emacs SGML mode is a joke for xml files and forcing xhtml mode of web-mode is also not that great)

Maybe all my emacs doing was just wrong.

Sad to see you're being downvoted for valid points. I'll admit I'm glad I don't have a job that involves staring at CSV or XML all day but I've found csv-mode and SimpleEmacsSpreadsheet lacking over the years, and large XML files can indeed be slow.

I wonder if some of the down-votes is from people who have tried to edit large XML files in the past with vi (Note: original vi, not vim) and discovered it chokes and fails to do so, complaining of over-long lines.

One of the reasons I switched from vi to Emacs in the very distant past was for this specific reason. (Vim did exist, but it wasn't installed on the old Unix machines I was working on).

csv-mode does exactly what you want.

Filter rows based on a value?

Deleting a Row?

Easily navigating from the nth element in a CSV header to the nth element in data row 1000?

Sure, just use SES and import the CSV. It’s no excel, but it does what you’re talking about.

also tramp, for editing files on any machine you can ssh into ...

https://www.emacswiki.org/emacs/TrampMode

<Same response as org-mode> A resounding YES! But Org-Mode and TRAMP are so well written about that although I have "special" setup for these in my config I felt I could not do more justice than other expert write-ups. Maybe, I should add them in a separate entry.

Now I understand why the saying goes like:

Emacs is a good OS... ;-)

I used TRAMP a lot in the past, for some reason I have mostly forgotten about it. Maybe my projects just changed in nature?

Thinking of it, what I do rather frequently is ssh into a server and sudo -e there (root account is locked). I'm somewhat confident that TRAMP can be configured to do that. Need to investigate when I have time.

I am using tramp primarily to edit files inside docker containers. https://github.com/emacs-pe/docker-tramp.el

use-package would be an improvement upon most of the code snippets in the blog post. Loading packages without it these days feels like a sin.

I would also recommend straight.el or perhaps even guix.

I'll give another vote for straight.el and its use-package integration.

I'm ashamed to say I've been using Emacs since 1992 but I have never been able to impress into my brain anything other than the minimal set of keystrokes to do basic editing. I feel like I need to be trapped on an island where the only thing I could do was learn emacs for a bit. There's so much there to dig into.

This is why I regularly create hydras for every emacs mode that I use. That way I don't have to remember any extra keystrokes, as the hydras will remind me.

What's a hydra? (in this context)

A cluster of Emacs keybindings that share a common prefix, implemented using the hydra library:

https://github.com/abo-abo/hydra

So it's sort of like a mode switch? You give the prefix, and then you can give it a whole series of commands, based on a crib sheet that it shows you, that have that common prefix - without having to retype the prefix - before passing a different key to drop out of the mode again?

That does sound potentially handy, if I have it right.

Yes, though I'd describe it more as a fully-customizable popup menu that appears when you type a certain keystroke. Once the menu appears you can type more keystrokes to perform an action or bring up another custom menu.

Also, it's possible to configure it so that there's a delay between the time you type a keystroke and the menu appears, so that if you remember the key-sequence you need to type to perform a certain action and you type it fast enough, then the menu won't pop-up, but if you forget the full sequence then you can type just the first keystroke and then wait a bit and the menu will pop up and remind you of what needs to be typed to execute the action you want.

It's super handy, and is one of my all-time-favorite emacs packages.

Just joining the basic editing keystrokes using macros (F3 to record, F4 to finish and play back) adds plenty of power.

One of my favorites is creating a separate backup dir where all backup "~" files are created and versioned and rotated in and out etc at specific intervals, so I no longer get the random files in the dir I'm working in but can still go find backups if I mess something up.

  (setq
   backup-by-copying t      
   backup-directory-alist
    '((".*" . "~/.emacs.d/bu/"))
   delete-old-versions t
   kept-new-versions 6
   kept-old-versions 2
   version-control t)

I already use this in my shrc files:
alias ls='ls --hide="lost+found" --hide="#*" --hide="*~" --hide="*.pyc" --hide="*.egg-info" --hide="__pycache__" --color=auto'
But I'll be adding your item into my config for the rotated versioning, I wasn't aware that emacs does that but I assume it'll save me anything from few hours to a few weeks yearly. Thanks!

If you like it check out this and see if you like anything else: https://sanemacs.com/sanemacs
or https://www.sandeepnambiar.com/my-minimal-emacs-setup/

I'm extremely surprised to not see Spacemacs mentioned in the article or the comments. Spacemacs is, IMHO, the most sane and useful default configuration of Emacs. It is friendly to people switching from vim and includes all the packages listed in the article by default (as well as many more).
It has been my go-to editor for many years now; I highly recommend it.

One of my favorites is creating a seperate backup dir where all backup "~" files are created and versioned and rotated in and out etc at specific intervals, so I no longer get the random files in the dir I'm working in but can still go find backups if I mess something up.

org f-ing mode
edit: actual package is called "org-mode"

A resounding YES! But Org-Mode and TRAMP are so well written about that although I have "special" setup for these in my config I felt I could not do more justice than other expert write-ups. Maybe, I should add them in a separate entry.

What's the point of TRAMP when you can just use the FUSE sshfs module?

Can you compare and contrast the two? I really like tramp for seamlessly editing files on a number of remote VMs. You can even edit files inside Docker containers on remote systems via multi-hops. Tramp is a huge timesaver.

Well one major thing is that tramp is inside emacs so you can configure it with elisp, which is a major plus in my mind. The main problem with tramp is that Emacs is single threaded (and elisp threads run one at a time), so networking operations can be iffy. On most normal connections it works fine in my experience. Another reason to use sshfs is if you're switching between Emacs and a separate terminal, you don't need another connection. That goes away with vterm since now you don't need a separate terminal (it fixes a lot of the traditional problems with ansi-term, shell-mode, and eshell. Although there's a good argument to make for using eshell as your main shell).

By vterm do you mean this?
https://github.com/akermu/emacs-libvterm/blob/master/README....
It seems extremely experimental, and I've been trying recently to make my emacs more stable so I can choose when I want to spend time editing my config.

It seems stable at this point. I've dropped using anything other than eshell & vterm in Emacs.

Can confirm—vterm is very stable now. I've ditched separate terminal applications and exclusively use Emacs+vterm.

Thanks
Is there a way to get fuzzy searchable history ala bash Ctrl+r?
Also I've noticed that if I use any emacs movement command (say jump to start of line) vterm looses internal sync and my edits edit the wrong text. Is that an issue specific to my config, or do you have it as well?

you should be able to leverage normal bash/zsh/&c. functionality.
the emacs movement issue I don't have, so perhaps that's a configuration issue.
(one perhaps useful tip: `vterm-copy-mode`, by default bound to C-c C-t, let's you navigate the buffer with normal emacs movement in order to copy)

org-mode for notetaking/journaling/organizing and writing documentation with org-babel for interactive (literate) programming and making diagrams (gnuplot, matplotlib, graphviz, mscgen, plantuml).
Can’t say this for many tools but using org-mode has been life changing for me.

I'm writing a novel with org-mode and it's the most transparent writing tool I've ever used, and so flexible too.

What is the emacs equivalent of package.json?
(whenever I git clone my dotfiles on a new machine I usually have to comment out a bunch of stuff in my ~/.emacs because it's referencing packages which aren't installed, and I forgot where I installed them from, what version, etc...)

I think you're looking for https://github.com/jwiegley/use-package ?

That looks awesome! All of a sudden I feel so primitive with https://gitlab.com/brlewis/brlewis-config/blob/master/emacs/...

It's really handy if you don't use spacemacs / doom-emacs.
My (old) config used it heavily. It also defined everything inside a single org file which also serves as a README on github: https://github.com/kwrooijen/.emacs.d
However these days I'm using Spacemacs, currently looking at Doom.

I use straight.el[0] for a reproducible package list. It basically clones the packages and stores a map of package->commit, so you can freeze your packages and reproduce them on another machine.
You could also use the Guix package manager[1] or the Nix package manager[2] to achieve a similar effect.
Reproducible software is much more stable!
[0]https://github.com/raxod502/straight.el
[1]https://guix.gnu.org/#guix-in-other-distros
[2]https://nixos.org/nix/

Awesome, thanks!

By default, Emacs doesn't have an equivalent. Although, if you want to use a package manager that supports version lock files, I would recommend straight.el.

Being emacs, there's a bunch of different ways to do this.
I use Cask: https://cask.readthedocs.io/en/latest/guide/installation.htm...
Let's consider Homebrew bundle etc outside of scope and assume you have some workflow that works for you to init a new machine with emacs and some other apps, and you're just worried about the zillions of little emacs packages you are testing or using.
So, I have a file called at ~/.emacs.d/Cask, that is just a list of packages on which I depend. This is the only way I install packages. Update the file and do "cask install".
This also means if you're packages get weird, or you have some sort of transient .elc problem you can just blow away ~/.emacs.d/.cask and do a 'cask install' (basically .cask ~= node_modules)

Alternatively, if your workstations are all relatively similar, you can sledge hammer it and just commit all of ~/.emacs.d/ into a private repo, including the packages. It saves me the headache of babysitting dependencies (at the cost of probably not being able to move to Linux without some friction? Never tried.) Caveat emptor.
Additionally, I recommend judicious use of (when (boundp 'some-thing) (some-thing)), and (fboundp ..), and (if (require 'foobar nil :noerror) (foobar-mode 1)). This avoids the cascade of errors on installation troubles (at the cost of not being alerted if you're missing them).

Most Emacs people use use-package for this.

It seems a lot of people have used emacs for years and love it. I never saw the point of learning as it seemed cryptic. In 2020 is it worth putting the effort to learn now? I figure with vim and IDEs I dont really need it.

I switched to emacs in 2019 after using primarily vim for 12 years, and I think it's more than worth it. It's not an editor, it's not an IDE, it is kind of like an operating system where you can have a text editor, debugger, notes, mail, whatever you want. If you dig that, you'll love emacs. It's extensible in a way you've probably not experienced anywhere else, so if you like honing your tools so they fit the way you want to work, emacs is for you. I've actually come to long for an operating system that gives me the same "interactivity" as emacs does.
Of course, I edit text in emacs with evil: https://github.com/emacs-evil/evil

> not an editor
It's "editing macros," so yes, it's an editor first and foremost.
> not an IDE
It's integrated; mostly used by developers; it's an environment.

I mean, I play NetHack in it. I don’t think any IDE has that kind of flexibility.

http://eclipse-games.sourceforge.net/

That's nothing. You can do, in Emacs:
- Run Nethack
- Chat over IRC. Double combo with Bitlbee
- Chat over Slack/$whatever proto is designed in Elisp
- Write Interactive Fiction
- Emulate Interactive fiction with a Z machine in Elisp
- Write and read emails/news with GNUs
- Listen to music with EMMS
- M-x doctor because is too complex and you need to talk to someone
- Comment on HN with eww
- Do literate programming
- Do math, and with Maxima/R, algebra/statistics/whatever
- Use GIT with Magit
- org-mode. With this you could write three ebooks larger than the Java specs.
- org-babel. I forgot it. This is damn magic. Programming as if you were in a word processor, going back and forth, easily, showing up your results inline.

Editor wars, won.

I particularly like calc mode. Top notch programmable rpn calculator with basic CAS support. Good for most algebraic transformations plus derivatives and integrals. It also supports graphing!
Also you missed that you can run WebKit inside of emacs. Also you embed X apps in emacs and use it as a window manager.

> embed X apps in emacs
Not in the console mode, you can't.

My highlight of 2019 was learning emacs.
I see it as an investment, since it will probably outlive me and anything an IDE can do, _technically_, can be done in emacs.
I was previously a vim user and I wanted to extend my editor but I really hate vimscript. I took a look at Emacs's Elisp and I liked it. To my surprise, the ecosystem was updated with my current tech stack (TypeScript, with the Tide plugin). I was really used to vim so I decided to create my own 'distro' and I began recreating some vim editing functionality along with similar keys (Since I'm not using evil mode or anything, I just made a prefix with Ctrl).
At the end I realized I only liked vim because of its ubiquity and keymaps.

> Is it worth putting the effort to learn now?
As a big emacs guy, I say it's only worth putting in the effort if you really enjoy the process of crafting a tool that fits the shape of your mind and bending your mind to fit the shape a tool. I personally get a lot of pleasure out of improving my text editor, but I don't think most people will/do.
Depending on your choice of IDE and your proficiency with vim I think the efficiency gains you'd get from switching to emacs will be relatively slight.

If you already have a wife you love, then no, it does not necessarily make sense to try and marry somebody else's, even if you know he loves her.

As a long time emacs user, I'm sad to say but I've become pretty content with Visual Code and I don't think I'm going back. Ofcourse, took a lot of time customizing Code retaining all my emacs keybindings, etc.

What was it that made you move, and what is it that will make you stay?

a few I use:
(defun shift-left (beg end) (interactive "r") (shift-region beg end -1)) (defun shift-right (beg end) (interactive "r") (shift-region beg end 1)) (global-set-key [A-M-right] 'shift-right) ;; >> shift every line of region (global-set-key [A-M-left] 'shift-left) ;; << (and region remains highlighted) (global-set-key "\M-+" 'text-scale-increase) (global-set-key "\M--" 'text-scale-decrease) (global-set-key "\M-=" (lambda () (interactive) (text-scale-set 0)))

the others I cannot live without:
neo tree
winner mode
god mode (I use instead of evil mode)
avy (visually jump to any char on the screen)
undo-tree (really neat, though I don't use it as much any more)

winner-mode was new to me. Thanks! The most annoying thing about Emacs for me is random windows popping up; I'm a "separate frames" person (the OS window manager does fine for me, I don't need much help from Emacs), and anything that streamlines windows is great.

then here's another just for you!
;;from https://github.com/m2ym/popwin-el ;; prevents annoying popup buffers/windows (require 'popwin) (popwin-mode 1)

> (the OS window manager does fine for me, I don't need much help from Emacs)
Embrace the power of "and": EXWM.

I have tried neo-tree and undo-tree. But never really got around to using them well. Maybe, I need to be patient.

I find undo-tree to be super useful in rare occasions, thanks to undo-tree-visualizer-toggle-diff bound on d.
The quick diffs can be pretty darn helpful with complex changes.

Neo tree was annoying to me (coming from NERDTree). I remapped things to work like NERDTree ('l' for open? should be o!). And then I finally grokked how much simpler it was to navigate directories with hjkl. Plus ? to see how to manipulate files and just keep it there is great. Way more ergonomic than NERDTree or Treemacs imho.
Also since I'm going on here, I've found the key to editor management is to make sure certain basics work across the board (for IntelliJ/, Xcode/Xvim, (space)emacs and even vim - sometimes I use vim for config changes since it's so fast to open, tmux, etc).
C-o/C-i -> should work for navigation ctrl-shift-j -> should select the file you're working on ; -> should map to : (retrain yourself) fd -> escape (retrain yourself) c-hjkl -> c-w hjkl (faster window/panel navigation) gd -> should go to definition vim text motion in general should work flawlessly e.g., @q - should start to record a macro
I use spacemacs + tmux since I like to customize and it's easiest to customize in elisp I've found than in any other IDE or vim itself. And when things don't work and I can't make it work in the editor itself, I fix it in the terminal app (Kitty) or the OS (BetterTouchTool).
Shameless plug for those curious:
https://github.com/p10q/home/blob/master/.spacemacs#L343 https://github.com/p10q/home/blob/master/kitty.conf#L797

I have switched to treemacs a while ago (for a file/project explorer), and it's really powerful and mature, with interesting features like "workspaces", which allow you to have multiple directory views (which can be anywhere on your disk), and is managed with a convenient Org mode configuration (I wish more Emacs packages had nice Org-based configuration systems like this).

I use treemacs instead of neo-tree, love it.

An alternative to winner-mode is eyebrowse, for anyone interested.

emacs as a binary editor: useful. Any other uses: counter-productive. I've (painfully) watched some amazingly gifted researchers/engineers using it, and saw them waste about 50% of their attention trying to use it. Emacs is not an editor, it is an OS with non-obvious semantics.

If the author, @mycpuorg, is reading this comment: please, PLEASE, do write about your mu4e configuration.

@rntski, I will be happy to.
I feel I get a bigger bang for buck for Work Email on Outlook Exchange since Email on mu4e makes me less distracted.

This sentence is either missing a negation or correlates "bang" with "distraction", which is wrong since "bang" is positive and "distraction" negative.

You are right, scratch that and I will try this again. I meant to say:
I have configured and used mu4e on a GMail account and another account hosted on Microsoft Exchange Server (MSE).
The Linux based email client I had tried before mu4e for MSE account are: * WebMail (Outlook's less capable younger cousin on a browser) * a slew of Linux UI email clients like Thunderbird etc.
I disliked all of them equally. However, using mu4e for emails with Outlook/MSE account makes doing emails less painful and less distracting. However, using mu4e as a mail client for Google accounts may not be preferable if you have bought heavily into the Google ecosystem. I have had trouble with things like Google API authentication on Emacs.

My favorite these days is a package called find-file-in-project. Ideal for navigating large projects.

related, projectile-mode gives a bunch of similar niceties

I would be productive if there were an emacs that weren't a parenthesis hell and slow as molasses. I hope there's is a lumacs

Whenever I hear about or see the .vimrc and .emacs files people create, maintain and constantly modify to me this just looks like the perfect example of a sunk cost fallacy.
IDEs are usually dismissed by many such people since you can (allegedly) do the same in vim/emacs but to me this seemed crazy as I'd see people spend hours configuring plugins, writing Lisp and whatever to save them on some task they'd get for free with a right click in IntelliJ.
I really do think people completely underestimate how much time they have and will invest in such endeavours. I mean if this makes you happy or you like this tinkering, by all means be my guest, but I'll take a hard pass.

Would you rather drive a nice car that needs some loving care and maintenance once in a while or an old banger that just gets the job done? It's the same sort of prospect.
Some people like to work in a nice environment where they are able to remove all the little frustrations that less customizable tools often force upon you. When emacs annoys you at least you can fix it if it is annoying enough for you to want to do so.
In any case neither choice is wrong or right. Do whatever floats your boat.

You might as well make this point about all software. Can't people just use Excel? Why write something bespoke?

What’s Excel? apt search is not showing anything...

This is a strawman. Nobody endless tinkers with their .emacs file, unless they really want to. I change my .emacs file less than once a year.

Because when you start to feel like the editor is an extension of yourself the feeling is so sublime. I’ve had collegues who literall pick up there mouse and click to go to the beginning of a line. It’s sad.

It's not an example of sunk cost fallacy, much less a "perfect" one. If you insist on shoehorning it, then the fallacy argues against you since the future value of emacs is no longer diminished by the sunk cost of configuring it.

> example of a sunk cost fallacy
For some people, it's the other way around. Emacs makes it simple to automate things. And there's no such thing as "excessive automation." Proprietary IDEs are like Steve Yegge once said: "are cookie-cutter solutions." To me, it's not even about productivity; it's about minimizing frustration. Repetitive and mundane tasks (no matter how small they seem to be) can and should be automated.
Practical examples of how using Emacs makes my life easier:
- I conduct Web searches right from my IDE. I can search on Wikipedia, Google, Github, YouTube, WolframAlpha, etc. I can select any piece of text/code and perform a search. One day I even realized that I could also enforce the programming language on Github. It took me about ten minutes to extend the existing functionality of the Emacs package called `engine,` now whenever I'm writing, for example, Clojure code, and I need to search for a selected piece of code on Github it automatically appends `Language=Clojure` to the search parameters.
- We have a convention to have suffixes in our git branches that denote the ticket number associated. So I used to go to Jira, find my ticket, then think about the branch name, then type it, sometimes I would mistype the ticket number. One day I sat down, spend about twenty minutes, wrote a little piece of emacs-lisp. For a given Jira ticket number, it fetches its summary and then, based on that summary, generates a "git-friendly" branch name. It's not like it would take me too long doing it the old way. But now it literally takes less than a second, and it is way less frustrating.
- I use Org-mode, which by itself is a hands-down the best todo-list/organizer/note-taking/journaling app. We also use Slack at work. Very often, I would copy Slack conversation and paste it to my main org-mode file, so the relevant information (associated with a unit of work) is close-by. I used to do it manually. The other day I sat down and wrote a script that retrieves that info from Slack by using its API and automatically generates an Org-mode heading.
I can provide countless examples of seemingly small things like that, but those who are now settled with using their favorite IDE probably won't be impressed or moved.
Don't get me wrong - IntelliJ is a superb product. I myself used WebStorm, PyCharm, RubyMine, and Ultimate for a number of years. About seven years to be more precise. I learned their IDE to the pieces. I have discovered undocumented/poorly documented features. I used to hang big print-out posters with the major keybindings on my walls. I participated in developing plugins. But still moved to Emacs, because there is simply no software product in existence with the extensibility capabilities that can match.
Please, don't underestimate the ingenuity of tinkerers. Best artists, watch-makers, and carpenters are known to create their own tools or pick up designs of someone else's and improve upon them. In their hands, the instrument that they have might be a thousand times more powerful and capable, compared to one that was created by an army of specialists.

Reply on news.ycombinator.com