 One of the most common questions I get is, hey DT, why did you choose Emacs over Vim? And you see this all over the internet. You see a lot of Linux YouTubers and programming YouTubers, you know, making videos about Vim versus Emacs, and the ones that use Vim, they can't get Emacs. They don't understand it. They're really not sure even what Emacs is as part of the problem. That's why the question keeps coming up, hey, I'm a Vim user. What are the benefits of using Emacs? Why would I leave Vim for Emacs? What does Emacs bring to the table? Especially after I spent all this time working on my Vim config, I've got all of these plugins that I've installed, and I've really turned Vim into a proper IDE, and it's really working well for me. So why would I bother learning Emacs? Now naturally, people want to know, what can Vim do that Emacs can't, and what can Emacs do that Vim can't? Well, let's get this out of the way right now. 100% of everything that you can do in Vim, you can do in Emacs. It does not go the other way, though. Emacs does a ton of stuff that is just not possible within Vim, because they're not even the same kinds of programs. Vim is a text editor, and it's a text editor that has to run inside a terminal emulator. But that's not what Emacs is. Emacs is something much, much more, because yes, there's a text editor to it, but you also have all this other stuff built around it, like org mode, and MAG it, and even video games, and things like that, and you know, it's really a complete environment unto itself. It's this complete environment that can do anything you want. As long as you speak the language of Emacs, which is EmacsLisp, or ELisp. So if you know a little ELisp code, Emacs is the ELisp interpreter. That's actually what it is. It's not a text editor, it's a ELisp interpreter. You write a piece of code using ELisp, Emacs interprets that code, and that's why Emacs has so much stuff available for you. That's why Emacs can literally do anything. You can imagine anything you can dream and write it in ELisp, Emacs will run that for you. Now in contrast, VIM is not an interpreter for a proper programming language, right? VIM, again, is just a text editor. Yes, it has an extension language built on top of it, so you can write some plugins to extend VIM a little bit. But at the end of the day, it's not nearly as powerful as what Emacs with ELisp can be. Now I think one of the reasons so many people on the internet are constantly asking this, what can Emacs do that VIM can't kind of question, is that nobody really understands Emacs. Nobody gets it. And I mean nobody. Unless you've actually used Emacs and I don't mean use Emacs for a day or a week or even a month, you actually have to spend a minimum, in my opinion, of six months with Emacs to even understand what it is, because it's kind of like the movie The Matrix, where Morpheus is trying to explain to Neo that nobody can be told what the Matrix is, you have to experience it, you have to see it, that's the same thing with Emacs. I could try to tell you what Emacs is, but until you actually live in that environment, you know, you live in it for a little while, and one day the light bulb goes off, you're like, oh, I get it now. So no one really gets Emacs on day one. It's impossible. I switched to Emacs in late 2019, so year and a half, two years ago, nearly two years ago, and for me, I would say it took about six months for me to finally say, hey, I understand Emacs. As far as I understand what Emacs is, I don't understand everything about Emacs because it's impossible to understand everything about Emacs because you can do practically anything you can imagine with Emacs, therefore, you're never done learning Emacs. That's another thing, you know, there's a steep learning curve with Emacs. But you know, initially, I thought that it was just another text editor, you know, a drop-in replacement for Vim. I think that's what everybody thinks it is, and that's not what it is at all. The more I used Emacs, the more I started to discover all of this truly amazing stuff that you can do inside Emacs, besides editing text, right? The more you start seeing Emacs as an entire ecosystem into itself, you know, and this is the part that potential new users just, they don't get, they can't get at first. You know, again, you're not going to understand this on day one. When people say Emacs is a complete environment, a complete ecosystem, you still don't understand that until you live in it. You know, by contrast, Vim is very easy to learn. You can pick up Vim, you know, in like 30 minutes, right? You can run through the Vim tutor and have a basic knowledge of everything that Vim has to offer, you know, within 30 minutes, as far as the really basic stuff with Vim. You're not going to understand anything about Emacs for weeks until you've used Emacs. And that's part of the problem. You see people, especially I see YouTubers making videos, hey, I'm going to try out Emacs for the very first time, whether it's GNU Emacs or Space Max or Doom Emacs. You see dozens of these videos, hey, let's try out Doom Emacs. And then that person does a live stream and they don't understand anything. And they think, well, this has to be the worst piece of software ever because I don't understand anything. What they don't get is there's no way they could understand anything, not on day one. It's just not possible. Now if you're a Vim user and you're wondering what Emacs has to offer, I think showing you is probably better than trying to tell you. So let me go ahead and open Emacs. So this is Doom Emacs. And what you're looking at here is a package called Dashboard. Now Emacs has packages rather than plugins. So Vim has plugins that kind of extend Vim. But Emacs has packages because Emacs has a package manager that manages all the stuff that runs inside Emacs because remember, Emacs is more of a complete environment rather than a text editor that you extend. And what the Dashboard here is showing me is some of my recent files that I've edited is showing me Agenda for the week as far as my to-do list that I've made inside org agenda, bookmarks, I don't have anything bookmarked projects. So these are project directories that I've worked in here. And then the register here is a text that I copied to the register for a copy and paste. Now let me go ahead and I'm going to hit R on the keyboard here to go to recent files and I'm going to open the very first one, which is my Xmonad config. But this Xmonad config is not a Haskell document. It's actually an org document because the great thing with org mode is you can do literate programming with org mode. Now what is literate programming? Well, org mode is really kind of an outline utility. If I do shift tab here, you know, I can actually fold the org document completely where, you know, the top level headers, they have now been folded. If I wanted to unfold one, what I could do is I could go down to about this config here and I could hit tab to unfold it, tab again to fold it back. If I wanted to unfold the whole document, I do shift tab a couple of times to unfold the whole thing. Now this, even though it's my Xmonad config, is actually titled readme.org because this is actually the readme file when you go to my Xmonad directory on GitLab. This is actually the readme that you guys see on that page. Well, how is the readme also my Xmonad config, which should be Xmonad.hs? Well, here in the header of the org document, let me make the font bigger here. I'll toggle on big font mode here in do me max. And you see the second line here, the property line, and you see header-org space colon tangle Xmonad.hs. What I'm saying here is header-orgs. What I want you to do is I want you to run the tangle program inside emacs. And tangle basically what it does is it takes the source code blocks of an org document and takes the output and writes it to another file. Where do I want it to write it to? I want it to write it to Xmonad.hs because that's the name of the proper Xmonad config. So what it's going to do is it's going to take these Haskell source code blocks that you see here, begin source Haskell, and that's proper Haskell right there. That's the import section of my Xmonad config. And what it's going to do is it's going to take that source code block and it's going to write that entire source code block to a file called Xmonad.hs. And it's going to do that for every single source code block in this org document. So that allows me to write the Haskell code for my config and it gets placed in the proper file. But then I can still in the org document do a proper outline and all of this stuff that's not in the source code blocks. So the outlining, the bullet points and everything. I could write lists. I could have tables. I could even add thumbnails as far as images. I can have all of that stuff. That stuff is just treated as comments. That's why the readme.org is also my Xmonad config as well as a readme. And when you do that, it really saves a lot of time because you don't have to write two different documents, right? You write one document, it outputs some of it to a second document. And once you get into this literate programming stuff, you start writing everything in org mode. And that's kind of what I've started doing. Now let me go back to the top of this org document. And I'm going to fold it again just for sake of readability. I'm going to unfold the about and show you guys this here. So in this, what I'm doing is I'm adding a screenshot, a thumbnail image to the readme here. So in the about section of the readme on my GitLab, you actually have the thumbnail image that gets displayed here. And that's what all of this is. And if I wanted to actually look at this image inside Emacs, I can because Emacs is a graphical program. It's a GUI program. It's not a terminal program. That's why you can have variable fonts inside Emacs. I can have varying font faces and font sizes. You can't do that inside a terminal emulator. It's impossible inside a terminal emulator. That's why it's impossible to have that inside Vim as well. But in Emacs, you can have that kind of stuff. You can have images. If I wanted to view that image, I can just click on it right there with the mouse or if I had the cursor on it, I could have hit enter and it opens the image in a split. If I wanted to quit out of that split, I just hit Q on the keyboard and no big deal there. If I wanted to follow one of these URLs, like if I wanted to go to my GitLab, I just hit enter right now. And it'll open that inside the web browser inside Emacs, which is a program called EWW, the Emacs web browser. And if I wanted to, you know, I could actually view my GitLab here. It doesn't look quite right there. Doesn't look like it really loads that page well inside EWW. And of course, I've got all the source code blocks being outputted to xmonad.hs, but I don't have to do that. I mean, I could have them output to anything, really. So let me unfold this again and I'm just gonna go to a spot here and let's just play around with this config. I'll undo everything later because it is my proper xmonad config. I don't wanna mess it up too much, but let's create a new headline here. I'm just gonna say test. And let's do some source code blocks. So how you do a source code block in org is you do a less than sign S for source code block and then tab, and it completes that for you. See, begin source, and then the source code block of course needs to know what kind of language it needs to interpret in the source code block. So, you know, Haskell, of course, for my xmonad config, or I could do a bash or sh for POSIX compliant shell or Python or whatever. Let's do some emacs-lisp. So let's write some elisp code because that's one of the most common things you're going to do with org mode inside emacs, especially once you start configuring emacs, right? You're really gonna get into elisp. So let's do a simple hello world here and this is very easy. Just do inside parentheses. Everything is a parentheses in emacs list. It's a million parentheses, but do inside parentheses message and then inside double quotes do hello world. I'll even add a comment and an exclamation point. And then once we do that, if you wanted to evaluate that, what you could do is ctrl-c, ctrl-c, and you get the results printed right here in the org document. How cool is that? So we get hello world as the result. That's pretty neat. I mean, if I wanted to change the source code block, you know, that's cool maybe with the exclamation and then let's evaluate it again with ctrl-c, ctrl-c, and you see the results just changed for us, right? Now I mentioned that you could have tables inside of org mode. So let's create a table. You create tables with the pipe symbol. Pipe is the separator in the table. So maybe I wanna do, that's, you know, it's a tiling window manager config. So maybe I wanna do keybindings and then a pipe symbol and then let's do keybinding and then how about description and then pipe symbol and other than the keybindings and the description maybe, I don't know, other stuff. I'm not really sure what this table is gonna be. And once I get to the end of this to really make it a table, I'm gonna do ctrl-return and we get another line with more separators. Now, if I wanted to, I could go to the beginning of this and get it into insert mode and start typing more stuff tab, more stuff tab, more stuff tab and it automatically sizes everything correctly. It auto resizes the table no matter what you do inside org mode and it's really fantastic. If I wanted to add a border because typically you want some kind of separator between the very top row of the table and the rest of the table and do me max, at least, I know I can do something like, I think it's space MB dash, yeah. And that adds a separator as part of the table. So really cool stuff there. Now, one of the really cool things you could do with these source code blocks, now I'm just having the output written to other files but what you could do is because it does print the results right here in the document itself, it makes blogging especially. If you do any kind of blog where you're doing programming related stuff as part of a blog where you're showing source code and then the results, typically you'll write the source code and then you gotta figure out the results on your own and then put that in the blog. Well, you don't have to do any of that if you write everything in org mode. You just write your source code blog and it'll print the results right there in org mode and then you can actually export to HTML. Actually you can export to a million different things here inside Emacs. If I do space ME for the org mode export tool, you see I have the ability to export an org document to a million different formats. Right now I can export to MAN. I can do PDF. I can do iCalendar, Gemini, HTML, LaTeX, Markdown and there's many, many other org export extensions I could install if I wanted other thing or if I needed the ability to export to other things. And what this does is the org export utility. It utilizes Pandoc. Pandoc is actually a Haskell program that is a document converter. It converts documents between various formats. So I've gotten in the habit of writing all of my configs in org, including my DOOM Emacs config. If I do search for my recent files and let's search for DOOM config.org. So config.org is my DOOM Emacs config. There it is all folded and unfolded completely. So I got a table of contents here. And one of the cool things here, let me go back to a normal font size is because again, because Emacs is a GUI program, a graphical program, you can have varying font sizes. Everything doesn't have to be the same font size the way you're forced to have everything the exact same font size in a terminal. For example, maybe to make these top level headers really stand out, I could make them a different font size. So let me show you how I would do that. What I would do is, you know what I'm just gonna add a source code block here and it needs to be Emacs Lisp. And in the source code block, I'm just gonna paste this here. What this does is it sets various org level headings. So you have top level headings, level one, two, three, four, five, and they're all set to height one dot zero, just the normal font size. I'm gonna make the top level headings though, 1.2, just to make them slightly different. I'm gonna do a colon W to write and then I'm gonna do space HRR to reload DOOM Emacs. And we wait a second and here in a second, yeah, a terminal is gonna open in a split. That's one of the built in terminals of Emacs. It's gonna rebuild DOOM Emacs for me right here. I didn't have to leave, you know, Emacs to go do this. And it says config successfully reloaded and look at the top level headings now inside org mode. They are slightly bigger than the rest of the text on the page and that really is useful. I mean, immediately these headers inside org mode stand out and you could do the same thing with markdown. You could do the same thing with your LaTeX or your GROF, especially with things like LaTeX and GROF where some of the headers really don't jump out at you because there's a lot of weird kind of syntax to those particular markdown languages. Being able to manipulate the text, have different font faces, italics, bold. You can't really do that in some terminals. Some terminals allow you to have an italicized font and a bold font, some don't. No terminal is gonna let you run more than one font family though. That's just not something that's allowed in a terminal. But you can do that inside Emacs. One of the cool things with Emacs is that you can always evaluate any piece of Emacs Lisp code. So any E Lisp code, like on the org mode, it's obvious because I write the source code blocks and you know it's evaluating it, especially when I reloaded my Doom Emacs config. You can tell it's reading that and we get the results right here in front of us. But if I wanted to, I'm gonna open up a second Doom Emacs window and I'm gonna do space B, capital B for my list of buffers and I'm gonna go to the scratch buffer. This is just, think of it as a scratch pad. It's just here for you to write whatever you wanna write in and one of the common things people do with the scratch buffer is you write E Lisp code and then evaluate it. So if you wanna see if it's a proper piece of code, so if you didn't know that this was gonna work, for example, you just wanted to test it out, let's do message hello world one more time. And let's go ahead and turn on big font mode one more time too so you guys can actually see this. And what I could do is I could go to the very end of this particular line here and I could evaluate this function here and what I could do is I've got a binding space E L that will actually evaluate that for me and actually returns hello world right here in the scratch buffer. If I hit another key, it goes away. I wanted to try this with something else so I could do inside parentheses plus plus is a function and that function takes two arguments. It's gonna take an argument of two and another argument of two in this case. If I go on the last parentheses and do space E L one more time, I get four. Now that space E L is my custom binding I set to that and that is for, I believe, the aval s expression aval dash last dash s expression. I think by default in Emacs that's usually set to control X control E. I think that's the default GNU Emacs key binding for that. I could be wrong on that though. So we've seen E list code evaluated inside org documents. You can evaluate it inside a scratch buffer. If I really wanted to, I could evaluate it inside the E shell which is Emacs's own shell kind of like bash or ZSH except E shell of course is written in E list and it can evaluate E list. So if I wanted to, I could do a meta X right now and do E shell and hit enter. This launches the E shell and if I wanted to do something I could do plus two and two again. I don't need the parentheses. At least I don't need it. If I was nesting stuff with parentheses I would need those but I don't need the very outside pair of parentheses. So plus two and two returns four. If I wanted to test if something is equal I could do equal four and four and that should return T. T is true. So you have T and nil for true and false by do up arrow and equal four against five. You see nothing is returned. That's nil, that's an empty set and that means this is actually false. Probably the biggest area where Vim and Emacs differ is that Emacs is self documenting. Everything you can want for documentation. Everything from every key binding, every variable, every function, everything has documentation readily available to you at all times inside Emacs. All you need to do is do meta X for the command prompt and inside that type the word describe and you're gonna see several describe kind of functions. The most common ones that you're gonna use are describe variable and describe function. They have key bindings by the way. Space HV and do Emacs for describe variable. Space HF for describe function. So let me do space HV for a variable and say it's gonna be a million variables in this list that Emacs knows about. I have a program called council installed in my Emacs and it's council. Let's look up one of the variables associated with the council program. I'm gonna look up council alias expand. I don't know what that is. I don't know anything about it but we can actually look at the documentation. It opens in this bottom split here. It'll make that a little bigger and you notice again because Emacs is a GUI program. Some of the font sizes are bigger for the headings than actually the descriptions themselves. That's really nice. It's really easy to read this stuff too. Just the font rendering inside Emacs is amazing. Good Unicode support too. Good emoji support if you guys are interested in stuff like that. And of course all the links here we can actually click on it and it will follow that link. It'll actually council.el is the name of the program that that variable is found in. When I clicked on it, it opens council.el, the program here inside the top split. That used to be my doom config. Now it's council.el. So I can read the source code for that. I can edit the source code for that and then I can space HR again to reload doom Emacs. I can see my changes take effect. And that's really when you start realizing how infinitely hackable, how infinitely customizable Emacs is. Now one of the most common questions people ask us about all the key bindings inside Emacs. How can you learn those? Or doom Emacs in my case, you know I tell people doom Emacs is great and then they go install it and they don't know any of the bindings. It's like, where do I find all the key bindings? Remember Emacs is self-documenting. If I did meta X and I did describe and I think it's bindings, yeah, describe-bindings. Doom Emacs has it actually with a key binding already space HBB. Let's use that space HBB for describe bindings. And it will list every key binding that is available for you, right? With every single key binding. I don't think people know that's there because again, and that's one of the most common questions I hear from you guys is I don't know the bindings. Where do I get the bindings? But you don't even have to use describe bindings to list your bindings. What's really weird when I see people trying out Emacs for the first time, not GNU Emacs, but things like doom Emacs and space max, every version of Emacs, every customized version of Emacs, almost everybody has which key installed. Which key is a package that tells you the key bindings? So if you're wondering what key bindings are available inside doom Emacs, I'm gonna do space because most key bindings inside doom Emacs involve the space key. So if I do space, which key pops up? And it lists the next possible keys and what they would do if I hit them. So if I did space and then I did S for search, let me do S. So right now the key binding has started with space and then S and then it's telling me what the next key in the binding possibly could be. So maybe space S, B for search buffer. And then what do I wanna search inside the buffer? So that's how you get that, let me get out of that. And we've talked about org mode being a killer feature for Emacs. Maggot is another killer feature. Maggot is the built-in Git client in Emacs. So let me open up DeerEd, which is the file manager here inside Emacs. So let's open up DeerEd. Let's go to, I'll go to my home directory. Maybe I wanna go to my GitLab repositories. I have a folder called GitLab-Repos and let me hit enter in that. And then I wanna go to, well we'll go to DWM-distroTube. Let's see if I have any unstaged changes in this. This is a Git repository. So if I do space gg that launches maggot here in doomimax and you can see in this Git repository all the untracked files that are in that folder and then the unstaged changes. So I've made changes to the config, the config.def.h but I haven't actually staged them or committed them yet. Now if I wanted to actually read the changes, the diffs, what I could do is do a tab. I could see the diffs. I can see what I changed. I changed some key bindings. I could tab again to not read that. If I wanted to go ahead and read recent commits, I could go down here. I could tab on that. If I wanted to read one of the commits and I like this one here from a few days ago where I was updating the package build, I could actually hit enter on that. I could read the commit on that. If I wanted to quit out of that queue to quit out of that. If I wanted to get rid of the recent commits, go back to the header, hit tab on that, folds it back up. Now if I wanted to go ahead and stage this config.def.h what I could do is just get on that particular line, hit S for stage and now instead of unstaged changes, you see I have staged changes. Now, if I didn't want to stage that, I made a mistake. I could hit U for unstaged or S again to stage. If there were several things in the unstaged list, capital S stages everything in the list, capital U unstages everything in the list. And now all I need to do is actually make a commit. I'm going to hit C on the keyboard for commit and then C again, one more time for commit. And I get this information here. I could go ahead and start typing my commit message. My commit message is edited the key bindings for DM scripts. And then once I'm done with that, I'm going to hit escape to get into normal mode. What I'm going to do is I'm going to do control C, control C, control C, control C, so twice. And then that's it. And that was staged. It actually exited out of the MAG it though, but it says get finished. Now it actually isn't finished because we never pushed it. So I actually need to go back. So let me go back into here and once again, go to my get lab dash repos DWM dash distro to repository there and hit enter space GG to get back into MAG it. And from here, we've already staged everything. All I need to do is P for push and P one more time to push to the master branch and then hit enter for origin. And I've already got SSH key. So I didn't need to enter a username or a password. And that's it. I just pushed those changes to my get lab. Honestly, once you start using things like org mode and things like MAG it, you start understanding what you're missing out in VM because there's nothing that compares to MAG it. You will never, you won't even open a terminal and start using get like the command line version of get once you start using MAG it because it's just so easier. It's just so, so much faster. You know, everything I did there with the tabbing to view the diffs and not view the diffs and everything, you'd have to actually do quite a bit of typing to do what I did in just those few seconds inside MAG it. So in my opinion, ultimately, I think what all the criticisms from the Vim users out there, what all their criticisms boil down to essentially is Emacs is hard. I think Emacs is too hard for me to use. Now they don't say that. They say other things. Emacs is bloated. Emacs didn't follow the Unix philosophy. Emacs is this, Emacs is that. You know, because it's embarrassing to say, I don't want to give Emacs a try because I think it's hard and I think I'm gonna feel at it. You know, that's embarrassing to say to other people, but I really think that's what most of the criticisms actually kind of boil down to is because, you know, there's a learning curve and it's a very steep learning curve. I'm not even gonna lie. There's a lot to learn with Emacs. There's so much more to learn with Emacs than with Vim, all right? There's a absolutely, there's an orgy of documentation of Emacs. Yeah, I showed you all the described commands and everything. Like you could actually go blind reading all that documentation. And people hate too much documentation. People hate no documentation too. The thing I hate the most is trying to find documentation on something and there's none. But also people hate being overwhelmed by documentation for a complicated project. And that's what Emacs is. There's a lot to it. So it's complicated and there's more stuff to read about Emacs than you'll ever read in your lifetime. And I know this rant and this video is gonna be a lengthy video. I don't know how long I've been recording now so I'll shut up. But hopefully, I don't know. Maybe you guys, you Vim users, you're thinking about trying out Emacs. Maybe you'll glean some kind of knowledge from this video. Maybe I showed you a little bit that maybe you didn't know before. Now before I go, I need to thank a few special people. I need to thank the producers of this episode. Absigay Mitchell, Akami Allen, Chuck David, Dylan Gregory, Erion Paul, Paulie Tech Scott, Steven Smith, Wes and Willie these guys. They're my highest tiered patrons over on Patreon without these guys. This episode you just watched, it wouldn't have been possible. The show is also brought to you by each and every one of these ladies and gentlemen as well. These are all my supporters over on Patreon because I don't have any corporate sponsors. I'm sponsored by you guys, the community. If you'd like to support my work, look for DistroTube over on Patreon. All right guys, peace. Oh, I forgot to show Tetris in Emacs.