Hacker News Reader

Comment by gumby | Hacker News Reader

I am a little concerned you start with package repository and then org mode. Emacs is at heart a simple, modeless editor. With c-[fbpns] and c-x c-[fa] you can immediately, if laboriously, do anything. Every new thing you learn incrementally speeds you up.

View on HN

I saw the headline and my first thought was "Emacs tutorials, cool! What's not to like?" and then I clicked the link and saw

  Video 1 - Setting up the package manager
  Video 2 - Intro to Org Mode
  ...

and thought "Why there are two things" and then came back to the comments and this thread was at the top and it sort of put the decision by the videos' authors in perspective.

At it's heart, Emacs is "The Extensible, Customizable, Self-Documenting, Display Editor." [1] I'd be much more comfortable saying Notepad is a simple, modeless editor. For a contemporary developer, package management is a reasonable reference point (even JavaScript has package management). And to me, org-mode is the killer app...Oh Babel. There is nothing else quite like You.

[1]: http://worrydream.com/refs/Stallman%20-%20EMACS,%20The%20Ext...

If you want to avoid all that, just use spacemacs. Don't like VI keys? No problem, it asks you if you want them when you first start it up.

Spacemacs is different, but for a new emacs user it's hard to argue with such a batteries-included approach.

I was not trying to avoid anything. I've been using Emacs for several years (and the same keybindings work in Bash and similar keybindings are available in many other editors/IDE's and in Firefox via plugins or settings).

For me, using Spacemacs would be limiting because not every mode has bindings and none of the official Emacs documents and most of the unofficial blogs and SO questions etc. don't describe keystrokes in terms of Spacemacs. In the end, using Spacemacs is using Emacs and will sooner or later require I know Emacs. Other people may have a different experience. Personally, I don't want to spend time cross-referencing the official documentation with this: https://github.com/Somelauw/evil-org-mode/blob/master/doc/ke... in the middle of trying to understand an org-mode feature.

I dunno. I think it's fine. For new users it has batteries included. For existing users, it's a lot of common-sense rules and a fairly simple mapping anyways.

I apologize for misinterpreting your comment, though.

As for notepad, I will give up org mode when you pry it from my cold dead hands. Can't imagine not using structured text and navigation for notes, outlines and task management.

I don't think Spacemacs isn't fine. That doesn't mean I would recommend it generically. My generic recommendation is vanilla Emacs because it is easier to find the right answer when there's a problem and more people capable of providing informed help.

Well there is the built in tutorial for that. And it'll leave you at a point where you can frustratingly do text editing and feel a bit confused about what all the hype is and then after a few weeks/months you'll drift back to a more traditional/"modern" text editor.

At least that was my experience... twice..

The only way to stick with emacs is to see how extensible and useful it is - which is really all about learning org and how to add packages.

Org is really the gateway drug b/c of how useful it is for everyone - even non developers. For developers the other "killer-app" is magit. For a long time I used emacs just for magit. Only a couple of windows git GUI editors come close in usefulness

I'm a long time vim user, but after a colleague showed me org-mode I installed emacs (with spacemacs).

Currently I only use it to edit org files, but it feels like there is a whole ecosystem waiting to be explored.

You should check out magit, as well.

And elisp.

and pacmacs [0]

[0] https://github.com/codingteam/pacmacs.el

Magit, ESS, SLIME, Cider, Gnus/mu4e, dired...

