It's basically the same as the distribution from http://emacsformacosx.com, but it supports various enhancements made for mac, eg. resize text size with trackpad, smooth buffer scrolling and SVG support, which is quite convenient when used with the jupyter notebook interface and producing plots. See for instance : http://imgur.com/gallery/vEI2z.
I use this version too and have been very pleased with it. It's also available via Homebrew [1].
As an aside, I'm looking forward to better support for text scaling in future [2,3] as it's a feature that (if it was compatible with autocomplete and company-mode) fits my workflow better than zoom-frm.
I've been trying Spacemacs with Evil mode on (I'm a regular Vim user), and I can kind of manage to use it for day-to-day editing and running Make, but it feels like I'm about to be eaten by snakes because I now have to deal with three additional meta key-combos (alt-x, C-c and space-m) in addition to the one I had for i3 (now banished from alt to Win) and I also have to learn escape codes to use my terminal and use them a lot to Vim on remote hosts over SSH.
I tried prelude and a few other starter kits, but still had trouble because the starter kits change the default behaviors, which can be confusing when trying to troubleshoot or find answers. I personally feel its better to start "vanilla" and understand the various Emacs concepts.
The built-in tutorial is good. It gets you through the basics of navigating.
Even after having used it for a few years, I enjoyed Mastering Emacs [1]. There are several "getting started" articles on the website and if you find them helpful, the book is also good, in my opinion.
Print out one of the many reference cards available (the official one is available on the Gnu website [2]).
Try org-mode [3], which is built in. It's extremely useful and a gateway to emacs.
I suggest working with just evil mode for a bit, or going all the way with vanilla emacs. Spacemacs is great, but overwhelming. Also, spacemacs should not be used in sensitive contexts, because it is a massive security hole: it brings in a vast number of melpa packages, the git repositories for any one of which could be compromised. And whenever spacemacs updates, it updates all those packages for you, and melpa updates a package on any new commit to the source git repository.
I don't think there is. I've been trying to move from vim to Emacs for a few weeks unsuccessfully, mostly for org-mode and all the agenda stuff. I still use emacs for org-mode but I don't feel comfortable using it for normal code editing.
I am using evil mode, Helm, Projectile and Jedi for completion, and even though everything is more or less configured and took me around 300 lines of elisp I still find all the time defaults that are completely different to vim and I'll have to fix at some point and I am not sure how much time and code it will take to make it feel comfortable. Just a few problems from the top of my head:
- evil-mode "u" to undo changes sometimes works and sometimes does crazy stuff. I think it has something to do with incompatible modes, specially org-mode.
- Tab doesn't work, I'll have to investigate how to make it work properly.
- The defaults for Projectile for opening files inside a project look and feel horrible, it's configurable but I'll have to investigate and probably spend a few hours writing elisp until I have it working to my taste.
- Things like ":set nowrap" don't seem to work in evil-mode, I'll have to investigate how to do the same in emacs.
- The completion is kind of weird and it appears automatically instead of using a key to activate it. Again it's configurable, but I'll have to spend a bunch of time getting it to work as I want.
- If you do ":e path/to/file" and then you try to open another file from inside emacs using ":e [TAB]" it will work as if you changed to "path/to" instead of the original directory.
And this is just from the top of my head without having used it for a few weeks now as I don't have the time to configure all that stuff. I'd say that evil-mode is not transparent enough to make the change simple.
I'm running i3 with alt as my modifier key on one laptop and win key on the other and run emacs just fine. I run a pretty basic setup and I really need to go pull out a few things I never use anymore. I set caps lock as control, now, though.
What really helped me get started was using a specific tool/ language. After playing around in Clojure for a while, I learned how to use emacs for a better REPL experience, but I did everything else in Sublime. Most of my school work at the time was in python so I worked on switching that workflow over to emacs. Eventually got pretty comfortable with python too. A few years later and it's now my main editor. It took a few days to figure things out, and a few months to get really comfortable, but I'm now really happy.
I run emacs in window mode and rarely use emacs in the terminal for the same reasons you mentioned. At some point I started using projectile for project management and now I can fuzzy fine files and fuzzy find projects on my system without needing to switch to the terminal. And now if I'm in a terminal, it's probably because I'm using vim on some remote host.
I recently tried switching to spacemacs from my custom init.el, and after a half hour switched back. It did inspire me to spend some time improving my setup, but elisp is so simple to work with once you learn it a bit, that there's really no reason not to just roll your own config.
I don't need 200+ key combinations off my leader. I have about 10 for the things I use often, and if I find myself pulling up commands from Alt+X (mapped to space x) regularly, I add that to a new leader mapping.
Use-package is really convenient to learn for setting up your config.
Other than that, the things I find I can't live without:
* Ivy/Counsul
* Company
* Flyckeck
* Flyspell
* Evil
If you take a look at spacemacs's GitHub, dive into their "layers" and pop open the packages file for any given layer for inspiration of other things to add for your desired languages/features. But integrate then yourself given the packages' instructions. You'll be far better off knowing your setup intimately than learning to skim the very large surface area of spacemacs.
Some of it has been subsumed into newer emacs releases.
In general, find out which modes are considered best for whatever you are doing, install them, and then learn how to modify the configuration file to customize how the rest of the UI works.
Learn to use the help commands (press "C-h ?" for a list). Apropos especially ("C-h a"). Personally, that's what got me hooked. The self-documenting was so mind-blowing to me at the time; I would spend hours just looking commands up.
The text editor, the extensions, and elisp. Pick a use case you really want to get into (Editing code in language X) and dig into that one use case first. Or taking notes (Learn Org mode). But pick just /one/ use case to start your practice.
Work through it up to chapter 9. Practice each command. There is (mostly) a rhythm. Memorize and emblazon the "describe key" shortcut into thy mind. Clear your mental desk and just do it for 30 minutes. It really isn't that bad, you just have to give it a little time and practice.
Packages / Modes:
There are a few packages in Emacs that are life savers. Get melpa working. Install and learn helm. Helm provides a completion buffer system for things like file selection and and commands. Helm is that /one/ thing I can't live without for extended Emacs usage.
Learn Lisp:
If this is going to be more than just a toe in endeavor, you need to learn lisp. When you learn the rudiments of elisp and build a couple of small modes or extensions for yourself or customize existing modes a little so many things about emacs just "click". Want to bang out some quick math or do a quick base 64 decode? An example document:
'''
This is a document where I am thinking.
Oh, I needed to do some quick math:
(- 2017 1980)[C-x e] -- result appears in Message area.
'''
Things and concepts not to miss:
CUA mode / block selection, macros (very easy and nice), regions, buffers, point, mark, registers. Things you might not think much about: The kill ring. Learn and read about the kill ring.
Final thought:
M-x = never remember all the shortcuts again. With helm doing fuzzy matching you only have to remember much easier to remember english names for things. Naming is consistent for modes too, so to start searching for "what was that Org mode shortcut?" Start typing 'org pro' oh yeah, org promote! [Whack enter] indents a sub tree in my notes. Then I usually remember the shortcut from there out because it is shown on the commands. M-x along with describe key are life savers as you can go from shortcut to function name and function name to shortcut and you can lazily search through commands and buffers. Helm makes buffers easy.
To summarize:
1.) Learn the editor Emacs and focus on editing on specific type of document (Markdown, Org, programming language). Follow whatever popular setup guide you find for document type X.
2.) Learn the extensions Emacs. Helm is a must-try.
3.) Learn elisp and get used to the idea you are in a giant lisp machine. Running lisp code /anywhere, anytime/ in your documents is awesome.
4.) Learn the little tips and tricks.
5.) Use evil mode if you must, but I have found being fluent in Emacs is great (iPython, for example, is very Emacs biased in its readline / shortcuts). Tons of other tools (mutt) will go with vim like bindings, so taking the time to be fluent in both means you are almost guaranteed to have the right shortcuts in your brain.
6.) I feel your pain about the shortcuts. I have it mostly down to 3: Emacs, Tmux, i3. I try to ram everything through that set of shortcuts, and then a small set of my tools I use a lot use vim bindings, and I am ok with that (mutt, mitmproxy).
First, at the risk of pissing off fellow emacs-ers -- if you're already a regular Vim user, why not stick to it? It's a great editor, and I know a lot of people who use it and are just as productive as I am with emacs. Plus, if anyone ever needs to use their computer, you won't get weird looks when you tell them Caps Lock is Control on your keyboard...
Anyway, if you absolutely want to learn something else, I'd suggest going the other way 'round, really: start with something minimal and work your way up from there.
For the first 1-2 years, I think, I've used Emacs as little more than a glorified Notepad clone (in fact, I even used it with cua-mode). I think my .emacs file was barely ten lines long. I was transitioning to Emacs from nedit, an old-ish Unix editor with a Motif UI that was getting increasingly difficult to digest and kept crashing and had trouble with Unicode and man I'm old... anyway, all I really needed it to do was let me write text and paint it in pretty colors sometimes.
I then sort of picked up its features one by one, as I needed them. The keybindings came first, because it was weird the arrow keys for motion and the other keys for everything else. Then I got a larger monitor and I could fit more than two windows on it and I installed window-mode so that I could switch between windows with M-1, M-2 and so on.
(Please remember this was 2005 or 2006 or something, a 21" CRT was a big deal for me...)
That's pretty much how I picked up everything else: first big C project was how I picked up xrefactory, then xcscope. First time I had to do big merges was how I picked up ediff, and so on.
The best thing about having something as scriptable and customizable as emacs is being able to make it work exactly the way you want it. Making it work exactly the way someone else wants it sort of defeats the purpose, I mean, any editor already works the way someone else wants it.
Edit: ah, yes, to address some of your pain points:
- Remote editing: look into something called tramp-mode. It's not perfect, and I, for one, use it sparingly, but it may fit your use case.
- Weird key combinations: I'm not sure what to say other than "you get used to them". It may be worth looking into how i3 deals with this stuff, too. I no longer use a tiling WM, but when I used ratpoison, it fit near Emacs pretty well -- I bound C-t to Ratpoison's prefix key, and just didn't use C-t for anything in Emacs. But then again, Ratpoison (and its successort, scrotwm) were both written by Emacs enthusiasts, and used similar key sequences.
If you're curious about anything else, ask away :-)
Has there been any update to the status of GuileEmacs? I have read that it aims to be "the future of Emacs", but I rarely see mention of Guile from the Emacs community.
It isn't the Emacs devs who are really asking for GuileEmacs. Rather, it’s Guile fans who are proposing to integrate a software they love into Emacs for mutual benefit. While the Emacs devs don't a priori reject such a thing, they naturally insist that the Guile-based Emacs be a mature, stable and faster piece of software before it is considered for the mainline, and that just hasn’t happened because only a handful of people are working on it.
Last thing I heard was that Guile-Elisp (and by consequence Guile-Emacs) is working, but very slow. That can be fixed but requires work. Also, Emacs internally uses a different string representation from Guile. This makes the transition between languages tough and some more glue is required.
IMHO Guile-Emacs is "nearly there". I.e. with just a little more work it could have enough momentum and attract developers to be on the trajectory of becoming the default elisp implementation in the long term.
Having the new Guile 2.2 VM drive Emacs would definitely improve things. And the C-codebase could become considerably smaller and cleaner.
It seems amazing to me that EMACS is just now getting ready to implement multi-threading.
Isn't that so 1990's?
Please I mean no disrespect...I was first exposed to EMACS in the late 80's if I remember correctly and have followed it's growth over the many years since, but I can't help but feel that introducing non-blocking threading is something that should have happened long ago.
Emacs and VIM are probably those two software pieces that to me look like from another era that I have not lived through and thus cannot get my head around.
As an Emacs user, I still don't get why they have the menu bar and tool bar, they have always been harder to use than the other methods of interaction, and most people don't discover much through them anyway since the menu bar is so cluttered.
Nonetheless, very happy with it once I put in my relatively small config.
When I first started using Emacs I found the menu bar useful for discovering features I had no idea existed. I quickly became fluent with the keyboard UI and can use that to explore the editor now, but it taught me not to underestimate menus. They might not be particularly useful, but they helped me find a few hidden gems.
Largely because some people use it, and for those who don't putting this in their .emacs serves as a straightforward tutorial focus and a right of passage:
The right-hand side of the menu bar can be helpful in application-like modes (like gnus or M-x list-packages). I agree you might as well turn it off otherwise and regain the space.
Wow, the Emacs website is really pretty. But I like vim's one too - I feel they symbolize the internal ideals: vim being lean and small with just the essentials (at just 230 kB) while Emacs is more fully loaded (930 kB).
I get that you meant it in comparison to 230k, but in the modern world I find it hilarious that a 930k website is being called (essentially) heavy. If only...
[+] [-] thomasdziedzic|9 years ago|reply
[+] [-] amiralul|9 years ago|reply
[+] [-] sunilkumarc|9 years ago|reply
[+] [-] tlikonen|9 years ago|reply
[+] [-] lindbergh|9 years ago|reply
It's basically the same as the distribution from http://emacsformacosx.com, but it supports various enhancements made for mac, eg. resize text size with trackpad, smooth buffer scrolling and SVG support, which is quite convenient when used with the jupyter notebook interface and producing plots. See for instance : http://imgur.com/gallery/vEI2z.
[+] [-] wlkr|9 years ago|reply
As an aside, I'm looking forward to better support for text scaling in future [2,3] as it's a feature that (if it was compatible with autocomplete and company-mode) fits my workflow better than zoom-frm.
[1]: https://github.com/railwaycat/homebrew-emacsmacport
[2]: https://github.com/company-mode/company-mode/issues/299
[3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18493
[+] [-] stinkytaco|9 years ago|reply
[+] [-] justinhj|9 years ago|reply
[+] [-] nxrabl|9 years ago|reply
[+] [-] cryptarch|9 years ago|reply
I've been trying Spacemacs with Evil mode on (I'm a regular Vim user), and I can kind of manage to use it for day-to-day editing and running Make, but it feels like I'm about to be eaten by snakes because I now have to deal with three additional meta key-combos (alt-x, C-c and space-m) in addition to the one I had for i3 (now banished from alt to Win) and I also have to learn escape codes to use my terminal and use them a lot to Vim on remote hosts over SSH.
[+] [-] stinkytaco|9 years ago|reply
The built-in tutorial is good. It gets you through the basics of navigating.
Even after having used it for a few years, I enjoyed Mastering Emacs [1]. There are several "getting started" articles on the website and if you find them helpful, the book is also good, in my opinion.
Print out one of the many reference cards available (the official one is available on the Gnu website [2]).
Try org-mode [3], which is built in. It's extremely useful and a gateway to emacs.
[1]:https://www.masteringemacs.org/
[2]:https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf
[3]:http://orgmode.org/
EDIT: Oh, and for remote hosts, I find it easiest to connect with Emacs, rather than connect and try to run Emacs from the remote host.
[+] [-] AlexCoventry|9 years ago|reply
[+] [-] carapat_virulat|9 years ago|reply
I am using evil mode, Helm, Projectile and Jedi for completion, and even though everything is more or less configured and took me around 300 lines of elisp I still find all the time defaults that are completely different to vim and I'll have to fix at some point and I am not sure how much time and code it will take to make it feel comfortable. Just a few problems from the top of my head:
- evil-mode "u" to undo changes sometimes works and sometimes does crazy stuff. I think it has something to do with incompatible modes, specially org-mode.
- Tab doesn't work, I'll have to investigate how to make it work properly.
- The defaults for Projectile for opening files inside a project look and feel horrible, it's configurable but I'll have to investigate and probably spend a few hours writing elisp until I have it working to my taste.
- Things like ":set nowrap" don't seem to work in evil-mode, I'll have to investigate how to do the same in emacs.
- The completion is kind of weird and it appears automatically instead of using a key to activate it. Again it's configurable, but I'll have to spend a bunch of time getting it to work as I want.
- If you do ":e path/to/file" and then you try to open another file from inside emacs using ":e [TAB]" it will work as if you changed to "path/to" instead of the original directory.
And this is just from the top of my head without having used it for a few weeks now as I don't have the time to configure all that stuff. I'd say that evil-mode is not transparent enough to make the change simple.
[+] [-] kqr|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] film42|9 years ago|reply
What really helped me get started was using a specific tool/ language. After playing around in Clojure for a while, I learned how to use emacs for a better REPL experience, but I did everything else in Sublime. Most of my school work at the time was in python so I worked on switching that workflow over to emacs. Eventually got pretty comfortable with python too. A few years later and it's now my main editor. It took a few days to figure things out, and a few months to get really comfortable, but I'm now really happy.
I run emacs in window mode and rarely use emacs in the terminal for the same reasons you mentioned. At some point I started using projectile for project management and now I can fuzzy fine files and fuzzy find projects on my system without needing to switch to the terminal. And now if I'm in a terminal, it's probably because I'm using vim on some remote host.
[+] [-] kromem|9 years ago|reply
I don't need 200+ key combinations off my leader. I have about 10 for the things I use often, and if I find myself pulling up commands from Alt+X (mapped to space x) regularly, I add that to a new leader mapping.
Use-package is really convenient to learn for setting up your config.
Other than that, the things I find I can't live without:
* Ivy/Counsul * Company * Flyckeck * Flyspell * Evil
If you take a look at spacemacs's GitHub, dive into their "layers" and pop open the packages file for any given layer for inspiration of other things to add for your desired languages/features. But integrate then yourself given the packages' instructions. You'll be far better off knowing your setup intimately than learning to skim the very large surface area of spacemacs.
[+] [-] leef|9 years ago|reply
It has sane defaults and contextual tips that help when you're getting started (and can turn off later).
[+] [-] grandalf|9 years ago|reply
Some of it has been subsumed into newer emacs releases.
In general, find out which modes are considered best for whatever you are doing, install them, and then learn how to modify the configuration file to customize how the rest of the UI works.
[+] [-] auganov|9 years ago|reply
[+] [-] bitexploder|9 years ago|reply
The text editor, the extensions, and elisp. Pick a use case you really want to get into (Editing code in language X) and dig into that one use case first. Or taking notes (Learn Org mode). But pick just /one/ use case to start your practice.
Learn the editor:
https://www.gnu.org/software/emacs/manual/pdf/emacs.pdf
Work through it up to chapter 9. Practice each command. There is (mostly) a rhythm. Memorize and emblazon the "describe key" shortcut into thy mind. Clear your mental desk and just do it for 30 minutes. It really isn't that bad, you just have to give it a little time and practice.
Packages / Modes: There are a few packages in Emacs that are life savers. Get melpa working. Install and learn helm. Helm provides a completion buffer system for things like file selection and and commands. Helm is that /one/ thing I can't live without for extended Emacs usage.
Learn Lisp: If this is going to be more than just a toe in endeavor, you need to learn lisp. When you learn the rudiments of elisp and build a couple of small modes or extensions for yourself or customize existing modes a little so many things about emacs just "click". Want to bang out some quick math or do a quick base 64 decode? An example document:
''' This is a document where I am thinking.
Oh, I needed to do some quick math:
(- 2017 1980)[C-x e] -- result appears in Message area. '''
Things and concepts not to miss:
CUA mode / block selection, macros (very easy and nice), regions, buffers, point, mark, registers. Things you might not think much about: The kill ring. Learn and read about the kill ring.
Final thought:
M-x = never remember all the shortcuts again. With helm doing fuzzy matching you only have to remember much easier to remember english names for things. Naming is consistent for modes too, so to start searching for "what was that Org mode shortcut?" Start typing 'org pro' oh yeah, org promote! [Whack enter] indents a sub tree in my notes. Then I usually remember the shortcut from there out because it is shown on the commands. M-x along with describe key are life savers as you can go from shortcut to function name and function name to shortcut and you can lazily search through commands and buffers. Helm makes buffers easy.
To summarize:
1.) Learn the editor Emacs and focus on editing on specific type of document (Markdown, Org, programming language). Follow whatever popular setup guide you find for document type X.
2.) Learn the extensions Emacs. Helm is a must-try.
3.) Learn elisp and get used to the idea you are in a giant lisp machine. Running lisp code /anywhere, anytime/ in your documents is awesome.
4.) Learn the little tips and tricks.
5.) Use evil mode if you must, but I have found being fluent in Emacs is great (iPython, for example, is very Emacs biased in its readline / shortcuts). Tons of other tools (mutt) will go with vim like bindings, so taking the time to be fluent in both means you are almost guaranteed to have the right shortcuts in your brain.
6.) I feel your pain about the shortcuts. I have it mostly down to 3: Emacs, Tmux, i3. I try to ram everything through that set of shortcuts, and then a small set of my tools I use a lot use vim bindings, and I am ok with that (mutt, mitmproxy).
[+] [-] notalaser|9 years ago|reply
Anyway, if you absolutely want to learn something else, I'd suggest going the other way 'round, really: start with something minimal and work your way up from there.
For the first 1-2 years, I think, I've used Emacs as little more than a glorified Notepad clone (in fact, I even used it with cua-mode). I think my .emacs file was barely ten lines long. I was transitioning to Emacs from nedit, an old-ish Unix editor with a Motif UI that was getting increasingly difficult to digest and kept crashing and had trouble with Unicode and man I'm old... anyway, all I really needed it to do was let me write text and paint it in pretty colors sometimes.
I then sort of picked up its features one by one, as I needed them. The keybindings came first, because it was weird the arrow keys for motion and the other keys for everything else. Then I got a larger monitor and I could fit more than two windows on it and I installed window-mode so that I could switch between windows with M-1, M-2 and so on.
(Please remember this was 2005 or 2006 or something, a 21" CRT was a big deal for me...)
That's pretty much how I picked up everything else: first big C project was how I picked up xrefactory, then xcscope. First time I had to do big merges was how I picked up ediff, and so on.
The best thing about having something as scriptable and customizable as emacs is being able to make it work exactly the way you want it. Making it work exactly the way someone else wants it sort of defeats the purpose, I mean, any editor already works the way someone else wants it.
Edit: ah, yes, to address some of your pain points:
- Remote editing: look into something called tramp-mode. It's not perfect, and I, for one, use it sparingly, but it may fit your use case.
- Weird key combinations: I'm not sure what to say other than "you get used to them". It may be worth looking into how i3 deals with this stuff, too. I no longer use a tiling WM, but when I used ratpoison, it fit near Emacs pretty well -- I bound C-t to Ratpoison's prefix key, and just didn't use C-t for anything in Emacs. But then again, Ratpoison (and its successort, scrotwm) were both written by Emacs enthusiasts, and used similar key sequences.
If you're curious about anything else, ask away :-)
[+] [-] nagvx|9 years ago|reply
[+] [-] Mediterraneo10|9 years ago|reply
[+] [-] jpfr|9 years ago|reply
Last thing I heard was that Guile-Elisp (and by consequence Guile-Emacs) is working, but very slow. That can be fixed but requires work. Also, Emacs internally uses a different string representation from Guile. This makes the transition between languages tough and some more glue is required.
IMHO Guile-Emacs is "nearly there". I.e. with just a little more work it could have enough momentum and attract developers to be on the trajectory of becoming the default elisp implementation in the long term.
Having the new Guile 2.2 VM drive Emacs would definitely improve things. And the C-codebase could become considerably smaller and cleaner.
[+] [-] AlexeyBrin|9 years ago|reply
Until Guile will work natively on all major operating systems, I see no future for GuileEmacs.
[+] [-] grey-sunshine|9 years ago|reply
[+] [-] gkya|9 years ago|reply
[+] [-] cubano|9 years ago|reply
Isn't that so 1990's?
Please I mean no disrespect...I was first exposed to EMACS in the late 80's if I remember correctly and have followed it's growth over the many years since, but I can't help but feel that introducing non-blocking threading is something that should have happened long ago.
[+] [-] reilly3000|9 years ago|reply
[+] [-] xmonader|9 years ago|reply
[+] [-] orschiro|9 years ago|reply
[+] [-] systems|9 years ago|reply
[+] [-] lottin|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] microcolonel|9 years ago|reply
Nonetheless, very happy with it once I put in my relatively small config.
[+] [-] jaccarmac|9 years ago|reply
[+] [-] ajross|9 years ago|reply
[+] [-] sfilargi|9 years ago|reply
For new users and people who run emacs by mistake or to just check it out maybe?
But I agree with you, these days disabling toolbar and menu bar is my first action when configuring a new emacs environment.
[+] [-] mjw1007|9 years ago|reply
[+] [-] adtac|9 years ago|reply
[+] [-] gkya|9 years ago|reply
[+] [-] yjftsjthsd-h|9 years ago|reply
I get that you meant it in comparison to 230k, but in the modern world I find it hilarious that a 930k website is being called (essentially) heavy. If only...
[+] [-] bobsam|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] agumonkey|9 years ago|reply