I have a few customizations, not many. My .emacs file is 63 lines long, doesn't include any other files, and mostly just tweaks some key bindings and turns off features that I don't like. The only modes I use are built-in ones (e.g., C-mode, auto-wrapping text mode, etc.). I can't write elisp without a reference manual, and I think that's okay.

I suggest:

- not installing a bunch of random stuff until you're comfortable with the core experience or you simply have to adjust or disable something that bugs you

- just using Emacs, and not customizing the crap out of it, ditto

If you haven't gone through the Emacs tutorial, it's how I learned it (at 300 baud, uphill both ways and in the snow -- not kidding about the 300 baud thing, though).

- Using the spacebar to invoke functionality is a massive physical boon to usage. Stock emacs wrecks me from fingers to neck for an real amounts of usage. This is a purely subjective weakness.

- Spacemacs vi emulation. I drank the modal Kook-aid. Especially if one has to SSH into headless instances in the cloud. vi is part of the POSIX standard, so you know it's there and it's robust.

- Spacemacs engineering. Great package integration in the form of layers.

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

The WORST thing about spacemacs though is their absolutely broken release process. The master branch rarely upgrades with fixes applied to the develop branch, and the tacit recommendation is just to run "on the bleeding edge." I have no idea why spacemacs users tolerate this, but my productivity has since improved after ditching it.