There are some fundamentals that make it relatively easy to pick up anything:

    * Help system (nearly everything is self-documenting)
    * Customization
    * ELisp basics (write some helper functions in your .emacs)
    * Debugging (Edebug, just do C-u C-M-x to instrument a fn and step through it next time it's called)

I've been a long-time Emacs user, and the "aha" moment happened when I realized that Emacs really boils down to three things: 1) a text editor 2) mechanisms to interact with your system (e.g. subprocesses) and 3) interactive and dynamically programmable runtime. Once you learn the fundamentals of those three things, the sky's the limit...

Another way to look at it is saving time and effort to do it right at the start. Learning how to use emacs without paredit and then learning again with paredit is twice the work of just learning once with paredit. Ditto projectile (with projectile-helm)

If you get used to smacking tab a zillion times while opening files to autocomplete, upgrading to helm find files after the tab habit is deeply ingrained will be painful (tab in helm find files is the help key, not the autocomplete key, helm is conceptually like "always on autocomplete" times a million sorta)

Also with the ecosystem of modes, meta-e usually does the right thing in all the modes unless you're editing something that doesn't have the right mode installed by default, then you get used to not using the keystroke M-e, possibly all the time in all files, which is really bad because M-e will work if you simply install that file's mode package. Obviously this extends way beyond one keystroke which multiplies the impact.

Its possible to use emacs at least two levels. Theres low level where the editor helps you navigate and format, if you permit it by adding file type packages. Then there's the high level where magit or org mode are nice CLI applications almost stand alone. So if you start out at a high level emacs with "my vim-alike can also run magit, so to me emacs is just a vi that can run magit" you're going to miss out on the substantial performance gains of low level emacs like navigation keystrokes.

Maybe a good programming analogy is its much simpler to start noob programming students on msbasic.exe, but everyone seems to think almost anything else as a first language is better in the long run, even if almost everything else is harder to use for the first fifteen minutes.

That's an exaggeration, it's definitely a lot less than twice the work. I'd say 1.2 times at most.

Agreed, although it's also true that vanilla Emacs is quite spartan and has many questionable defaults. In my opinion it would be much better if plain Emacs provided a nicer user experience out of the box, thus reducing the need for customisation and external packages which is a big barrier to entry for new users.

Do you have a good set of basic customisations that anyone using Emacs should do?

I'm not sure how you are with vim bindings but in my opinion evil mode helps a lot with productivity.

And spacemacs is a great starting point.

Or God mode.

You've probably heard about it, but Mastering Emacs is fantastic.

https://masteringemacs.org/reading-guide

https://github.com/technomancy/better-defaults aims to be "a small number of better defaults for Emacs".

I use it, though I'm not a heavy emacs user.

I think ido mode in the mini buffer is a requirement for smooth emacs use. And of course, installing any editing modes for particular program languages that you use.

Install ido-mode and projectile as a bare minimum. All these can be installed with M-x package-install, or you can do something like this https://github.com/wcummings/dotemacs/blob/master/modes/my-p... to automagically install your packages.

(setq ido-enable-flex-matching t) (setq ido-everywhere t) (setq ido-create-new-buffer 'always) (ido-mode 1)

(projectile-global-mode)

Maybe enable flycheck globally if you're used to syntax checking.

(global-flycheck-mode)

Also worth learning TRAMP if you're used to sshing into boxes and running vim. M-x info, C-s tramp.

Get rid of the waste of space toolbar:

  (tool-bar-mode -1)

And install a nice theme, whatever floats your boat, I use a solarized theme [1]. The default theme is gross.

  (setq custom-theme-directory "~/.emacs.d/theme")
  (setq custom-safe-themes t)
  (when (display-graphic-p)
    (load-theme 'my-solarized))

I use eshell, I think the plan9 smart shell features are nice:

  (require 'em-smart)

Basically includes additional editing features in eshell. It creates keybindings to edit previous commands and page through the output of commands.

Make CTRL L clear eshell

  (defun eshell/clear ()
    "Clear the eshell buffer"
    (interactive)
    (let ((inhibit-read-only t))
      (erase-buffer)
      (eshell-send-input)))

  (defun my-eshell-mode-hook ()
    (local-set-key (kbd "C-c e") 'end-of-buffer)
    (local-set-key (kbd "C-l") 'eshell/clear)
    (eshell-smart-initialize))

  (add-hook 'eshell-mode-hook 'my-eshell-mode-hook)

Line numbers, but only when you're editing code (GUI and text):

  (when (not (display-graphic-p))
    (setq linum-format "%4d | "))

  (defcustom linum-disabled-modes-list '(eshell-mode wl-summary-mode compilation-mode org-mode text-mode dired-mode doc-view-mode image-mode rcirc-mode)
    "* List of modes disabled when global linum mode is on"
    :type '(repeat (sexp :tag "Major mode"))
    :tag " Major modes where linum is disabled: "
    :group 'linum)

  ;; override linum-on because there is no good way to   disable global-linum-mode
  ;; on a per-mode basis
  (defun linum-on ()
    (unless (or (minibufferp)
                (member major-mode linum-disabled-modes-list)
                (string-match "*" (buffer-name))
                (> (buffer-size) 3000000))
 (linum-mode 1)))

"Smooth scrolling"

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

[1] https://raw.githubusercontent.com/wcummings/dotemacs/master/...

- grab a decent theme

- if you're on a mac set the command modifier to meta

- ido mode

- transform yes or no into y or n

- Disable the bell and the visual bell

- cua mode (this begins to be personal so I'll stop there)

http://spacemacs.org/ solves this exact problem. It's a set of packages, with consistent UX.

The problem I have with Spacemacs is that it's almost too fancy. Even as a moderately experienced Emacs user I found the defaults overwhelming. As an example, it displays lots of incomprehensible to the new user information on the bottom that changes with file type. Compare that with ye olde Emacs starter kit, which just fixed up some basic key bindings and gave it a more modern colour scheme.

Personally I find that a better starting point.

> Even as a moderately experienced Emacs user I found the defaults overwhelming.

I agree. There is a lot of "magic" going on, and it doesn't help that Spacemacs is a lot slower and less stable than my less-intensive personal customization.

Of course, that's the problem with any significant starter kit. As a new user, now you don't just have to learn emacs, you have to learn emacs + whatever heavy modifications they've done to emacs.

Spacemacs is a lot slower and less stable

In principle, I liked Spacemacs, but stability is a big problem. Often certain org functionality stops working, etc. I now have a reasonably stable snapshot and I just don't update ELPA/MELPA packages anymore, because the risk is simply too big that things break (yes, I know that you can rollback).

Another problem that I have been running into is that Mitsuharu Yamamoto's emacs-mac, which is IMO by far the nicest Mac version regularly seems to trigger a bug where WindowServer starts using 100% CPU. I haven't really nailed it down (I only notice it later when the fans start getting loud), except that it only occurs sometimes when I run emacs-mac.

Once you find what you like about spacemacs, it is usually better to start with a raw configuration and add those things that you found and remove everything else. You end up with a much faster and lighter editor.

FWIW my .emacs file is less than two dozen lines long and I spend most of my day in it. The only external package it loads is magit

I made these for people who finished the tutorial (in particular, I had my students in mind). It's very much the way I do things and the hope was it would smooth the way for people to get to customizing Emacs in their own way.

I originally wasn't sure if I was going to do the mini org-mode stuff early on but thought that it would be better for organizational reasons rather than pedagogical.

>Emacs is at heart a simple, modeless editor. With c-[fbpns] and c-x c-[fa] you can immediately, if laboriously, do anything. Every new thing you learn incrementally speeds you up.

That kind of introduction is already in the Emacs tutorial.

And it's the type that drives newcomers away.

I first used Emacs in the late 90's. Even then, the regular cursor keys worked. Now I do understand that some prefer the original keybindings, but the tutorial is likely not targeting that minority.

> c-x c-[fa]

You mean c-x c-[fs], right? I'm by no mean an emacs expert although I've been using it for 6 years now, and when I read your comment I thought "Wow, c-x c-a is a functionality? How comes I have never used that?", so I tried that in emacs but it's not mapped to anything.

Apart from that, I fully agree with your comment.

I had the same reaction when I read this. I was looking forward to getting to my computer later today so I can see what that key map does!

Yes, it's a typo (but I can't edit my post anymore). c-x c-f and c-x c-s

If you want a suggestion for what to bind C-x C-a to, I use this function:

    (defun align-all-matches (start end regexp)
      "Align all matches of the given regular expression."
      (interactive "r\nsAlign regexp: ")
      (align-regexp start end (concat "\\(\\s-*\\)" regexp) 1 1 t))

It inserts space in each line of the region so that all matches a given regexp are vertically aligned. I find this to be my most common use for the powerful but complicated align-regexp.

(If you call align-regexp interactively without a prefix argument it does something much like this function but only aligning the first ocurrence on each line, and if you call it with the prefix argument it prompts for all parameters of align-regexp.)

> Every new thing you learn incrementally speeds you up.

Like forgetting the original keybindings and switching to evil.

I don't think Emacs has been modeless in many, many years. I read that already in 1978 Emacs buffers could be used to edit files, of course, but also read email, run a shell, show a list of compilation errors linked to source locations, etc. Each of those is a completely different mode of operation with different keybindings (and different meaning for keybindings that happened to be shared).

That's true but the text editing part is modeless as opposed to how vi and it's kin do it. Of course even that can be changed and Spacemacs has recently made it a fairly popular choice.

"Modeless" is used as a term of art here: when entering text there is no difference between entering and editing (as opposed to, say, vi which separates editing and navigation from entry). Word and TextEdit are modeless editors.

What Emacs calls "modes" have indeed been around for a long time; I started using Emacs in 1978 as it happens and did use it to read my mail. However ITS didn't have the concept of "shell" (the command entry system was also the debugger!) nor of "inferior" processes so you would exit EMACS to compile or run other programs.

Are you saying the term modeless only applies to text editing? I thought it was a general UI term that can be applied to any program and means that keystrokes always mean the same thing independent of context. In that case, Emacs as a whole is not modeless, but usually each individual buffer is.

And sorry for getting the history wrong. I think I mixed the ITS and Multics versions up. Maybe the email reader was only in the ITS version and the Multics version had the ability to call the PL/I or Fortran compiler within Emacs and get a buffer with an error list. Does that sound right? And I'm not sure about command shells, that's probably just wrong and they came later.

Reply on news.ycombinator.com