I'm always a little jealous when I see what people do with emacs. But I've never liked using emacs, so I've resigned myself to a permanent, mild case of emacs envy.
I think you could get approximately his same functionality with a terminal (e.g urxvt) and tmux for the splitting. In fact I do essentially that at work on Windows, from a cygwin terminal and tmux. When it fits whatever workflow I'm doing from within cygwin, I'll launch the occasional Windows program from there; the rest of the corporate Outlook, IE etc is done normally from Windows.
At home on Linux I get my basic window splitting from my window manager, i3wm. If I need more terminal-ish splitting I'll run tmux in a urxvt.
The nice thing about Emacs is how much it's open to modification. There are compatibility modes to make it work like other editors (eg. "evil mode" to make it work more like Vi, "cua mode" to use "normal" key combos instead of having to learn Emacs's, etc.). There are often a bunch of alternative ways to do things, which have their own pros and cons, so if something seems frustrating, it pays to Google around a little to see if there's another way.
For example, running a terminal can be done with `term` (b/w) or `ansi-term` (colour), which provide a pretty standard xterm-like terminal emulator, completely under the control of whatever shell you use (eg. bash). This is useful for screen-manipulating programs like ncurses-based UIs, but is awkward to manipulate as text (a bit like the awkward copy/paste functionality in screen and tmux).
There's also `shell`, which runs a regular shell (like bash), but Emacs keeps control of the screen. This makes it useless for curses-based UIs, but great for text manipulation. For example, rather than running a pipeline over and over, tweaking the output options, we can often just dump everything to stdout then play around with it using the full power of Emacs (search/replace, regexes, keyboard macros, lisp functions, etc.).
There's also `eshell`, which is like shell mode but instead of a regular shell like bash, it uses a custom shell written in Emacs Lisp. Eshell's strength is its integration with Emacs; for example, Emacs Lisp functions can be run just like commands and Emacs buffers (including shells!) can be treated as files, etc. Eshell's weakness compared to shell is that it can't do pipes.
Personally, I use mixture of shell and eshell, plus some handy Lisp functions eg. for spawning new shells instead of always switching back to the same one. I avoid term and ansi-term in favour of a separate st terminal though, since they're pretty slow to update and their lack of decent text manipulation makes them feel uncomfortably "un-Emacsish".
is so useful for searching for text strings in outputs. (when grep alone will not do) like all things emacs/ terminal its a little awkward when trying to use the control keys (up arrow, ^r) and they get captured by emacs and not the shell.
Amen, and throw in hi-lock and you can create arbitrary keyword highlighting (like any time the word "error" appears it's colored red). Great for tailing log files.
I've only used eshell casually, but /dev/clip for redirecting output to the clipboard was really handy. It turns out there's a bunch of ways to do this, but eshell was my first exposure to clipboard as file.
It's also kinda nice setting up emacs in a cygwin that winds up being relatively consistent with mac.
For some reason I share the feeling about emacs. However I personally prefer dwm in X11 environments and have thus written a "clone" for terminal/ssh sessions called dvtm.
I like Debian and wonder if there's a best practise setup for desktop environment plus i3wm. Everyone seems to do something different and the setups I've seen have all had minor quirks (wifi tray icon, sound control, locking, etc).
Currently my main machine is Ubuntu 14.04 with Xcfe and i3wm and I have a few quirks (something about the keyboard charset picker never aligning with the Xcfe tray).
For what it's worth, I also use i3 under Arch. I don't think there is a canonical right distro or anything, but then again I've only ever used it under Arch so what do I know? Also like the sister comment, I also use dmenu & i3bar to handle the rest of my needs. I generally stay away from things like conky.
Good luck, although I generally found i3 a breeze to set up. Part of that is due to the fact it was already 95% of what I wanted in a WM. I didn't have to spend hours and hours customizing it like dwm or Awesome. Your mileage will, of course, vary.
I will say that the Arch wiki page on i3 is a treasure trove of info, most of which is distro-agnostic or at least easily translated into debian flavors.
> I will say that the Arch wiki page on i3 is a treasure trove of info
I think Arch docs are the best Linux docs I've seen. The FreeBSD manual is the only thing I've seen that's comparable. I've only ever ran Arch for a day or two a few times (no complaints), but Arch docs always deliver for me.
I use i3 on Arch with a custom dmenu (https://wiki.archlinux.org/index.php/dmenu) for opening GUI applications, along with tmux for terminal applications like OP. I also use the included i3bar (http://i3wm.org/i3bar/). i3 documentation is so good it's a joy to configure. I only have few tools, but it gets me wherever I need to go.
Xmonad, Emacs, a terminal and Chrome pretty much do the same thing for me on Ubuntu desktop, possibly with a little less pain. Mostly mouse free operation, and easy resizing, swapping etc.
If you want to learn Emacs, just jump in head first. Try and use it like a native. Just for kicks I'm trying to do the same with vi by forcing myself to use it for anything vaguely sysadmin related.
I generally like that setup better as well, but imo one of the advantages of the emacs approach is that there is more of a culture of providing extensive API hooks for scripting. If you run an RSS reader inside emacs, it's expected that it'll expose many/most of its operations via elisp function entry points, so what's going on in the reader is "transparent" in a sense: scripts can query the list of feeds, the items within the feed, the read/unread status of items, can grab the text of items, can trigger re-fetches, etc. And you can integrate that with a bookmarks manager, outgoing email, whatever.
Most tabbing window managers also provide a pretty good scripting interface, but the programs you run inside them tend to be more opaque. If you run the ncurses RSS reader 'newsbeuter' in a window, your WM scripts can't easily interact with a running instance, short of screenscraping its output and sending it raw keystrokes as input, because it doesn't expose any kind of API.
Thank you for this comment. I spent years thinking emacs was cool, but didn't quite get the push toward using emacs for everything but the kitchen sink until now. Time to take another look at it, I suppose.
He could still run Xmonad and have a workspace for a browser, only switching to it when he wants to check something. Running a proper window manager will not interfere with how many things he wants to run in Emacs.
I've run Xmonad bare on a dual core 1 GHz machine with 512 MB RAM and it ran great. The processes he runs are going to vastly outweigh Xmonad in terms of resource usage. This is one of the worst non-solutions I've seen to this, when he could've had the same setup without any of the hassle.
I really like fluxbox, is very lighweight, so my setup is fluxbox, tilda and chrome. If by some reason I want a full desktop, I just need to type Alt-f2, nautilus, and boile, gnome takes the desktop.
I agree that that is the best way to learn Emacs (and vi/vim). For me, the hard part wasn't so much learning to navigate Emacs as it was customizing it to my liking. The basics of Emacs are pretty straightforward (unlike vim, which takes a while to get used to), but using it well requires you to understand how to install packages and at least read emacs lisp.
I run Xmonad with no status bars or anything and it works great. No clutter, just the windows I want to have there. I tried it out as an experiment on my laptop to get more screen real estate and then I carried it over to my next desktop install. I used to think that it was obvious that there were things I wanted to have visible all the time, but in reality there was really only one thing that could even qualify for that and that was a clock. When I realized I could do without that, even, I decided to skip status bars entirely.
The effect is what the article is seeking, without the pain of "Oh, but if I want to do this thing I can't". Free with workspaces that can be used for anything, meaning you don't have to deal with this "It opens up on top of everything else, making multitasking useless".
There were a few 'solutions' that I was content with. You can have a workspace where you have these things (htop, other monitoring tools) and you can also have it in your vim/emacs status-line if you want to keep track of it while working.
I've never actually found that I need something _everywhere_ as much as I need to have it _somewhere_. Monitoring of things like these included.
Edit: I hesitate to call them real solutions, because obviously they are not for everyone. Some people need to see their CPU/RAM usage, network usage, clock and battery level at all times.
Nope. When logging in, I use gnome + xmonad. The topbar from Gnome (with networking etc) stays, and I use dmenu for launching. I like to keep it pretty minimal.
Nope. I already tried to use emacs as my login shell but it was not very concluding… But clearly I would like to read some feedback of someone who tries.
Half a decade ago when I was using a slow-booting (2min?) netbook, I sometimes used both this and init=/usr/bin/python when I wanted to test some idea real quick.
Rather than using Emacs standalone, I like using ratpoison as the window manager. That way I can have a full screen Emacs and easily use other applications, too. Bonus points for not having to use the mouse for any of it.
Yeah, I've used StumpWM. I don't really like Common Lisp so I don't use it anymore. I want to use guile-wm because it's written in Scheme, but it's not ready to be a daily driver.
Thanks for writing that up - I am going to work on improving my Emacs setup on my Linux and OS X laptops. I find it much easier to write or code when my screen is not cluttered so full screen Emacs makes sense for me.
BTW, off topic, but re: having a personal environment while at work: I was fortunate to work at Google for a while in 2013 and I was uncomfortable having any personal setups on my work Linux box or laptop. My solution was simple: I just used my Android phone for personal email, checking Hacker News, etc. during my lunch break. I also have a SSH shell app on my phone so in an emergency I could have accessed my personal servers. Anyway, it seems odd to spend too much effort setting up a personal environment for use at work :-)
One can get the same effect (full-screen emacs, no window decorations, Lisp) with stumpwm, a window manager written in Common Lisp. It's under active development, but it has not so far succumbed to creeping featuritis.
Yeah, the main problem with this approach is all the mouseless extensions I found for webkit (vimperator, surf, uzbl, etc) were built around Vim bindings instead of Emacs bindings. For some reason all the Emacs-centric ones (Conkeror, Keysnail) are based on Gecko.
Maybe this is because Gecko's extension mechanism is worlds better than the one that ships with Chromium, (which requires you to recompile the C++ just to change the key bindings for menu items) and the crap extension mechanism bothers Emacs users more than Vim users, but it's a weird coincidence all the same.
And it's always possible (and hopeful) that things have improved in webkit land since I last took a look.
I've been really happy with Conkeror and, IMHO, it's been more reliable than the keyboard driven, webkit browsers (Luakit, DWB, etc.) I've had issues where they'll crash on certain websites (my bank, Jira, etc.) and Conkeror will soldier on.
I thought stumpwm was dead until just now! Thanks for that.
Did they ever fix the system tray situation? When I last used it (several years ago) there was refusal by the devs to implement any sort of systray support and the third-party tools did not fill the gap, so I switched to i3.
My impression has been that emacs is a poor window manager. Granted, I am not incredibly skilled with emacs but even after some weeks I was still confused by the way emacs opened up new windows or changed existing windows when you've clicked on something (for instance, in dired or org-mode's agenda) I ended up to open everything in a new frame and left the management of these frames to awesomewm.
I agree, some Emacs commands use windows unintuitively and destructively. Dired and various searching modes (grep, ack, ag) are major offenders. You should (1) mitigate the problem with winner-mode so you can easily recover your window configuration, and (2) learn enough Elisp to tweak the poorly-thought-out commands. It usually takes me no more than 15 minutes to figure out what function does the wrong thing and add a small snippet of code to my .emacs.d/init.el which either reimplements the behavior or uses Elisp's brilliant advice feature to isolate and override with better behavior.
More modern modes usually behave well. Magit, for example, uses windows correctly.
Thanks for the suggestion of `winner-mode`! Swapping between buffer arrangements based on task (coding vs shell work, etc) always felt weird.
I solve it with having a giant editor on one monitor on one screen and a large terminal w/ tabs on the other, but that doesn't work so well if I am accessing in a headless way (e.g. remote work).
I use persp-mode (https://github.com/nex3/perspective-el), it solves nearly all my problems managing different projects, shells, code buffers, note-taking, dired, and just about everything else. The only slight wart is term.el performance, making shell output a bit slow sometimes, but I can live with it.
Emacs has many frustrating behaviors out of the box. Typo-> C-z->Crap->Grab Mouse->Expand Emacs Window->Scold self for not calling it a frame.
"Frames v. Windows" thing aside, every behavior in Emacs is configurable. It's just that the default assumes that the user fired up Dired to seriously use Dired. The default assumes that the user is using Emacs as Dired and so it becomes Dired with lots of dedicated resources. Orgmode is the same way. They don't constrain the amount of information they show in deference to other activities.
BTW, you can run "killall -CONT emacs" instead of having to use a mouse and expand the window (which is hack anyway).
You could also use cua-mode, which makes Ctrl-Z work like in other applications. Or you could use an "Emacs starter kit" which includes it (I started with "Emacs Prelude", although that doesn't include cua-mode if that's what you're after).
Other answers are given here, including a one-liner to disable Ctrl-Z completely:
Of course, this "frustrating behaviour" goes the other way too. I've lost count how many times I've made a selection in some application, then pressed Ctrl-W to cut it, only to have the document/program close!
I don't think it's fair to blame this kind of mis-match on Emacs though, since it's been around for 30 years and pre-dates the "standard" conventions by quite a bit. Emacs shouldn't have to change based on current trends, and as I've already mentioned, changing the default behaviour is a job better suited to Emacs starter kits than Emacs itself.
I don't blame the convention for not being Emacs-compatible either. It's just another unfortunate case of standardising on a sub-optimal solution. An "optimal" solution wouldn't need to work across every application, it would just minimise the chances of accidental data loss, crashes, etc. when used across as many popular applications as possible. Accidentally selecting text, or moving to the end of a line, is better than accidentally closing an application ;)
To be clear, I'm not blaming Emacs. I find it mind boggling incredible. It's computer science not an ad-supported app built about culled Creative Commons content. I've written the one liner - which just maps C-z to 'undo. Got the tee-shirt the first time. I just find myself thinking about it as a manifestation of the nature of Emacs because I seem to install some version of Linux over another a few times a year and wind up redoing the defaults because I'm too lazy in the wrong way to set up a central init.el somewheres.
Emacs takes a long time to learn and I think that's a good thing. The fact I grab the mouse after hitting C-z shows that I don't know the OS's underlying hotkeys for managing windows. It shows that I've been trained to use the mouse rather than actually control my computer. I love that Emacs points this out to me regularly.
Speaking of SuperUser, did you know that there's an Emacs site in beta on StackExchange?
Yeah, I do find it annoying how many Emacs-based applications assume they're the only thing running.
I'm developing an application built on ProofGeneral, which itself is built inside Emacs. I ran the test suite one day and one function turned out to quit Emacs if it encoutered an error! It took out all of my open shells, files, etc. (everything was saved, but I had to open them all again).
Now I'm running the tests in a dedicated Emacs process, launched via a command from eshell!
I know it's the internet and the standard assumpution is that what I wrote is a complaint.
But just to be clear, I don't find Emac's behavior annoying. I find it empowering. The idea that I might know what I am doing and be doing it seriously is refreshing. Even if I don't.
I get annoyed with the fact that I don't know Emacs better. But I love the fact that I can change that fact. I love that there's something else to learn about Emacs and that it's likely to be worth learning because it involves diving into an incredible piece of software as an object of design.
Well, I was mostly piling my own complaints on top of what you said. I also agree that Emacs is wonderful, and I agree that it's great how much power it gives us to reconfigure everything. However, that doesn't make it perfect. It's completely legitimate to point out flaws, whether they're actual bugs, subjective annoyances or hand-wavey project-wide things.
For example, I think that the Emacs community should embrace starter kits more when encouraging others to get started. Of course there's some truth to the "thrown in at the deep end" and "get to grips with the real, inner-workings" approaches, but at the same time the line has to be drawn somewhere; I doubt many would recommend new starters to compile Emacs themselves.
Still, Emacs is certainly not as scary as many make it out to be. This week I was helping out a Haskell programming class of CS students, where the instructions included setting up Emacs and installing haskell-mode (in Emacs 23, so they had to install the package manager first!). Out of a group of 60, only one struggled to do this, and it turned out to be because the sysadmin hadn't installed Emacs on the machine he was using ;)
The Emacs community embraces starter kits to the extent it makes sense to embrace starter kits. That extent is the extent to which people are willing to expend the energy to develop and maintain those configurations. My impression is that few people have the energy and will to make such projects a successful ongoing enterprise because in the end, pretending that Emacs is notepad.exe comes crashing down to the reality that Emacs is a power tool and even newbies are drawn to it for that reason. The bill for its learning curve comes through.
Do you have any other example of an Emacs application assuming it is the only thing running? I ask because I use Emacs a fair bit and don't think I've ever come across something like that.
Emacs is unfortunately still single-threaded at its core, so it indeed happens that some subpar code can hang the whole editor while waiting for some network requests to finish, or take down everything in a crash (but this happens extremely rarely; I think I had only a few random crashes on Windows in years of using Emacs).
TRAMP to me seems to be the worst offender here. If your connection is slow or you mistyped the domain you pretty much just have to wait for it to time out
I use emacs all day every day, and the only crashing problems I've had has been helm-projectile lagging and crashing if you start typing too fast after invoking it.
It's pretty bare. The thing is, anyone can build a new management library (the buffer-window tree is accessible), there are some extensions, like tabs, too, but it seems most emacsers are ok with the way things are. Things are moving a little smoother in its dev though (migration to git, windows can be sized per-pixel ...), so maybe now is the time for pushing some new ideas.
I used to be a big Emacs user, especially in my postgraduate days and would love to go back to the run everything in Emacs days but the world has changed. These days I only use it for editing text.
The many problem is that Emacs hasn't really kept up with the times. It's bloated in the wrong ways with too many default packages installed. Asynchronous processes and integrating WebKit to allow binary buffers (PDF, Images, SVG) would solve a lot of issues but I can't see it happening without a fork given the stubbornness of RMS. The recent spat over AST in gcc (which would again improve Emacs) doesn't increase the hope that things will change anytime soon.
And that the sad thing. The idea of Emacs, a scriptable, extensible environment is timeless and should not be lost to the past.
(BTW I would pay money for an Emacs fork and modernization project)
Jamie Zawinski later went to work at Netscape where he was responsible for the Unix version, and named the Mozilla open-source project that you have heard of. He cashed out of Netscape and bought the DNA Lounge nightclub.
On his blog, he likes to point out software inanities with the caption "This is why I sell beer now")
The one thing that I have never been able to work to my liking is running a shell inside emacs. I've tried the different modes (term, ansi-term, eshell) and find that they are all deficient in different ways.
I think the main issue is that I have different operating models for emacs vs a terminal and when they get mashed together I subconsciously want a superset of functionality without any conflicts. So when there are key bindings that are different in term mode I get quite annoyed. Likewise, I have no problem with copy/paste in an xterm or in emacs, but put a terminal inside emacs and copy/paste frustrates me all day.
Have you tried term/ansi-term mode in Emacs 24? I thought it (and eshell) weren't that usable in 23 but just this past week I decided to give them another go in 24. It's a huge improvement, I went from a standalone iTerm/st and occasional shell mode to eshell and ansi-term for everything. So much better.
I basically have a variation on this set up but I use Vagrant on top of VirtualBox. Then I keep the Vagrantfile and ancillary files on github. So I can theoretically show up to a computer and be able to quickly recreate my environment. I customize my VMs for Python or Clojure development and have a nicely set up emacs as foundations for both. This set up is really useful for Python where different Pythons coming from different package managers (brew, conda) tend to clash on my regular (OS X) OS.
Minor nitpick, but isn't that Firefox, not Chromium in the screenshot of the web browser overlaying emacs, right after mentioning that he uses Chromium instead of Firefox because it requires a "real" window manager?
Regardless though it's an interesting setup, I've always wanted to try a minimal window manager.
This is awesome and has opened my eyes to features of emacs I didn't know about. But I still have use for tmux because it lets me attach to the same long-running session on a remote host from multiple clients. I'll probably just start having emacs be the only window open in my tmux session.
I use emacs every day. You'll soon find emacs is a terrible xterm/gnome-term/iterm/whatever-term.
* The emacs terminal is very slow. Run a command that produces a few hundred lines of output and you need to wait 30 seconds for it to catch up. A dedicated terminal program displays the output several orders of magnitude faster.
* Emacs crashes or freezes from time to time forcing you to kill all your emacs terminals anyway. It isn't nearly as stable as tmux.
That said you can connect to a tmux session with an emacs terminal. That fixes the stability issue - even if emacs crashes your tmux session lives on. It doesn't handle resizing well, and it is still slow as molasses.
I do use emacs server. That plus emacsclient allows you to open files instantly, and your term mode and gui mode emacs can share buffers.
Interesting idea. I would just use something like DWM, a lightweight tiling window manager. You still get the simplicity but with a bit more flexibility. Most people will probably quickly hit a deal breaker with just using Emacs as a WM.
I agree. He's not really using Emacs as a WM, so much as using no WM, and doing as much as possible within Emacs. Note that Emacs can be used as a WM, with a little effort: http://www.emacswiki.org/emacs/EmacsXWidgets
I much prefer my current Xmonad setup to this "Emacs WM":
1) My windows are all fullscreen, whilst his are stuck at their app-specific defaults.
2) I can use multiple desktops (in practice, each one holds a different app, including 2 instances of Emacs)
3) I can show one desktop on my laptop screen and another on an external monitor (or occasionally a projector). I have no idea how his setup would cope with multiple screens.
4) I can have long-running external windows. He must close his before returning to Emacs. Whilst I could live without this, it would be a pain. Even if I only used each app temporarily, I'd have to wait for them to start up every time.
5) I can run slow Emacs applications in a separate instance. I read my mail with Gnus, which gives me four options:
5a) Run Gnus in my main Emacs instance, which will freeze every time updates are fetched.
5b) Start a separate Emacs instance for Gnus, which I must wait for as it fetches updates, since it is overlayed above my main Emacs instance.
5c) Start a separate Emacs instance for Gnus in a terminal, which of course limits me to a character-based interface, and causes key conflicts between the outer and inner Emacs instances.
5d) Have a long-running GUI Emacs instance, fetching mail on another desktop, which doesn't interfere with my main Emacs and I can switch to instantly whenever I like.
The OP uses (set-frame-parameter nil 'fullscreen 'fullboth).
In contrast, I use (set-frame-parameter nil 'fullscreen 'maximized) leaving OS X's menu bar and Dock on the screen.
I do not know if Homebrew package `emacs` has been fixed because these years, I only ever install Homebrew package `emacs-mac` (a.k.a., Mitsuharu Emacs) but it used to be that one had to install Emacs.app via `brew install emacs-mac` instead of the conventional `brew install emacs` for (set-frame-parameter nil 'fullscreen 'maximized) to automatically and cleanly occupy every screen pixel except for the pixels needed for the menu bar and the Dock.
I cannot do a definitive test because I only ever use one monitor at a time, but since (set-frame-parameter nil 'fullscreen 'maximized) does not make use of the fullscreen mode introduced by Apple with Lion, it will almost certainly not suffer from the most-complained-about problem with multiple monitors on OS X.
In contrast, (set-frame-parameter nil 'fullscreen 'fullboth) does make use of Lion's fullscreen mode -- and it gets rid of the menu bar and the Dock, letting the Emacs frame occupy every screen pixel. But then at least on Lion and Mountain Lion (which is the extent of my experience with recent versions of OS X) multi-monitor support is hosed IIUC.
I can tell you how I switched a couple of years ago.
I started to use emacs for the sql-oracle mode since it was tons better than the standard sqlplus client shipped by Oracle. I still kept doing most of my coding in vim but gradually was learning emacs by working with that sql mode (there is of course a mode for every database there).
Later on I started doing notes in org-mode as it was also nicer than anything else I used at that time. The ability to do ad-hoc tables/spreadsheets in it helped a lot. Then stuff just started rapidly speeding up. I found out that browsing changesets with the emacs vcs mode is great (you can open up a file in annotation mode and flip back/forward through revisions). Browsing the filesystem, grepping from withing emacs etc.
By playing around with the modes I got really used to how the editor ticks and switching to coding in it daily was just a natural evolution as I started doing more & more stuff from inside of emacs.
My experience was similar, except with Sublime. I used Sublime for most things and org-mode for note taking. Then I started using emacs for personal projects but kept using Sublime at work. Eventually I started to feel almost as productive with emacs as Sublime. Once I found projectile and helm-projectile for project navigation, I made the switch entirely.
Alternative: go full-on emacs, without evil. I think you need to do that, at least at first, to really learn emacs.
How to still get your work done: continue to use vim for your "work," and at first just use emacs to learn emacs. As soon as practical, start using emacs to do just one thing from your work. Somewhere soon after this you'll be comfortable enough to do everything from emacs (although still not an expert), and then you'll be able to decide to stick with it or go back.
I started to learn Emacs with its native commands and shortcuts. But I switched to evil when I noticed than I was unable to memorize the shortcuts for some basic actions like "add a character to the end of each line".
Today I use evil-mode for all tasks and to be honest I don't think I'm missing something.
The Emacs shortcuts are not mandatory to benefit of the power of Emacs, which resides essentially into its modularity and plugins.
I've been looking into spacemacs, but I've found it to be a bit bloated vs. my personal config. It takes longer to start up, and sometimes just typing text in Insert Mode was sluggish (I imagine due to one of the autocomplete/typeahead libraries). That said, it has a lot of nice things and nice ideas. I'm undecided if I want to port my personal config to spacemacs, or just pull things out of spacemacs into my personal config.
I think I had sluggish behaviour sometime ago - but the updates to the config are happening at a very fast pace. I'm a pretty happy user. Also, the chat on https://gitter.im/syl20bnr/spacemacs is very active too, may be someone there could answer your specific questions (if you haven't asked already).
EDIT: you can also disable the packages you don't need, perhaps that's an option.
> EDIT: you can also disable the packages you don't need, perhaps that's an option.
I realize that, but it also means tracking down which thing is misbehaving because it's not immediately obvious.
I haven't given up on Spacemacs, but for the time being, I'll need to swap back and forth with my personal config so that I can get work done. At the very least, there are things that I like about it that I'll want to figure out and pull into my personal config.
There are also some things that could use a bit more documentation. For example, porting parts of my config over, I didn't realize that :nohlsearch was already bound to evil-search-persist-remove-all in the Spacemacs initialization.
It took all day Saturday to configure things so they mostly behaved the same as my vim environment, mixed with learning emacs specific stuff along the way. There's a few quirks I still need to work out, but the power to configure absolutely anything is worth the switch in my book. I have to admit, I wish I had made the switch sooner.
The biggest thing I desire right now, and maybe I just don't know what to look for, is a way to swap between full sets of buffers. i.e. Group A: handful of IRC windows, Group B: project 1's code buffers, Group C: project 2's code buffers, etc. Maybe someone has a tip?
Being a Vim user of 4+ years, and having made 2 previous attempts at switching to Emacs, this is the setup that finally made me immediately productive enough to get work done. Been using this as my primary environment for more than a month now.
Thanks for this, looks like like a better, more encompassing version of the evil-mode + customisations that I've hacked together thus far for emacs.
Amongst many other changes I've remapped the spacebar (while in normal mode) to send a C-x, colon (:) to send a M-x, so I have access to a ton of emacs commands while mainly just using vim.
I am Windows/Mac user and I spent a bit of time trying to configure emacs across all my machines. I think it's fair to say that it wasn't designed to be configured cross platform, which is a shame. When I can be bothered I will have to create .emacs files for each platform that I use
I disagree. I have been using the same init.el across Windows and Mac for several years. Hardly anything needs to be tailored but you can inspect the system-type variable if it is really necessary.
I use the same `.emacs` on both Windows and Linux. I put some Windows-specific stuff in a separate file that I load only when `(string-match "nt" (symbol-name system-type))`.
The biggest cross-platform difficulties are the emacs version and OSX.
Make sure all your computers have the same major version (all 23 or all 24; I recommend 24 as it actually has a package manager). OSX was for several years a problem for emacs as there were two or three incompatible ports that did things differently; it's probably gotten better over time.
As preavy said, the rest can be handled by checking the OS type, machine name, user name, etc in your init files (they're not just config files, they're emacs lisp programs that get run during startup).
I keep mine in a git repository to make syncing the changes over time easier.
Yes !
I highly recommand this plugin to those who are not familiar with the strange Emacs shortcuts ... but also to those who are not familiar with vim. evil-mode allows to learn Emacs and Vim at the same time, it's perfect for a beginner.
I use emacs with evil, it gives you a fully functional vim emulator inside emacs. Since vim is the best text editor and emacs is the best OS, it's perfect!
There are things that are missing, but you can modify them. Examples:
I use Ctrl-6 a lot in Vim, but Evil mode only implements it as Ctrl-Shift-6. But it's easy to create the binding (especially since the function that implements the functionality is already there).
The :sort command doesn't exist, but there is :sort-lines, etc.
The other thing that is a bit lacking is folding. Emacs doesn't have folding baked in, and there are several folding implementations (outline-mode, hide-show-mode, etc). I haven't found a good setup of all of the z* commands for folding. spacemacs does a good job of setting them up for org-mode (which leans on outline-mode for folding), but also doesn't implement zj / zk folding movement bindings.
I would love to do something similar. I recently switched from Weechat to ERC, and started getting into eshell more heavily.
However, I must have a browser window open at all times. There is no way around this. So, unless another solution presents itself, I will continue using dwm with Emacs / Firefox.
He says that his work is virtualization systems, so the install of (e.g.) VirtualBox itself is not "personal software." It really comes down to whether or not you consider the guest OS image running in the virtualization system to be "installing personal software."
Most IP reassignments I've ever signed have included the clause "any IP developed with the company's resources belongs to the company".
This would include anything created in such a VM, unfortunately. So, if you're not worried about that, it's a great separation of concerns. If you are developing new IP, though, you would want to be very careful about using your work machine.
I'm even nervous about logging into a personal machine via SSH from my corporate laptop, if I'm honest. Might not be enough to legally take ownership, but its probably enough to draw you into a protracted legal battle.
It doesn't sound like he's "creating" anything of value in the VMs. He notes that he mostly uses it for org-mode. It's probably just him needing to access (from his work computer) to notes / agenda info that he would rather keep (e.g.) on his personal Dropbox.
You are right though that anything done using "company resources" may be fair game for a legal battle to determine ownership.
Can emacs soft-wrap at a set column size without doing so in the middle of a word? When I last tried to get into it I couldn't get it to do this, and that put me off my meal.
Yeah, if you set the buffer-local variable "word-wrap". As noted in the docs for that variable, you probably just want to use "visual-line-mode", as that sets it and also adjusts some navigation keybindings to account for the soft wrapping. Works pretty well, overall.
What is the best way to actually learn emacs? I'm a vim guy who is curious enough to switch but I'd rather just hack the introductory process and get to the fun bits.
I read the built in help and the recommended parts didn't take too long (30 - 90 minutes somewhere I guess).
Used the GUI version (the menus are usueful for reference when I started) but learned the new copy / paste keys instead of using Windows standard and generally try to pick up every shortcut.
I've tried a few "distros" and found one I liked. I also spent a little (too much?) time on implementing org-mode, mostly according to http://doc.norang.ca/org-mode.html
Wouldn't use it for window manager though for roughly the same reasons I wouldn't use the tractor to go shopping with the family.
(Background: I've used vim for configuration for the last few years and ST2/3 + Netbeans for developement, never touched emacs before last fall except by accident.)
The most interesting cultural observation thats not often talked about is bare emacs and bare vi are equivalent-ish, but all the "cool" stuff in emacs is in the addons.
If you just use bare emacs you'll think its pretty boring and not see any productivity gains.
If you use a pre-packaged set for emacs, you'll be utterly overwhelmed trying to learn a million things at once. There are no pre-pack sets with just systemic improvements.
Another cultural thing is there's addons for emacs that improve everything (like helm) and addons that provide one nifty feature (like magit) and addons that are affinity specific (like clojure-mode thats of interest to clojure coders but not likely other coders). So we call them all the same thing, addon or extension or whatever, but there's 3 classes of thing with that name that differ in how you interact with them and they interact with you.
So ... my advice is install your vanilla emacs, put in the stereotypical system wide addons maybe just helm, and then add one package at a time figuring out what they do.
Aggressive-indent rather forcefully indents your code as it sees fit, which some like, others hate. Maybe a good place to start?
So projectile and helm-projectile makes opening files in the same project simple. It understands your git repos and you can open any file in that repo and a lot of other repo related stuff.
And perspective lets to segregate multiple project buffers so however unwise it is, you can work on multiple separate real world projects at the same time.
And flycheck does on the fly highlighting of errors in your code.
And magit does git inside emacs sorta
rainbow-* does colorful syntax highlighting (or drives people nuts)
yasnippet adds tab completion (so "i" "f" "tab" give you a whole if-then stanza ready for editing, depending on your language)
Trying to add all that at once would drive you nuts, so one package at a time till you feel OK with it. I still don't entirely feel OK with magit, whatever.
There's also language specific packages although cider and clojure-mode will be quite useless unless you code clojure, etc.
Learning Emacs is a very interactive process (much as Emacs itself). It's best to introduce new extensions one by one as you need them, and spending some time using them.
I consider myself a noob Emacs user (having been using it exclusively for the last 4+ years), and here's a trick I use if I feel overwhelmed/annoyed by some extension: I decide to spend 30-60 minutes (to the clock; personally I measure it in pomodoros) practicing the mode itself. Such focused learning gives wonderful results. For instance, I spent 30 minutes on learning multiple-cursors.el and now I can't imagine living without it. Or I was always confused by Paredit, but it took about one hour of practicing it to become proficient in it. Again, I now can't imagine working in Lisp without Paredit.
Discovering interesting modes can be a task in itself; I suggest browsing through at least Emacs Rocks short videos[0], they introduce many a handy utility.
@melpa_emacs twitter feed automatically lets you know packages that are under development. That doesn't mean they're any good LOL, but it does mean they're definitely not abandoned.
meta x package-list-packages or something like that and scroll thru 3000 or so packages. I used to do that with Debian in the 90s or so when there were only a couple thousand packages, to see whats new.
HELM input method addon for emacs is interesting. So you hit alt-x and type pac (spacebar) lis and it searches the command list for the regex pac (logical AND) lis and returns the set of scrollable results. Its why I don't remember if the command is packages-list-packages or elpa-list-package-list or whatever, no cognitive need anymore, you want a list of packages you type some of the word package, spacebar and some of the word list, and its right there, ready for up and down arrow and hit enter. And HELM is applied to pretty much everything in emacs, running commands, switching buffers, opening files, projectile addon stuff... pretty awesome. I think it took me about a month to completely break my decades old tab completion habit when opening files LOL.
Just scrollin about the emacswiki finds some interesting addons.
Finally if you install a pre-pack of 50 addons and init file, you'll be blown away, but they can be a nice map or todo list. I think that was how I discovered perspective addon, I'd seen it and shrugged shoulders, but everyone likes it in the lists of pre-packs so I gave it a try, and I really liked it after trying.
AFAIK there is no "emacs addon of the week" twitter feed or podcast or screencast. This would be an interesting microstartup for some bored new emacs user. "Lets play" screencast video series on youtube featuring exactly one emacs extension per episode sounds fun.
> The most interesting cultural observation thats not often talked about is bare emacs and bare vi are equivalent-ish, but all the "cool" stuff in emacs is in the addons.
Agreed. That's pretty much the point. "GNU Emacs is an extensible, customizable text editor."
So it starts off bare but it's extensible and customizable.
That's it. That's the value proposition right there.
Something waiting to be done: a /Handmade Hero/-style webcast by a vim fan who wants to create vim usage within emacs, from scratch. The warm-up week could be a guide to lisp.
I was a heavy Vim user, and what worked for me was forcing myself to use emacs for a project. Other people use evil-mode, but I kept the standard key bindings. Use the help as much as you can, and learn about functions like C-h k and C-h m. I stayed with emacs for org-mode, for buffer management, and then for projectile, magit, flycheck, mu4e, etc etc...
I'm a self-considered emacs user, but I like evil-mode. But I'd also recommend sticking to just emacs when switching (I think 20-30 days of "only emacs keybindings" may be enough) to learn a little about its normal keybindings. It's important to know where you are moving, even if then you change the furniture ;)
I've never tried evil-mode, but I always thought it would confuse me when using things like helm and magit and org-mode that (sometimes) use emacs-like bindings for their controls. Do you run into any problems with this?
Since the goal is a low VM footprint, rather than install a X on the VM, I'd rather use Emacs as my kernel init process and simply use my host web browser when needed.
> I always grin when I read the change log in the release notes of any window manager project. It begins by complaining that all other window managers are bloated, and that this one will be small and efficient, [...] and soon the project is just as big as the competition
I bet he doesn't grin thinking about how many things can Emacs do other than editing text. That said, I like people with peculiar workflows, they open up ideas and discussions.
Yeah, but it has the virtue of existing, unlike (sadly) Genera.
One of the reasons I like to use stumpwm (c.f. supra) is that I have an always-running Common Lisp process which I can connect to. I have some ideas about how to make it even cooler, but sadly I've not explored them yet.
There's eshell, shell and term, each with tradeoffs (see on of my other comments). I have an external terminal running tmux and a bunch of curses programs (wicd-curses, alsamixer and cmus) but do everything else in shell mode or eshell mode.
To me, the killer feature of shell mode is the ability to manipulate the buffer contents like any other file. The killer feature of eshell is its built-in TRAMP support, for manipulating and opening remote files transparently. Eshell's lack of pipes makes shell mode my default though.
I think you could get approximately his same functionality with a terminal (e.g urxvt) and tmux for the splitting. In fact I do essentially that at work on Windows, from a cygwin terminal and tmux. When it fits whatever workflow I'm doing from within cygwin, I'll launch the occasional Windows program from there; the rest of the corporate Outlook, IE etc is done normally from Windows.
At home on Linux I get my basic window splitting from my window manager, i3wm. If I need more terminal-ish splitting I'll run tmux in a urxvt.
... still jealous of emacs though.