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.
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.
And it is a little worse on the kinesis, as the function keys are not the same quality as the rest of the keys.
It's also kinda nice setting up emacs in a cygwin that winds up being relatively consistent with mac.
(warning stars are turned into formatting in HN)
with C-c M-b to pick a buffer name easily
I thought eshell had both pipes and output redirection but lacked input redirection.
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).
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 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.
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.
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.
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.
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".
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.
My config is here https://github.com/simonswain/dotxmonad
initrd=/install/initrd.gz quiet init=/usr/bin/emacs
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 :-)
And one can then run Firefox instead of Chrome…
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.
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.
Unfortunately, it's getting harder and harder to use GNOME with anything other than the GNOME WM.
I really should post my pure-stumpwm config on GitHub one of these days. It really is a nice desktop-environment replacement.
More modern modes usually behave well. Magit, for example, uses windows correctly.
Here is an example of how I used advice to fix bad mouse behavior (yes, I use the mouse sometimes to switch windows): http://emacs.stackexchange.com/questions/7347/preventing-mou...
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).
"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.
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 ;)
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?
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!
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.
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 ;)
Otherwise it's rock solid.
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)
> (BTW I would pay money for an Emacs fork and modernization project)
(for some background: http://www.jwz.org/doc/lemacs.html
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")
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.
It looks like it's meant to be included directly as a config file, which seems like deep magic to me. :-)
Sorry for answering late:
You'll need tangle/babel
➜ .emacs.d cat init.el
Regardless though it's an interesting setup, I've always wanted to try a minimal window manager.
* 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.
Likewise, it wouldn't be "using Firefox as a WM" by just running Web apps in a fullscreen FF. You'd need something like PyroDesktop http://web.archive.org/web/20080905102046/http://www.pyrodes...
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.
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.
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 love your modeline, which is actually clear - any pointers to how to do it myself? I'm using Prelude (I know) which does its own weirdness.
 - https://github.com/howardabrams/dot-files/blob/master/emacs....
 - Yes, he writes his configs in org-mode. This is the first time I've actually seen literate programming used and it's beautiful.
Any tip for a convert like me? Is the "trick" just to make the jump and persist until it clicks? How do I still get my job done in the mean time?
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.
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.
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.
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
What flavour of Emacs are you using on Windows?
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.
I have my .emacs.d symlinked to a folder in Dropbox. So to set up on a new machine I just have to install Dropbox and make a new symlink.
This also worked for me in Ubuntu.
I was concerned when package management came in as a lot more stuff seems to get downloaded, but it just seems to look after itself.
Also, I've had good luck with Emacs Live. http://github.com/overtone/emacs-live
There was at least another tiled window manager able to embed GUI windows.
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.
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.
> My remedy is to install a virtualization system...
which is personal software.
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.
You are right though that anything done using "company resources" may be fair game for a legal battle to determine ownership.
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.)
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, they introduce many a handy utility.
 - http://emacsrocks.com/
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.
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.
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.
p.s. xmonad + vim is the true way ;-)
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.
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.