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.
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.
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
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.
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.
That's an exaggeration, it's definitely a lot less than twice the work. I'd say 1.2 times at most.
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...
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.
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.
> 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.
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.
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.
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)))
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.
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.
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.)
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).
"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.
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.
I have never understood the rampant practice of using ~/.emacs.d/ for one's personal Elisp files. Most of what is in this directory appears to be machine generated files from various packages. To me, it seems much cleaner to have a separate directory for my own files, instead of maintaining ~/.emacs.d in Git and having to constantly update my .gitignore as I install and use new packages.
EDIT:
Also, C-h v user-emacs-directory RET says programs in Emacs store information in this directory.
1. You shouldn't be updating your `.gitignore` continuously. You need to ignore everything and explicitly define exceptions e.g.
*
!.gitignore
!init.el
2. The reason I prefer ~/.emacs.d/ is that I have it in a git repo and on every system, I'll just clone the repo and soft link it in the home directory. This way, I have only one directory inside home about emacs within which my files are explicitly separated and tracked.
P.S. I've recently tried to move from Spacemacs to Emacs and by no means a pro, so the process I've described may not be optimal.
I solve this issue by using my own config directory; this way I soft-link two things from my dotfiles repo:
- .emacs - which defines my config dir and loads everything in there
- my own config dir (called .emacs.conf), in which I have lots of .el files with specific configurations
Emacs packages still write by default to .emacs.d, and this way I don't have to care about any of that when moving between machines, because my configuration and Emacs's ongoing state are separate.
To be honest, though, I'll probably be migrating into a single-file literate solution soon, which will render my own config directory unnecessary.
I do this as well! I have this repo [0] at ~/cfg, then I symlink what I need [1] as an init script. My end goal is to be able to run a single script and get everything [2] set up on a new machine (I change machines somewhat frequently and I got the manual process to under 45 minutes, so there's room for improvement). More on setting up Macs [3].
There is also GNU Stow [4] that does something similar, and probably better.
I used to do it that way. I've switched to `vcsh` to let me keep various files directly in my ~/ directory in various different git repos without needing a ~/.git/ marking the whole thing as a working directory.
1. I still need to grow my .gitignore file as I add more .el files of my own.
2. A similar scheme would be to maintain a directory called ~/elisp in git and make ~/.emacs a symlink to ~/elisp/emacs. And pretend that ~/.emacs.d/ does not exist.
Really? C-h v user-emacs-directory RET says programs in Emacs store information in this directory. To me, this says ~/.emacs.d/ is not intended for humans.
user-emacs-directory is a variable defined in ‘subr.el’.
Its value is "~/.emacs.d/"
This variable may be risky if used as a file-local variable.
Documentation:
Directory beneath which additional per-user Emacs-specific files are placed.
Various programs in Emacs store information in this directory.
Note that this should end with a directory separator.
See also ‘locate-user-emacs-file’.
It happened in 2002, and git was started in 2005. See commit a04d5983:
commit a04d59830e46664faa4d534366a6b07e3b7c12f2
Author: Richard M. Stallman <rms@gnu.org>
Date: Sat Oct 26 22:41:33 2002 +0000
(command-line): Look for .emacs under ~/.emacs.d after looking in ~.
Interestingly it was changed to look for ~/.emacs.d/init.el in 2005, six months after git got started.
See also chapter 51.4 of the Emacs manual (which is often preferred over the documentation of variables simply because it can be more explanatory):
51.4 The Emacs Initialization File
==================================
When Emacs is started, it normally tries to load a Lisp program from an
“initialization file”, or “init file” for short. This file, if it
exists, specifies how to initialize Emacs for you. Emacs looks for your
init file using the filenames ‘~/.emacs’, ‘~/.emacs.el’, or
‘~/.emacs.d/init.el’; you can choose to use any one of these three names
(*note Find Init::). Here, ‘~/’ stands for your home directory.
So yes, it's long been used for things like the list of recently opened files, and configuration changes you made with Custom, and the UIDVALIDITY of your IMAP folders and so on, but it's also been a place to put your init file for quite a long time as well. Once you get a longish init.el file, it's a pretty short step to making several .el files that you load from init.el, and from there you can get as fancy as you like.
Programs and humans can peacefully coexist. Emacs looks for your init.el in that directory so it is most definitely also meant for people to use. I put my own libraries in ~/.emacs.d/my-lisp (and I put this directory on the load path). I've had zero trouble with this setup.
I don't think there is a right and wrong way to customize emacs, whatever works is good. What I do is have a .emacs and my custom elisp files in a Dropbox folder. Then I have a simple ~/.emacs file that loads the Dropbox one. If I didn't use Dropbox for various other purposes I think I'd use git as well.
Hey, has any of you guys been using emacs for modern front-end development? I’ve been looking for video tutorials (or at least for demos) on this subject, but could not find anything useful and practical. How is emacs’ support of JSX? Of typescript and TSX? Of flow? Of CSS in JS? Of eslint? Does it keep up with the crazy speed frontend development is changing, or has it remained far behind (being used mostly for the basic tasks that are shown in the video on web-mode in the 'Using Emacs' series)? What's your experience?
The best setup I've found is to use js2-mode for .js and rjsx-mode for .jsx, which parse the buffer for syntax highlighting, local refactoring (with js2r) and basic linting. For typescript, use typescript-mode. Flow support is quite bad ATM
nvm.el replaces the shell scripts from nvm.
Add a jsconfig.json to your project root and enable tide-mode for completion. This has worked far better than tern-mode, which some people recommend.
For fuller linting than what js2/rjsx offer, use flycheck. Eslint support is built-in, so it should just work, I think.
Finally, for build management, I use prodigy to run webpack, babel, ts, etc. Feel free to ping me if you need more help
I'm not a professional front end developer but recently completed some projects in TypeScript. I found it very painless to get set up on Emacs with Tide [0] and it was a pleasure to use. I also use web-mode [1] for templates which adds some bonus features over the existing HMTL editing mode.
I have done some work in angular2 (and rails, fwiw) using emacs.
There are modes for javascript (yegge's js2-mode is one of the more feature rich modes I have seen for any language), angular, and typescript. I have not tried eslint but a quick search for emacs eslint turned up some packages.
What in particular would you be looking for in terms of front-end development?
One issue I run into is problems with poor (auto)indentation when I am editing a file which contains html formatted as a string. For example an html template in an angular module. Anybody have/fix this issue?
I've found web-mode to be superior for JSX and ES6 stuff, though I tried to use Yegge's for a while. Though I don't do much JS development anymore, this is my current config for web-mode, though I had Flycheck and Flow types working at one point, as well.
I'm using RJSX-mode + emmet mode for JSX. RJSX is a fork of js2-mode so it handles normal js just as well. It has built-in linting that works great but you may still want to set up eslint if there's a need for it. `web-mode` is the undisputed best mode for HTML and again you can pair it with emmet-mode to write even faster.
If you're looking for 'intelligent' auto-completion like IntelliJ Emacs is probably not for you, but I think most people choose Emacs for its keybindings and workflow anyway. The shortcomings are definitely worth it imo.
On this discussion. I was trying to work better with React code. I found out about global + gtags + pygments. I'll soon be able to jump to reference if I set things up properly. I'll probably post something about that soon. Anyone got jump to definition and jump to references set up with javascript (or JSX) code properly? In terms of autocompletion, I don't what would be the best way to go about it yet.
Honestly? WebStorm with Emacs key bindings and several plugins. I use Emacs for pretty much everything but web development is not where it truly outshines other tools :(
"Fundamental mode" handles all those things great, and anything you can think of. Escape the shackles of syntax highlighting and special modes and you'll be free, hackers, you'll be free...
Multi-occur has kept me with emacs. Exactly what's wanted when making coordinated edits to multiple file formats, e.g. a project that involves JS, Go, Markdown. After some setup hassle, 'M-x mo <regexp>' or similar searches all open buffers, and presents matches in a new temporary buffer. Typing 'e' in that buffer makes it writable. The usual editing commands then simultaneously modify both the temporary multi-occur buffer, and the originals.
>Inspired by Mattias Petter Johansson, or MPJ who make a weekly video, I decided to try to create a series of YouTube videos and matching blog posts.
I find this pretty funny since MPJ is editor-agnostic and thinks it's a huge waste of time to learn command shortcuts, config files, etc. He promotes using a clean Atom install with no plugins to his viewers.
I'm a Vim user that did try to get into Emacs with evil-mode. However, I got annoyed when dired wouldn't let me user the Vim movement keys and went back to Vim.
For me, it's been keyboards with ctl and alt on both sides. Thanks to Xah Lee [1]. This rules out Macbooks (and most laptops) and favors Thinkpads, though currently I have a Dell Precision laptop and it has ctl and alt on both sides but the ctl's are not symmetrically placed and it is a bit annoying and not as good as the Thinkpad it replaced but it is workable.
On my desktop, I have a Microsoft Natural Ergonomic 4000, which is an awesome keyboard and cheap and robust. The major compromise is that it is corded to USB, but for me it is worth it.
That said, it takes practice to develop muscle memory to use both ctl keys and both alts and key bindings that require switching ctl keys to touch type feel strange.
Good points. I also swap Ctrl and Alt on both sides, using my thumbs for Ctrl. Using the opposite hand to press the modifier is analogous to how a touch typist uses the shift keys. For desktop use, I now use a Kinesis keyboard, again with symmetrical modifiers but all as thumb keys.
lol how do enter spaces then? I use alt as my meta key, just like how it is on Linux iirc. It's hard to remember what the default behavior is when I conveniently clone my dotfiles wherever I go.
Caps lock as control still caused pinky strain for me. I use xah lee's Ctrl palming method and it is amazing. I recommend anyone try it for at least an hour to get used to it, you'll never switch back.
Unfortunately it only works with physical keyboards. Still use caps lock on my laptop.
I press left ctrl with my pinky curled, so I actually press with the upside of the finger (just above the nail). It puts my wrist at a very small angle and no effort on the pinky finger itself.
I used to think "emacs pinky" was a joke, until I got my first programming job and I suddenly used emacs eight hours a day. :-|
Then I read somewhere that the Ctrl key used to be at the location now occupied by Caps Lock on PC keyboards. So now, on every computer I use regularly, I remap Caps Lock to be an additional Ctrl key. My pinky has thanked me for it ever since. ;-)
Also, I cannot remember having used Caps Lock ever, except by accident.
Actually the machines Emacs was developed on had rubout where caps lock is today. Control and meta were next to the space bar (control on the inside) and they were also wide keys like shift is.
Sun put control where caps lock goes; i don't know if they originated that or if it copied someone else's existing practice.
I just press the control key with the part of the palm of my hand that's right below my pinky finger. That way my pinky finger always stays on the home row, and never gets tired.
I don't like to remap control, alt, escape, or caps-lock because I don't want to be hobbled when I use another computer that I don't control to type on. This method has worked well for me for decades.
I don't understand how remapping Caps Lock to Control is supposed to improve things, considering that there's already a Control key in the vicinity of Caps Lock. For me the bigger problem is the right control key.
I used to basically think it was insane that people would recommend changing the layout of my keyboard in order to accommodate the inefficient default key bindings of Emacs.
However, even though I long ago stopped using Emacs, to this day I still swap Caps Lock with Ctrl because it's a much more natural position for the control key once you get used to it.
The difference between "in the vicinity of" and "on the same row as the home keys" proved immense for me. YMMV I guess, depending on your typing habits.
Use a keyboard with thumb key clusters for Ctrl, Alt, and other modifiers. If you cannot use such a keyboard (e.g. on a laptop) I suggest remapping CapsLock to Ctrl or using `god-mode`.