I can kinda agree the C++ layer was definitely a bit of a pain, but I had general pain setting up a good workflow for C++ in emacs with the project I was working on (most of the emacs packages assumed a different layout, so couldn't understand my CMakeLists to generate the files it would need to look at for smart completion).

Overall, I quite like spacemacs, I used to hack on it a bit to make it suit my needs better, but now I rarely have anything I need to do it "just works" now.

I particularly appreciate that almost any language I want to use, I can just download a layer (I think it often prompts you to install one when you open the file automatically!) and a lot of the common across languages editor functions you want have similar keybindings, and the `which-key` popup will tell you anything you're missing. It makes a very short ramp up to being productive in your editor for a new language.

https://github.com/emacs-evil/evil-collection

Which provides evil bindings for a lot of modes

Beyond that, add language modes for anything you need that's not already included.

If you use 'git', 'magit' is very nice.

Beyond that, helm is interesting, though very large and kind of mind-blowing.

Recommend these in your ~/.emacs.d/init.el, to avoid being that guy:

    (setq-default show-trailing-whitespace 't)
    (setq-default indicate-empty-lines 't)

    ; try not to use tab characters ever when formatting code
    (setq-default indent-tabs-mode nil)

    (setq-default require-final-newline 'ask)
    (setq-default mode-require-final-newline 'ask)

If you're talking about production hosts, they shouldn't really have vanilla emacs installed either. Not having your creature comforts present on production machines is a feature, like the red shell prompt / terminal background some people use, a reminder to get you to think twice and try to not do things directly in production. If you really must, just use TRAMP, it's amazing.

If, on the other hand, you're talking about using somebody else's laptop to do anything, that doesn't make sense to optimize for, at least in my experience. I prefer not to even touch other peoples' laptops/keyboards.

Tramp is great, but not all such hosts are reachable that way.

> I prefer not to even touch other peoples' laptops/keyboards.

Me too, but that's why they call it work.

I wonder if I'm weird, but I use a highly customized Emacs on my dev machine, but if I have to ssh into a host and edit something I just use vi there. The correct answer to vi or emacs has always been "both" for me.

(add-hook 'before-save-hook 'delete-trailing-whitespace)

This deletes all whitespace when you save a buffer.

; try not to use tab characters ever when formatting code (setq-default indent-tabs-mode nil)

And, of course, if you do any programming at all, you should install magit immediately. It is the best git experience anywhere, on any platform, period. It is an unbelievable productivity booster, and people who haven't used it do not even appreciate what it can do (ever wanted to quickly apply a single diff from one of your stashes to your current code tree? it's two keystrokes).

Approach emacs like you would a musical instrument: you are not expected to play the piano on your first day, and the first year will require some patience and training, but eventually you'll start playing those sonatas.

[context: my Emacs init file has lines that are 27 years old]

If so, I might want to try it.

More than simple fun; I've saved people from hours and sometimes days of drudgery with just a few minutes of mucking about in Emacs. Teaching someone simple automation is pretty rewarding. Even if they are not technically capable of repeating your solution, at least they go away with a problem solved AND the knowledge that there are usually better options available than drudgery.

That and white space mode for examining files..

evil is also great, and it might actually be the most popular option for new users at this point, thanks to Spacemacs and Doom.

Because it's so old, no one bothers to maintain compatibility with it anymore, and almost all modern elisp will break in some way if it's loaded in 22.1. Somewhat fortunately, it seems like Apple has removed this emacs binary from Catalina, so it won't be an issue on future versions of macOS.

To get a modern Emacs: https://emacsformacosx.com/ has binary builds of the official Emacs releases, with some additional scripts that let you launch it from Launchpad, etc.

The best way of learning Elisp is reading the source code that is distributed with Emacs. Do a git checkout of Emacs and read Elisp code written by Stefan Monnier. Stay away from org-mode elisp - the quality of that code base is highly suspect.

You can learn Emacs well just by starting with this manual and beginning to tweak Emacs to do things you want: https://www.gnu.org/software/emacs/manual/html_node/elisp/

Emacs Lisp is very low-friction to start hacking on. There's no SDKs to download, no IDE to install, no developer mode to enable, no project wizard to run, no source tree of template files to start from, no program to attach, no emulator to run, to separate build to run, no sandboxing, etc. You can just start Emacs, and start editing Emacs Lisp expressions and evaluating them, and you can change the code of your running Emacs in a very straightforward way.

I initially started by writing little fancy editing features for C and C++ coding (e.g., format my comments a certain way, do a expression transform, etc.), and then started writing to editing modes for my employer's proprietary languages. The public bits are at "https://www.neilvandyke.org/emacs/". That was my introduction to Lisp hacking, and eventually I gravitated to Scheme.

For those fundamentally interested in developing development environments, coding tools, or making your editor your hobby, diving deep into emacs customization is a reasonable thing to do. In other words, if creating things like evil-mode or spacemacs excites you, a dive deep into emacs is a good option.

For those who aren't interested in those things, try to actively avoid deep diving into emacs. It will be an unfulfilling waste of time. There's no magical developer productivity pot of gold at the end of that rainbow.

I occasionally try cool-and-new Emacs things that are mentioned on HN or elsewhere, but drop most of them. The reality is that a lot of these things are completely crazy and don't help; they are complicated, but don't reduce the overall complexity of the system. If you are new to Emacs, every one of these things is a potential stumbling block that leads to dropping Emacs. (The reason to use Emacs over the cleaner and newer editors is the raw text editing efficiency. The new editors are behind here, and munging text should be the editor's primary concern.)

But, I have also written many of my own extensions that have served me well for decades. I wrote "eproject" back when Emacs didn't have built-in project support. I have kind of ignored it as an open-source project (there are probably 8 million Github issues open that don't interest me), but I use it every day because it works perfectly... for me, the author. I have also written a couple of other neat extensions that have served me well; many years ago I was a fan of "takahashi method" presentations, and wrote an editor/viewer for these. It is unlikely that anyone else would ever use it, but it worked for me at the time. Having that flexibility in your toolkit is great... but it is not necessary for day-to-day editing. (I learned Elisp when I was converting a client's set of static HTML files [actually JSP] to a CMS. I needed to extract certain metadata from the filename and HTML tags into flat files, and then replace the static content with markers that would load that content from the CMS. Almost all of the pages followed a certain format, but there was enough variance that a good chunk of them required manual intervention. So I wrote a Lisp program that highlighted the relevant areas and let you edit them, then did the actual extraction and replacement. It took a couple days to write, but I did the actual extraction in half a day with no errors, so I think it was worth it. If you were using something less flexible, you wouldn't have written that, and would have had to clean up a bunch of mistakes from your non-interactive batch job, or just spend three days manually cutting and pasting thousands of chunks of HTML.)

As for extensions that have "stuck" for me; lsp-mode is the big one. A lot of languages have good language servers, and jumping to documentation and autocompleting symbols is pretty enjoyable. Depends on the language you use; I'm happy with gopls and the Typescript language server. I've never gotten clangd to work on an existing project, however. Minimalism is the name of the game; I use lsp, but nothing fancy. It underlines errors in the code, provides completion (with company-mode), and I setup keybinds to jump to definitions and documentation. I basically ignore lsp-ui-mode completely, because it's too much clutter.

Pre-LSP(+) code formatting hooks have also stuck. I cannot live without gofmt-on-save and don't use a programming language without an autoformatter (prettier is great for Javascript and friends, YAML, and JSON). Clang-format serves me well for C/C++/Protocol Buffers (but most open source projects don't follow their own style rules, so you have to turn it off if you're just making a small edit to their project). Emacs has good modes for all three of these things, go-mode and goimports, prettier-mode, and clang-format-mode. Could not live without them; formatting code is a silly thing to spend any mental energy on, and computers do a much better job than I could.

(+) I say pre-LSP here because the Language Server Protocol does do reformatting. I have not played with it. I'm happy with the static tools that existed before LSP, and haven't found a reason to try something new. YMMV.

Oh, how I wish it would be completely re-written with other dialects... Although there are many attempts, they are far from polished compared to Emacs itself.

I have yet to grok this mindset.. which is a shame.

Credentials established, I cannot recommend this tutorial enough:

https://david.rothlis.net/emacs/tutorial.html

He walks you through most of the core of what makes Emacs great by showing you how to make a change to a project in the idiomatic Emacs way.

I would have learned it years faster had I started there.

Beyond that, learn basic Emacs keybindings via the tutorial, as others have suggested.

I started in Emacs but installed evil-mode a few years ago and have never looked back.

I do not recommend Spacemacs. Install the tools you want as you find you want them, so that you know what's doing what, and so you have a decent chance of knowing what broke things when something stops working.

Keep your packages in version control as part of your .emacs.d repository. That keeps updates and deleted packages from screwing you.

Use "use-package" (https://github.com/jwiegley/use-package) for configuring what you install. It's written by one of the Emacs maintainers and will help you do things right by default.

I'm not the best Emacser out there, but if you're curious, my config is on my GitHub account: https://github.com/NateEag/.emacs.d

Happy hacking.

I'm committed to modal editing and vim keybindings already, so spacemacs introduced me to emacs and got me to convert, but it is a 90% for everyone solution. It adds tons of stuff that mostly works, stuff which you specifically mostly don't need.

It mostly works, but coming from vim spacemacs is a big black box for the most part. I think it is a fantastic first step if you need to get something mostly working.

Going through and building up my own .emacs with the parts I wanted was the way I finally learned to grok emacs for real. It took that step to actually be able to understand what's happening when something unexpected happens. I also discovered a lot of alternatives to the spacemacs packages, well known by real emacs users, that I much prefer to the choices made by the spacemacs team.

Once you have a decent idea how the parts fit together, you don't really need Spacemacs, IMO.

I think the last time I tinkered with it at all was about a year and a half ago?

I am currently a spacemacs user (holy mode, ya dirty heathens) and I like a lot of the built in functionality. However, I think that I will eventually build up my own config from vanilla.

- episode 0: introduction => https://mickael.kerjean.me/2017/03/18/emacs-tutorial-series-...

- episode 1: the basics => https://mickael.kerjean.me/2017/03/19/emacs-tutorial-series-...

- episode 2: org-mode => https://mickael.kerjean.me/2017/03/20/emacs-tutorial-series-...

- episode 3: interesting built in features => https://mickael.kerjean.me/2017/03/21/emacs-tutorial-series-...

- episode 4: installing plugins => https://mickael.kerjean.me/2017/03/22/emacs-tutorial-series-...

- episode 5: extending emacs with elisp => https://mickael.kerjean.me/2017/03/23/emacs-tutorial-series-...

If you want something close to what most users probably have setup and yet still close to vanilla you can give Emacs Prelude a try: https://prelude.emacsredux.com/en/latest/

I started with it, tried out the package selection, but then started a smaller config from scratch with what I liked from it.

Also good links: https://www.masteringemacs.org/reading-guide http://emacsrocks.com

I don't believe one should restrict oneself to a single editor, but rather follow a path of least resistance - Emacs is actually the path of least resistance when you want to have a custom editing experience.

Overall I use four editors Emacs, vi, notepad++ and VS Code. Emacs when doing Clojure or any other code so I can have something that is very convenient for me, vi and notepad++ on machines where I don't want to setup a config or where I do only simple text editing and VS Code where I would ocasionally need to install a plug-in, but I don't need to use it often.

So after about a year I started over, resetting my config and using Emacs customization over custom elisp writing to get a working init file. It helped me learn a lot. This is the path I recommend: do small customizations using Emacs' built-in features, then learn elisp later.

I learned a lot from this CS prof's videos, and it's a good, practical learning path I'd recommend: https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpF...

If you're into writing, I maintain a list of resources for writing with Emacs: https://github.com/thinkhuman/writingwithemacs

Unless your passion is in going meta and focus on building the tools instead of using them, chances are that your current tools can do what you need just fine.

I used TECO to get grades back in the day, on a DEC-10. People used to write BASIC interpreters in TECO for fun. Then I went into the wilderness, where every system I used was uncustomizable. And then DOS, where Turbo C and Brief were kings. Eventually the system I used was Windows, and MS Developer Studio (before Visual Studio) had some macro recording capability. Then I joined a company where everything was just more convenient if you put Linux on your desktop, and for my limited Windows work, one of the Windows ports of Emacs was adequate, and a couple of our brightest were always using Emacs. These were the guys I wanted to emulate so I started using Emacs. But then I branched off and started using Eclipse, because I couldn't get ctags to work well enough with all the C++ code I was working with. Eclipse's remote solution seems to be dead so now I'm using Code.

I don't miss TECO.

But, even if that were the case, the recommendation would be to either (a) find a lighter alternative to the used IDE or (b) switch to an IDE that is plugin-based to remove all of the "bloatware". At no point I would be telling people that the first alternative for them to "be fast" is to join the church of Emacs.

Fuck, I worked with junior developers who were more comfortable after I showed them they could work with gedit + terminal instead of cargo-culting whatever tool some nerdy senior used.

All I am asking is to not be like those photographers that spend more time on forums discussing about equipment than actually taking pictures, or audiophiles that focus so much on testing their equipment that they forget to enjoy the music. Unless you are a camera maker/speaker designer/software tool developer, focusing on the tools instead of the product is quite a stupid way to live.

I do have some functions for connecting to databases, but for the most part, there are no deep customizations.

I also have avy (think that's jump mode in vim), ldo for file browsing, yasnippet (for snippets), multiple-cursors, and some language-specific major and minor modes.

I mainly want to press C-c C-c and get my work done.

------

As a general rule, emacs is pretty easy:

* C = basic

* M = more powerful

* CM = most powerful.

So...

* C-f = move forward one character

* M-f = move forward one word

* CM-f = move forward one bracket

A lot of things are sort of mnemonic:

* f - forward

* b - back

* r - rectangle

* s - search

* r - reverse search

The biggest thing to remember is that "yank" has the opposite meaning in Emacs. In emacs, you can either "kill" (cut), or "copy", then you "yank" to (paste). This is a function of how the Emacs "kill ring" works. This extends to the above:

* C-y - yank the last item

* M-y - scroll back through the backlog of the kill ring.

Everything sort of falls out from this logic. If had to be completely honest with you, I probably use 20% of the total functionality of Emacs. It's a huge system, but I get my work done efficiently and don't sweat that I can't write a bunch of elisp from memory.

Also emacs is largely self-documenting. Learn the keys for querying documentation first thing. You can search for current keybindings, what a given function _does_, etc all live while you're using it.

On the evil front there is also Doom Emacs (https://github.com/hlissner/doom-emacs) which is better optimized and is still pretty full-featured.

1. Go through the Emacs Tutorial. Just start emacs, put the cursor on the text 'Emacs Tutorial' and hit enter. It will only take 30 mins max.

2. Go through the first chapter in the Practical Common Lisp book here: http://gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-th...

3. By now you are comfortable navigating around and editing text, opening files, running emacs commands with M-x etc... so you can now install packages for syntax highlighting for your language etc... via M-x package-install <enter> -> search for your language (usually LANGUAGE-mode), and install it.

4. Use emacs to edit all your files for at least 1 day.

5. Use emacs keybindings to navigate around in other apps if you're on Mac or Linux, those are standard keybindings that work everywhere in Terminal, bash, Textedit, Chrome, etc...

6. Learn how to use vim, download a vim cheatsheet and have it handy for reference, edit some files in vim (git commit messages will also do).

7. Install evil-mode and edit your .emacs.d/init.el file to bind a key to toggle evil-mode on/off

8. In maybe one day max, you're very comfortable in emacs now, and may be well on your way to writing your own extension functions. You're pretty much an emacs expert by now, in only 2 days max!

9. Try out different emacs configs. You can try mine out here: https://github.com/sufyanadam/.emacs.d it's setup for all major languages, Ruby, Python, React, JSX, etc... It also has some soundboard keys bound, try C-c-n-m when you want to greet someone new but don't want to be interrupted (you have to have mplayer installed on your system for it to work).

edit: If you use MacOS, Yamamoto Mitsuharu‘s emacs-mac [3] is my recommendation, as for linux the version from your distros package manager should be apt. ;)

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

[1] https://github.com/syl20bnr/spacemacs

[2] https://github.com/emacs-evil/evil

[3] https://bitbucket.org/mituharu/emacs-mac

That might be problem as teams standardize on newer editors with good collaboration features, which don't exist or aren't as new-user friendly as in Emacs. Some languages also don't have as good integration with Emacs as they do with some IDEs.

That said, if you really want to learn Emacs, then

     - go through the tutorial
     - print out a good Emacs cheatsheet
     - Have piece of paper or notebook to make your own supplement/complement to the cheatsheet
     - use a Rosetta stone site if coming from Vim
     - Force yourself to use the keybindings to move, not the arrow keys or the mouse. It will take a few weeks to get comfortable with the basic movement.
     - Probably most important after the tutorial: learn all the help functions and their keybindings 
        - C-h ?
        - info
        - apropos
        - where-is
        - describe-key, describe-function, describe-mode, describe-variable, describe-bindings
        - find-library
     - understand how undo works
     - package-list-packages to install packages
     - Start a basic init.el:
       - (fset 'yes-or-no-p 'y-or-n-p)
       - (global-font-lock-mode t)
       - (transient-mark-mode -1)
     - Learn keyboard macros <--- Enormously useful
     - After you are more comfortable, install and configure helm
     - Read or browse the Emacs manual and the Elisp manual (in info)
     - Read the "Mastering Emacs" posts for more advanced features
     - Also Mike Zamansky's Youtube channel

https://sites.google.com/site/steveyegge2/effective-emacs

http://steve-yegge.blogspot.com/2006/06/shiny-and-new-emacs-...

http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html

Even after close to a decade of Emacs usage, I learned more about Emacs using Spacemacs for a month than I thought possible.

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

I'd say it depends on what your aim is: (1) would be the way to go if you primarily want to get fluent with emacs, or are content to use tools you already know for other work, and learn plain emacs gradually in the background. (2) would be best if you want to get productive quickly using emacs for real work, at the risk of a more occluded understanding of emacs per se.

I'd put in a word for Prelude (https://github.com/bbatsov/prelude) as a possible compromise, making emacs immediately usable but without putting many layers between you and it. Some might consider it a little old-fashioned however (no use-package etc).

I've used vanilla emacs on and off for many years for quick edits, but only recently for actual programming (using Prelude, and prompted by learning Clojure). It's taking over my computing lifestyle. I've laughed in the past at people using it for email, but found myself using mu4e lately. Scary.

They are at: https://www.youtube.com/channel/UC0uTPqBCFIpZxlz_Lv1tk_g/vid...

Most of the videos are focused on practical tasks you would want to do. It's one of the few really good Emacs focused channels IMO.

Start with plain Emacs. Print/write out the popular cheatsheets. Just make sure you know how to exit, access the documentation, and move around the windows/frames/buffers. Get Melpa & install some packages. Play with the config, adding keybindings, figure out hooks and so on. Copy some elisp functions from dotfiles on Github. Spam the documentation command on everything. Get frustrated with how much tinkering you need to do to get the crazy setups you've seen on blogposts. Stay motivated by consuming more content about custom setups. Discover the magic of magit and parinfer and dired. Look up some of the org-mode/PIM heroes on github, usernames: novoid, alphapapa, karlicoss

Install Doom. Tinker with it a bit. Take notes of your learning in an org file. Tinker some more. Go back to plain emacs for a bit. Then try spacemacs. Go straight back to Doom because it's faster and you now understand enough about emacs to be scared of spacemacs' layers.

Below are some links to help you along the way.

http://ergoemacs.org/emacs/blog.html

https://sachachua.com/blog/

https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf

https://orgmode.org/worg/orgcard.html

https://cestlaz.github.io/stories/emacs/

https://www.youtube.com/watch?v=0g9BcZvQbXU

https://zaiste.net/doomcasts/

https://github.com/jethrokuan/emacs-workshop/blob/master/mod...

is pretty good as an introductory resource.

Disclaimer: I picked up Emacs from Jethro Kuan

I will mention cmd-c / cmd-w is still an anomaly. I sometimes capitalize stuff or close windows.

then start with

Absolute Beginners Guide to Emacs http://www.jesshamrick.com/2012/09/10/absolute-beginners-gui...

follow up with Emacs' tutorial and online help

follow up with Mike Zamansky videos on YouTube https://cestlaz.github.io/stories/emacs/

finally check out the blog entries (and the book !) at https://www.masteringemacs.org/

Second, I want to recommend the Emacs Lisp tutorial, which I would argue is the best official tutorial for a programming language, full stop. This will teach you a tonne about Emacs which you won't pick up any other way, and you can fill in differences between Spacemacs and vi(m) by the usual expedient of trolling the internet for clues.

Find an expert Emacs user who's willing to help, and have them watch you in person, even for just a short time, as you use Emacs to do things. Lather, rinse, repeat. Make sure they show you how to use the built-in help and feature-exploration mechanisms (but they'll know to do that anyway, if they're an expert).

I suggest don't go full inside but start slowly incorporating emacs into your workflow.

If you write code then using emacs only for git via magit for the first couple of weeks should be a good start (while reading some emacs related book in parallel).

Then try to experiment with the org mode, this thing alone might get you on the hook to be productive with the tool.

If you like the experience then I suggest you to consider buying ergonomic keyboard like ergodox/maltron/kinesis advantage to improve your typing.

https://packagecontrol.io/packages/orgmode

https://marketplace.visualstudio.com/items?itemName=tootone....

https://github.com/jceb/vim-orgmode

Members of said lovely community thoroughly recommended Mastering Emacs to newcomers as a number one introductory text which I since do as well—mostly because they did. I also recommend built-in tutorial.

As for packages,

• helm or some other fuzzy completion thing; make sure your M-x, C-h f, C-h v do offer fuzzy completion, it improves discoverability greatly. Recent (27?) Emacsen may have something like this out of the box.

• avy: jump to positions on screen

• there are several packages that offer insert/command mode including the famous evil-mode but it's a good idea to get used to defaults. “Mastering Emacs” has something on this. I've heard macOS supports default Emacs keys everywhere (not true for other systems)

• which-key can display keys and commands available at the moment, quite helpful from the start. You can actually find some of this information with context menu but it is less convenient. The issue with which-key is, you need to configure it to actually see its stuff. A config for it may be found in the link below

• https://github.com/a13/emacs.d/blob/master/README.org is a cleanly written init file; if you want a starter config for package x, try searching there for (use-package x ..) expression, copy it to your init file, press C-M-x and it's applied (note: it will often download the package, too). Many popular packages and built-in features are covered. Tweak some parameters, C-M-x, observe the changes immediately.

• last but not least, to make use of many existing configurations out there, you will need use-package. So install it early and learn to load it on startup (see the very config above as a reference)

Emacs led me to elisp which led me to Common Lisp which led me to scheme which led me to racket, each of which has its own unique set of literature.

I’m enjoying the journey. It’s a refreshing change of pace from the ever-changing, cutting-edge, hyped-up programming world many of us live and work in.

Emacs has also led me to further interest in macros, compilers, and programming languages.

If you don’t have prior experience with lisps I’d recommend Gentle Introduction to Common Lisp, How to Design Programs, or Practical Common Lisp. The fundamentals from each apply well to elisp.

If you want immediate(ish) productivity, id recommend emacs prelude, doom, or spacemacs.

It can be treated as an editor, and as your workflow slowly adjusts you will find yourself writing a mental wishlist.

Realising that wishlist is where Emacs shines among other editors/IDEs/applications.

It is a headspace/workspace and imo the programming equivalent of BASB.

I for example use it because I want nothing to pull me from my workflow, so I have shells, repls, notebooks, filesystem browser, internet browser, rss, and a slew of other utilities tiled, something akin to a Bloomberg terminal, even spotify if I need music. It has enabled my productivity in a way no other application could.

Could you describe each of the specific packages you use to accomplish all this? I'd love to add more tools.

Repl (these will depend on what language you're using): usually I just run this within a shell, dedicated to the task (Mx rename-buffer) but there are specific shells for this like Python-shell.

Notebook: EIN, can be a pain to set up, requires you to run a notebook server, best done headlessly of course.

Filesystem browser: Neotree is the best I've found but there are other decent ones.

Internet browser: EWW is fine, some sites will better in mobile format, some in simple format if available.

RSS: Elfeed

Spotify: Helm

Have flirted with BitlBee for Discord and WhatsApp but think it is deprecated for the latter.

Most of the above are available with the default install. Additionally there are modes and such that make life easier like SLIME, MultipleCursors, WindowPurpose etc. Some settings will need to be fiddled with to get Elfeed updating when you want it to, I mean it's never as simple as installing a package as I'm sure you know, but once up and running it's fantastic.

All readline apps support[1] them, including bash[2] and many others emulate them.

On MacOS, support for emacs keybindings is standard in Cocoa text views[3] and you can improve it quite easily[4].

[1]: https://tiswww.case.edu/php/chet/readline/readline.html#SEC1

[2]: https://www.gnu.org/software/bash/manual/html_node/Readline-...

[3]: https://developer.apple.com/library/archive/documentation/Co...

[4]: https://github.com/fkchang/emacs-keybindings-in-osx

I started out by following basic tutorials, like this one [0], and working my way up. You may want to find a guide to get themes setup, and some rough edges ironed out.

Alternatively, you could dive into distributions. I highly recommend Spacemacs, and have written an article about it [1]. It is a lot of learning especially if you're familiar with vim. The github page is also a great introduction [2]. I would recommend using the develop branch over master, as master tends to be very stale.

I have also heard good things about Doom emacs, another vim style distro.

[0] http://www.jesshamrick.com/2012/09/10/absolute-beginners-gui...

[1] https://dpbriggs.ca/blog/spacemacs-for-fun-and-profit

[2] https://github.com/syl20bnr/spacemacs#introduction

Otherwise you can read it here on Github: https://github.com/dpbriggs/dpbriggs-blog/blob/master/blog/2...

- Do the built-in tutorial before anything else.

- Read through most of the manual. It's extraordinarily good despite containing a few small and usually obvious errors. You can skip things, e.g. calendaring if you're happy with your current calendar system.

- Get a friend's nontrivial init file (.emacs, init.el, etc.) or find a representative one online. Ideally use one from someone who uses Emacs for the same stuff you will, so more of it will be relevant to you. Read and understand every part of this file, copying and adapting into your own .emacs as you feel moved.

- Use the built-in help system aggressively. Don't be afraid to go on detours when an intriguing function or variable meets your eye.

- Spend some time browsing the descriptions of packages in the `list-packages' buffer to find interesting packages, and read their source code.

- Read the Intro to Elisp (note: I think I used a 3rd party alternative tutorial somewhere, not sure which one) and use the Elisp manual more as a reference. Take as much time as necessary to digest anything that seems confusing. A few things aren't super intuitive on first read, for example the precedence relationship among various keymaps. Make diagrams!

- Contribute some bugfixes and new features to packages you are using. Start small.

- Use the Emacs Wiki as a secondary resource.

I joined a company where most of the devs used emacs, so I kind of needed to adopt it too. I started with very little config and it was very hard. Because many operations were different to the GUI editors I'd used before, I had to waste 20% of my brain power to consciously do things that should be unconscious (save, cut, paste etc). This made it much harder to program!

The first step was updating the config to make emacs more similar to my old editor. For example: make it so pasting text when text is selected replaces the selection. Turn off branching undo. Install a plugin that gave me an autocomplete list of every file in my current project. Make it so that if I copy text in emacs, it appears on the OS-wide clipboard. I'm sure your list of things will be different.

Another important step was getting my emacs theme to look nice. This really made me love the program a lot more. It's silly, but there we are.

The third important step was finding things that emacs does better than other editors. For me, a big one was having a terminal inside my editor (lots of editors do this now, but back then it was rare).

Hope you end up loving emacs!

2- Any key combination you touch translates to those commands, so `C-h k` which shows you the actual command is key. Learn the commands behind the keys and mix and match to suit your style. Read http://steve-yegge.blogspot.com/2007/02/my-save-excursion.ht... to get the overall idea. Use smex or helm's helm-M-x to be able to call the commands without remembering their names fully. You can also use apropos to search for commands, but smex or helm is much easier. This way, you don't need to learn that many shortcut keys.

3- Define a shortcut key to open your .emacs file so you can define new commands without extra effort. Keep it to a single file in .emacs.d dir to make things easier. Too many files make things harder to maintain for me.

4- Practice on your elisp skills on `ielm`.

Helm is pretty amazing and almost worth the cost of Emacs by itself: https://emacs-helm.github.io/helm/

I've been using emacs for about a year now. My config is stable at 1506 emacs packages. It runs on 6 different emacs distributions. Some would say my setup is bloated. With a 2 minute startup time, I need emacsclient. It's important to remove any impediments to learning as possible. Any weird keyboard problems, or waiting times you should try to eliminate. It takes an obsessive kind of discipline, like using batons on homeless people to combat the spread of coronavirus.

Every day I check the emacs reddit and search melpa for packages with particular keywords in their names. Every time I hit a bug I try to solve it.

Run multiple emacs instances so if you break something, at least one emacs still works. I recommend using 'lispy' for emacs lisp, but until you have learned that I recommend using vim for writing elisp. You kinda have to make key bindings to learn new emacs packages.

Please name some features that I'm missing.

People talk about adding their own tweaks. Any programmable editor lets you add your own tweaks. I've added my own to several. Including emacs. Emacs wasn't special here

I'm happy to use emacs when I have to (it's the only thing installed). But otherwise not feeling it.

I have not seen something similar to undo-tree in other editors: https://www.emacswiki.org/emacs/UndoTree

I sometimes keep different frames for different machines through ssh (TRAMP), and rename the frames. I'm not sure how good is multi-window support in other editors or remote editing of files for that matter.

emacs works on every platform I've ever used, and tramp lets you access everything/anytihing else. I have one set of startup files that has grown over the years.

Anything that can't work, doesn't work, works poorly can be tweaked adjusted rewritten or replaced.

I used emacs for a couple years on a linux laptop with a full keyboard, and I loved it. Then I got into more teaching than programming, so I moved to some beginner-friendly editors; I wanted to use the same tools I was recommending for my students.

Now I'm doing more dev work again, and I really miss emacs. But I'm a little lost about how to map keys so I can jump between my laptop in standalone mode, my laptop when I have an external keyboard connected, and non-mac linux machines.

On an external keyboard, I don't remap because I have a Control key in both corners of the keyboard that I can press with the corner of my palm/the base of my pinky finger.

BTW, did you know many Emacs keys work in standard macOS text views? For an intro and a bunch of details, see <http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html> and <http://www.hcs.harvard.edu/~jrus/site/system-bindings.html>.

https://sites.google.com/site/steveyegge2/effective-emacs

Note some of the advice, such as how to swap Ctrl and Caps-Lock on specific OSes, maybe be outdated now.

That and the built in tutorial - there should be a link on the screen when you start up emacs, or `C-h t` - should be enough to get you started.

Pretty good resources right at the top.

https://www.apress.com/gp/book/9781484217023

I didn't find anything similar when I got started using it, so it might be useful to you.

S. Chua's blog is the best "zine" I think: https://sachachua.com/blog/

To avoid "but vi/vim and the shell…" which is a sort of "mental flu" every Emacser has to go through at least once in his life, understand this:

"the UI paradigm of Emacs" is also called a roguelike interface by ESR, vi's too: "In Chapter 11 we described the effect of the absence of standard arrow keys on early roguelike programs; vi was one of these. " http://www.catb.org/esr/writings/taoup/html/ch13s03.html

Curiously last weekend I have found a video about org-roam and the presenter mentioned he was using Doom emacs. I was curious enough to try it. It uses vim key bindings by default. To get started I highly recommend this series by Zaiste [0], he explains how to set up the environment and digs into org-mode which were my main concerns. I found the sections on projectile, magit, dired and avy very helpful. Now I am tempted to give it a try in one of my projects. The downfall so far is I didnt find an in depth explanation on how to grok it with python.

[0]https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXB...

magit is a fantastic git UI. helm is a great ui for searching lists of things(used very often)

I've been using Emacs for ~5 years now, and I switched from Sublime Text. I used Vim here and there but I wasn't a huge fan, and I always heard that Emacs is _the editor_ that can solve anything. Org mode is what got me really interested so I read through that book and switched to Emacs fully after a couple of weeks of light usage and reading.

Now I only use Emacs, and I've never been happier programming. It's truly a remarkable piece of software.

Edit: just want to say that you should use vanilla emacs and try not to install any plugins at first. Resist the temptation to go willy-nilly on some awesome-xyz list.

I personally would recommend doom-emacs (https://github.com/hlissner/doom-emacs) which has an easy to understand codebase.

Now as you use it, you'll inevitably run into bumps or things you want to change. This is where you start to learn. In doom you can just press `SPC h a` to search up anything you could want (`SPC h` will show you all possible help options). Discoverability in Emacs is amazing, and puts all other editors to shame.

If you like trying new programming languages then all you do is add it to the layers list, and it’ll install recommended packages for that language. It’s nice to have that ready for you to use so you don’t waste time researching which packages go with which language. Then you just hit “space-M” and you see everything you need to work with that language. Read the README.md for that layer or even dive into its code if you want to know how it works.

I don’t think I could have moved from Vim to emacs without spacemacs and will be forever grateful for that.

https://prelude.emacsredux.com/en/latest/

http://emacsrocks.com/

https://sachachua.com/blog/category/emacs-news/

https://ethanaa.com/blog/switching-to-doom-emacs/

I wouldn't worry too much about elisp until you're at least intermediate. I've used Emacs for 10+ years and I next to no custom config that I've found indispensable.

Also, not as a tutorial, but more as a reference, https://emacswiki.org/ is a great site for not just information on the editor itself, but all the various modules/hacks people have contributed.

Pick a real goal you want to accomplish that the thing you want to understand is a good fit for.

Maintain a curious mindset while trying to accomplish the goal.

To frame this in the context of emacs. Just start using it for programming. When you come across something you want it to do, google how do I make emacs <...>.

I know it sounds overly simplistic, but just trust me and try it.

I installed Emacs from brew and apt (on two machines) and just ran doom installation script which you can find in Doom's GitHub repo.

To find your way around you can just follow command descriptions when you press <SPC>.

It is mostly about learning Emacs without blindly copying configs from GitHub and getting distracted by all the shiny packages one can get.

The multiple cursors episode is really cool: http://emacsrocks.com/e13.html

https://emacs.sexy/

https://github.com/emacs-tw/awesome-emacs

My favorite thing about writing Emacs Lisp code is that it is easy (e.g., just an 'apt get' on Debian) to install the aforementioned manual locally -- and the other resources I mentioned a part of the basic Emacs install -- and once I have installed that manual, I don't need internet connectivity when I am writing Emacs Lisp code. (Not having internet connectivity means I waste less time browsing around aimlessly.)

[1]: https://www.gnu.org/software/emacs/manual/elisp.html

Feel free to add more.

(https://clojure.org/news/2020/02/20/state-of-clojure-2020)

* Motivation

This is inspired by an ongoing conversation about emacs with a friend and a debugging interview that I really enjoyed.

* Exchanging emacs tips with a friend

A friend of mine is pretty proficient in emacs: org-mode all the things, written >500 LoC of elisp, tried several distributions. We still regularly teach each other about existing emacs functionality and exchange messages along the lines of: - I just found that there is a function foo, which I have made a keybinding foo and can now search open a tab with a SO search with text from the clipboard - whaaat? That's super useful! - I know, right?

He works with a couple of greybeards, who also seem to be constantly finding emacs functionality that makes their lives easier, which suggests it would be beneficial for all of us to watch others in emacs.

* Interview

I was given a real git repo that I needed to load into my environment (spacemacs on Linux) to debug and fix failing tests. They sat me down during the onsite (the days when we would go to interview in person), told me to download the repo from the URL, told me how to run the tests (after activating the python venv) and watched me debug and fix failing tests - only 5 were failing from about 100. The interviewers were not proficient in emacs, but I felt that they could follow my thought process and workflow. I had only recently set up python dap-mode and felt clunky navigating in pdb through dap, so ended up print debugging.

It made me think how interesting it would be to watch other people with different backgrounds and experiences debug the same problem and how often I would learn new tricks or debugging techniques. Having a good understanding of the problem and the code allows you to focus on the activity of programming and watch out for new ways of tackling the same problem.

* What will we investigate

Furthermore, it might be interesting to see what debugging practices are statistically more succesful in tracking down the bug faster (and control them for overall years of programming experience and emacs proficiency).

If our sample is big enough we can answer questions like: Correlation between overall years of programming experience and debugging time? Who is faster at debugging: printf or gdb debugger people? Which keybindings and modes are most frequent across users? Is there a correlation between having custom elisp functions and debugging time?

* Format

I will prepare a representative repo in the most popular language (I am most comfortable in Python, happy to consider other languages, if people prefer), bury some bugs in it (that will be easy), administer the study and summarise the findings in a spreadsheet/write-up.

Following the debugging session outlined above. Every participant:

starts recording their screen

Starts a fresh emacs instance with their config and loads a emacs lisp script that we provide for printing keypresses and recording keypresses + function calls to a log file.

download the prepared repo

run tests

investigate failing tests

fix them

commit their changes

The participant ends the screen recording session before sending me

   - the video to me or youtube/dailymotion URL 
   - plaintext keylog history
   - <optional> link to their elisp config

I watch it, sumarise the findings and present a write-up.

Who is interested?

I'll have more comments later, but the first two, slightly related to each other, would be:

1. Are you sure using just one language for the code is a good idea? It's going to instantly turn off large segments of people who would otherwise like to contribute - no matter which language you choose. Further, "the most popular language" may not even be appropriate: there's probably less Java, C#, and C++ programmers who use Emacs compared to the general population. I think the first step here should be a poll to see which languages are actually popular among Emacsers. Once we have the list, we can prepare a couple of codebases using the top 5 entries (for example.) I think I can contribute here - I don't think there'll be a language I'm unfamiliar with on the list. I'm also reasonably confident that, in case the improbable happened, I'll be able to learn that language in a few days. (Assuming there are docs available and so on, the usual disclaimers :))

2. Another consideration: how much time would participants have to prepare? I believe this is crucial. In my case, I have a bunch of "first-class" lang configurations, for the ones I spent the most time with, and "the rest," with configs just barely above bare-bones. If you give me a month, I guarantee I'll have all the possible tools you could use with the lang prepared, and I'll have quite a few hours of practicing their usage. If I had to go for it right now, and the implementation language happened to be outside of ~10-15 languages I use regularly or used extensively in the past - I don't think I'd be up for it.

> Starts a fresh emacs instance

Why a fresh one? Do you want to measure startup time (and later, performance in general)? But then people on the latest and greatest would have an advantage over someone working on a netbook.

> a emacs lisp script

I wonder if this wouldn't be better handled by an external tool. I don't know which, but it might be worth considering.

> logging keypresses/function calls might feel intrusive

You don't need keypresses - commands and functions would be quite enough. To be honest, I'd prefer a short chat with a participant afterward, maybe coupled viewing the replay at 10x the speed. What is valuable, I think, is the thought process behind the chains of commands, and "decompiling" those out of the "assembler" (key presses) of people's minds might prove quite hard.

That's it for now, I'll be happy to talk more about the idea, though I think we should take the conversation off the HN. My email is in my profile :)

I remember checking the thread several hours after posting my comment and assumed that it was so offtopic people didn't engage, hence the delayed reply.

> Are you sure using just one language for the code is a good idea?

The more languages the better, I was only assuming that I would be preparing the codebase myself, hence wanted to maximise ROI by choosing a popular language that I can write.

Adding more languages would be great, however, we would need to keep the code + tests + failures as consistent as possible i.e. no language-specific test failures due to multi-threading unsafety of C++, which Python's GIL prevents. Also I am not sure how useful cross-language comparisons are.

> how much time would participants have to prepare?

Prepare what? Ideally nothing in their language + emacs setup. The whole point is to learn about people's natural emacs workflow and what tricks they use when in the state of flow. I think each participant should only do it once in their "first-class" language, otherwise participants won't enter flow. That way, we control for no previous familiarity with the problem and get the best emacs knowledge and maybe even some elisp snippets others can follow.

To borrow a sports metaphor - I am sure that Tiger Woods can play a decent game of tennis, I would rather get tips from him to improve my golf swing.

> Starts a fresh emacs instance

That was a suggestion born from my workflow that minimises the risk of other buffers getting in the way of the test and preventing users' from leaking personal data during the screen recording.

> commands and functions would be quite enough

Yes and no. Some of Mike Zamansky's youtube videos have an on-screen feed of keypresses, which is interesting to watch for evil-vimlike navigation practices. I cannot promise I will be good at analysing a stream of keypresses and extracting meaningful analyses though, so commands and functions is what I can promise to analyse.

> I'd prefer a short chat with a participant afterward, maybe coupled viewing the replay at 10x the speed.

A chat is a great idea, however, if we manage to get a decent number of participants (ideally 40+ for each language for meaningful stats), my availability for a sync chat will become the bottleneck of the experiment.

I am thinking about replacing it with an async Q&A that the participant can add after completiion.

  M-x tetris

First, I firmly believe that kabdib comment - that you shouldn't customize Emacs, or fiddle with it too much - is not good advice for the year 2020. Forty years ago (i.e., when kabdib started using it), I would have agreed with it (I'd have to be born first, though). In essence, the vanilla Emacs is a powerful text editor with macros, syntax highlighting for many languages, debugger and linter integration, split panes, great diff viewer, and so on. In short: vanilla Emacs is still loaded with features, especially if you compare it to EDIT under MS-DOS or MS Write from Win 3.1.

The problem here is twofold: due to strict GPL licensing requirements, the inclusion of new features in the Emacs core is not that fast, and (more importantly) the rest of the world hasn't been frozen for the last 30 years. What I mean is that today, the comparison is not Emacs vs. Notepad, but rather Emacs vs. (Sublime | VS Code | Atom | ...). The vanilla Emacs has literally no features you could see as an advantage over the other editors (and that's even before we start talking about modern IDEs).

Basically, the only thing Emacs has in its favor is this: it's a full-blown, incredibly efficient IDE for programming in Elisp, and it's been like this for the last 40 years. Thousands of programmers used that environment to build the tools for just about anything under the heavens, and most of their code is out there, on Emacs Wiki, in ELPA / MELPA repos, and all over GitHub.

To me, using Emacs without taking advantage of its ecosystem is simply a waste of time. So to summarize this point: you don't have to fiddle with your Emacs config too much, but one of the first commands you should learn is probably `M-x list-packages.`

---

Second, while I say you "don't have to," it's important to remember that you can fiddle with the config. The "incredibly efficient Elisp IDE" is always there for you, a single command away. You can use it to read the code and docs for any function or command you use (or want to). You can make a small change in command and have it immediately reloaded. You can put a breakpoint anywhere in any function and step through its execution while having call stack with all the (if not compiled away) variables and their values.

The browser-based editors could, in principle, offer a similar or better experience, but for some reason, they currently don't (yet). You don't necessarily have to use it right off the bat - or you can ignore it altogether - but when you need it, it's always there. Fixing a typo, disabling unused features, automating chains of commands, binding commands to whatever is convenient to you, and so on - Emacs allows you to do all of that more efficiently than any other editor I've seen (LightTable being dead and all).

Also, as for "endlessly tweaking" your config: in my experience, that's not what happens. It took me a year to learn Elisp, then I spent about two years trying out various packages, writing my own, adding some conveniences on top of what's provided, and so on. That was almost a decade ago, though, and since then, I touched my config with very minor edits every couple of months, and I tried out some new packages as they came, so maybe a few times a year? Something like that. This is because I made my Emacs fit my habits, and once I did, I have had no incentive to fiddle with it further. Why would I? It works exactly the way I want it to.

---

TLDR: first, learn how to install (and uninstall!) packages and how to customize them with the `customize-...` commands. Then, go through the "awesome emacs" on GitHub and play with any package that catches your attention. Ask for package recommendations on StackExchange or somewhere if you're not sure which to choose or if there's a package implementing what you want (there is). Then, if you wish, delve deeper: start debugging and editing the packages' code, learn Elisp in the process, write whatever helpers you need. And after that, yes, simply use the editor (your editor!) for the next couple of decades.