'Using Emacs' Series(cestlaz.github.io)
cestlaz.github.io
'Using Emacs' Series
https://cestlaz.github.io/stories/emacs/
105 comments
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 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.
You need to check out Spacemacs[1]. It's set up so that as soon as it's installed you can use it efficiently using your vim keys.
It's got a ton of great defaults and I'm considering changing over full-time. I've been using it quite a bit lately and love it so far.
[1]https://spacemacs.org
It's got a ton of great defaults and I'm considering changing over full-time. I've been using it quite a bit lately and love it so far.
[1]https://spacemacs.org
Have you tried neotree? It's a port of vim's nerdtree.
What is the best way to reduce pain from using ctrl with pinky finger? (emacs pinky?)
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.
[1]: http://ergoemacs.org/emacs/emacs_pinky.html
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.
[1]: http://ergoemacs.org/emacs/emacs_pinky.html
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.
Build a keyboard that puts Ctrl and Alt under your thumbs, or have one built for you.
Or, more easily, you could just buy one: https://www.kinesis-ergo.com/shop/advantage2/. I've used a Kinesis Advantage at home and at work for 10 years now.
In my experience - buy a good mechanical keyboard, and remap Control and Caps Lock.
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.
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.
Try it and you'll see. Control is usually two keys lower than Caps Lock, forcing you to bend your pinky in a weird way.
As for Right Control - I don't think I ever pressed that key in my life...
As for Right Control - I don't think I ever pressed that key in my life...
At least on MacBook Pros, there is not a control key anywhere in the same pinky area as the caps lock key. A solid inch or two is quite a big deal.
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.
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.
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.
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.
Sun put control where caps lock goes; i don't know if they originated that or if it copied someone else's existing practice.
Huh. Thanks for the info.
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.
Unfortunately it only works with physical keyboards. Still use caps lock on my laptop.
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`.
evil-mode
For me, god-mode has been a life-changing discovery. It solves C- and M-. I use sticky keys for shift, but that's less of a home run
https://github.com/chrisdone/god-mode
https://github.com/chrisdone/god-mode
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.
What really worked for me was switching to Sublime, and nowadays Vscode. :(
Press control with the opposite hand (so C-A uses the right control), and swap caps lock and control.
I read from somewhere saying that Emacs was invented at a time where the control key reside at where the caps lock key resides now.
One day, my pinky genuinely hurt from stabbing the control key of my work-issued keyboard. I remapped the control key to caps and never looked back.
One day, my pinky genuinely hurt from stabbing the control key of my work-issued keyboard. I remapped the control key to caps and never looked back.
I swapped ctrl with caps lock and it had helped me immensely. Would highly recommend that.
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 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.
Alternate between the left and right Ctrl keys...
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.
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.
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.
*
!.gitignore
!init.el
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.
- .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.
0: https://github.com/andreis/cfg
1: https://github.com/andreis/cfg/blob/master/init.sh#L64-L69
2: brew and brew cask, dotfiles ofc, and a _lot_ of system settings on mac os can be changed via the CLI, see
3: https://github.com/iCHAIT/awesome-macOS#setup
4: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...
There is also GNU Stow [4] that does something similar, and probably better.
0: https://github.com/andreis/cfg
1: https://github.com/andreis/cfg/blob/master/init.sh#L64-L69
2: brew and brew cask, dotfiles ofc, and a _lot_ of system settings on mac os can be changed via the CLI, see
3: https://github.com/iCHAIT/awesome-macOS#setup
4: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...
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.
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.
1. Perhaps make a new directory `.emacs.d/elisp`, append it to your path and add your files in it and have .gitignore not ignore the directory?
2. You could!
2. You could!
Using ~/.emacs.d this way came about well before git was invented. :)
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:
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):
commit a04d59830e46664faa4d534366a6b07e3b7c12f2
Author: Richard M. Stallman <[email protected]>
Date: Sat Oct 26 22:41:33 2002 +0000
(command-line): Look for .emacs under ~/.emacs.d after looking in ~.
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.
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.
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
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...
Video 1 - Setting up the package manager
Video 2 - Intro to Org Mode
...
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.
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.
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 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
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.
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.
That's an exaggeration, it's definitely a lot less than twice the work. I'd say 1.2 times at most.
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.
Currently I only use it to edit org files, but it feels like there is a whole ecosystem waiting to be explored.
Magit, ESS, SLIME, Cider, Gnus/mu4e, dired...
There are some fundamentals that make it relatively easy to pick up anything:
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)
You should check out magit, as well.
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.
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.
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.
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.
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
Do you have a good set of basic customisations that anyone using Emacs should do?
You've probably heard about it, but Mastering Emacs is fantastic.
https://masteringemacs.org/reading-guide
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 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.
- 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)
- 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)
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:
Make CTRL L clear eshell
https://www.emacswiki.org/emacs/SmoothScrolling
[1] https://raw.githubusercontent.com/wcummings/dotemacs/master/...
(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)
(setq custom-theme-directory "~/.emacs.d/theme")
(setq custom-safe-themes t)
(when (display-graphic-p)
(load-theme 'my-solarized))
(require 'em-smart)
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)
(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)))
https://www.emacswiki.org/emacs/SmoothScrolling
[1] https://raw.githubusercontent.com/wcummings/dotemacs/master/...
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.
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.
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.
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.
If you want a suggestion for what to bind C-x C-a to, I use this function:
(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.)
(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))
(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 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
> Every new thing you learn incrementally speeds you up.
Like forgetting the original keybindings and switching to evil.
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).
"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.
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.
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.
[deleted]
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.
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?
(Disclosure: I'm the author of rjsx-mode)
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
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
Thank you! That was really helpful.
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.
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.
Sounds like you might be interested in my dumb-jump package: https://github.com/jacktasia/dumb-jump
I've had good luck with JSX in web-mode. It just kind of... works?
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 :(
I do all front end development in emacs, using Clojurescript. Lisp support is of course great in emacs.
I also use web-mode a lot for source files that are a mix of CSS, Js and HTML.
I also use web-mode a lot for source files that are a mix of CSS, Js and HTML.
"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...
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.
[0]: https://github.com/ananthakumaran/tide
[1]: https://github.com/fxbois/web-mode
[0]: https://github.com/ananthakumaran/tide
[1]: https://github.com/fxbois/web-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?
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.
https://gist.github.com/asummers/b8304b8ea78fc331b8177ff35d0...
https://gist.github.com/asummers/b8304b8ea78fc331b8177ff35d0...