Excerpts from Sacha Chua's Emacs Chats
Emphases mine.
Carsten: The point when I really found out how amazing Emacs is, was when I discovered the calculator.
Sacha: Yes.
Carsten: At the time, I was working in America at another institute. They had this great set up, because this was an institute behind a fence, so everybody who was in there was completely security-approved. Inside, everything basically was easily accessible for everything.
For example, they had a printer queue there. You could just take a document and print it to that queue. At the next morning, this thing would be bound as a book on your table.
Sacha: Wow.
Carsten: Or you could print images to a slide printer, and they would make slides out of it and just put it back on your table. That was really fantastic.
I used that to print a couple of manuals. I was just casually looking at a Calc manual and then printed it. It came back like a pile this size. It was this gigantic book. It totally sucked me in. I took this book and I read it over the weekend, from the first to the last page, the entire book, because I thought it was written so amazing.
Sacha: It's hilarious.
Carsten: Yes. I started reading the code which is amazing. Everybody always says that codes should be documented, it should have lots of comments, it should have documentation things. Well, you would be amazed. I don't know if you have ever looked at the code of Calc. There are no comments in there, there are no documentation strings for most of the functions, but you can still read it. This amazed me so much.
It told me that a person who has enough clarity in their head when writing code, they even can make code readable without putting a lot of extra commands and documentations. So it was really amazing. I totally fell in love with this program and just started studying and using it. I'm using it to this day.
It's such an amazing marriage of two worlds. On the one hand, he has made this –– he started out–actually maybe just a little detour, if you read his introduction toward the manual or to the tutorial, he said that he was just trying to write this in order to find out what – I don't know, whatever it was, 2 to the power of 10 or 32 or so – he couldn't do this on a normal calculator, so he wanted to do this. He chose Emacs Lisp, because he decided this is just an editor extension language, so he would truly hit a wall very soon, and then this project will be over. It never did, apparently.
On the one hand, he implemented this amazing functionality. It's like a poor man's Mathematica. It's of course not as good as Mathematica for complex stuff, but it does 3-D matrix operations, it does some analytic operations, integration, differentiation… All implemented there. And it was written in a time when Emacs didn't even have floating point numbers.
Sacha: Wow.
Carsten: It only had integers. He implemented arbitrary precision integers with lists of numbers and he implemented arbitrary floating points calculation with this thing. Today, I think Calc has not been re-written to make use of the internal floating points. All the floating point operations are actually hand-implemented. It's crazy. There's all this complex stuff in there.
But on the other hand, he keeps the simple calculator interface. If you use Mathematica, for example, then you have to type all these commands. That's just a lot of typing. The commands you're putting in are complex. While with the Calc calculator in Emacs, it's still you press a key and you get an action, just like you have it on a calculator.
You press the logarithmic key, and logarithm will be calculated. In Calc, it's usually two keys. Usually, it's sort of a category key like arithmetic or matrix or so. Then the second key for the command. It's extremely fast.
It has the best way to work with units of numbers. I'm an astronomer so we deal with big numbers and having the right units ready… when I sit here with my students, very often they come with something with an idea or so, and then I just turn around to my Emacs and make a little estimate using the unit calculation facilities. It's really the fastest and best way to do this. I totally love this.
I have an iPad. The one reason why I hate is that I cannot have Emacs on it just for the calculator. This is how good this program is. It's amazing. I always have the feeling it's not known well enough. This is why I use this chance to make a big advertisement for it, because it's an amazing program. It's really mind-blowing.
Carsten: Yes. Magit is really good. It's also because of the integration with the change log entry creation and stuff like this. That actually that may be interesting. If you write an Emacs package will be part of Emacs, Emacs of course requires you to produce changelog entries in the right form at hand. So you have this special changelog file which you have to do. For really a number of years, we basically had to do double bookkeeping in Org Mode because we had a version…
Sacha: Yes. I heard about that recent mix, the recent shift.
Carsten: We had a versioning system, and then we are still keeping all these changelogs. Even worse, when it came towards release time, I would actually go through and look at all the changes, and then sort of more or less by hand, produce all those changelog entries. Sometimes I would only produce half and hope that the Emacs maintainer wouldn't notice.
That was really terrible. And the way we do it now is we only use Git. No changelog files. We just enforce that the description of the change in the git commit message has to be formatted in a way that it will work as a changelog entry. And then in the end, at release time, we just have a script which uses Git to extract all the things and put them into a changelog file. This is really a very simple solution but very effective.
Carsten: Yes, that is possible. The table editor, I think, needs a rewrite. I've looked at that code recently because there was a bug report. I wasn't able to fix this bug because it was so convoluted and hard to maintain. There's this one thing which I think is great in Emacs and which I have used too much sometimes. In Emacs, if you have dynamic scoping, you can basically write a let statement and assign a variable, make a variable and assign a new value to it, and then call some other functions. In this way, you change the background in which this other function will work. It's not a parameter which you actually hand to that function, but it changed the background, and then you can make it something crazy. This can be really powerful, but of course, also dangerous, because it reduces maintainability if you use these hidden ways of communicating to another function.
Sacha: It's actually really helpful. I've been using it to study for various tests as well. I used to use Flashcard before. Flashcard.el did that kind of spaced repetition too. The nice thing about Emacs of course is you could hack things around. With flashcard, I'd set it up to show me a fortune cookie every time I got something correct. Then once I had gone through the entire fortune file, I think I had it set up to show me cute pictures of kittens from Cute Overload or something like that.
Carsten: That keeps you motivated.
Sacha: Yes. Emacs is an eminently hackable thing.
Carsten: You know what my prompt is on my terminal window? It's, “Sir?” Like an English butler, it would ask you what to do next. I like this kind of attitude of my computer towards me, to just stand there, and wait, and then do exactly what I want. That's how it should be.
Sacha: It is very tempting to just spend all of that time customizing Emacs and looking at other people's stuff, writing all those little hacks for your packages or whatever. But it pays off because then you don't have to think about it so much. You just work the way that you work.
Carsten: Yes, exactly. There are days where you have to self-censor and stop yourself. But normally, I agree. I just use this stuff in downtime when I couldn't really do something else otherwise anyway.
Sacha: As you said, it's your form of relaxation.
Carsten: It totally is. It's my hobby. Like other people would knit or something like this.
Bastien: Yeah. And somehow I feel like the Emacs is a nice tool for doing small, cheap prototyping. Are you using it for that? If you have something in Ruby that you know is big, do you start prototyping with Emacs with small functions or even for web development with bigger constraints?
Sacha: For personal use, definitely. I have a lot of these scripts that start off as Emacs Lisp functions, because I like being able to use buffers and regular expressions, search forward, and all these other little things. Sometimes I never end up turning them into a shell script or something else. I'll use keyboard macros or write small Emacs functions just to do something. Sometimes if I've got a good idea and it works out, then I'll go and write it up as an actual script that other people can use.
An Emacs-type editor has advantages as an app platform. Creating apps for other platforms takes quite a few man-hours, whereas it does not for Emacs. So if someone comes up with something that hasn't been done in Emacs, it can be recreated by one person in a day. The opposite process has often happened, i.e. ideas start out as Emacs apps, then become apps on other platforms. The creator of Anki first made flashcard.el, which means that Emacs had flashcards very early.
Mickey: What you can also do is C-M-t, which transposes the entire s-expression, and that does it like that, by swapping the s-expressions around. Not terribly useful here, but if you go back and then do M-t, you swap the whole thing. This is one thing that… You can sit down and learn the rules, but I find that just trying to use it over and over again in all kinds of different circumstances until you mentally map it is perhaps easier to do.
I can type C-M-u for control meta up and it jumps to the top. If you then combine it with C-M-k, the control meta kill, you kill the entire s-expression which is bound by the two braces. Now obviously that's quite handy. But if you're at the end of it, you can just type M– like that which is basically negative argument, and then type C-M-k. It's backward.
Mickey: That's right. That's C-SPC which sets the mark and then C-u C-SPC which jumps to the last one.
Sacha: Oh, and you might like–I found this Emacs Lisp snippet, it might have even come from you, I can't remember–but when you get C-u C-SPC and you keep hitting SPC to go back to the previous ones?
Mickey: So if you go to the command… let's see if I can… find-name-dired. What that lets you do is it takes a find command. You give it a starting directory and then you give it a standard globbing pattern. It will go through and it will get all the files that match whatever your find criteria is. Of course there's absolutely nothing stopping you from constructing a more elaborate find query with greater than sizes, and less than, and all that stuff. It basically lets you mark and add all these files in different directories. I just do it with one big unified dired session. That will in many ways replace your standard find and xargs command workflow from the command line. That's very useful.
Mickey: Exactly. But that's what I like about it. It's the fact that you'll bump into someone who may not have been using Emacs all that long. They'll show you a great trick you've never heard about. I find that really useful. That's what I like about Emacs. It's all these little things like being able to combine all these things with Dired, for instance, which is a very powerful paradigm. If you're not a master at using find, well, make slightly wider search criteria and then filter it manually using Emacs's own filtering and search routines and dired, and Bob's your uncle.
This one is useful. This one would insert the buffer file name from another buffer, insert-other-buffer-file-name, which when I run it, I'll give it (using ido) a buffer, and it will give me the full file path.
Sacha: Yes, I can see how that ends up being quite handy, especially if you're in shell.
Mickey: I do use it a lot. Sometimes I might be in the Python shell or something like that. I need to feed a file name to some function that I already have open. Instead of typing it out, I just do it like this. That's primarily what it's for.
Sacha: Re-builder lets you interactively build regular expressions and you can see what it matches and what it doesn't match in your buffer right away. […]
Mickey: Yes. It's great. It doesn't work very well in large buffers. It will actually stop placing the overlays. […] C-w, yes. You type C-c C-w and you paste it, but it will paste a Lisp-friendly version, which is quite handy if you're doing that a lot. So that's useful.
Sacha: Yes. I always end up counting slashes.
Mickey: That's the thing. By default, you can actually have a printout double-slashes so you don't have to do that yourself, which is quite useful.
Phil: The main thing people get tripped up on, I think, is that paredit will refuse to do certain things when it can tell that those operations will result in broken pairing.
Sacha: The number of times I've hit C-q )!
Phil: Right, yeah. It's trying to set you on the right path, so it does that by just making sure that all the operations it does are protected. Every time you insert a paren, you have to insert a matching one. Every time you kill, you can only kill up to the end. Otherwise that would leave your code in an invalid state. As long as you limit yourself to the commands it knows about, it provides this guarantee. C-w (kill-region) is not one of those commands, so you have to train yourself to avoid that. When you use kill-region, you're saying, "No, paredit, I know better than you," which is usually not the case. But once you've internalised that, you end up working on a higher level where you're not thinking in terms of characters any more, but in terms of expressions. You're saying, "I want to kill this whole string or this whole form", not, "I want to kill from this point up to this point". It's higher level commands, I would say. Especially people who are new to Lisp, they think this is so intimidating, seeing all these parentheses everywhere. If you have paredit on, it's… it does take some adaptation, but it's no additional mental overhead for you. You're changing the structure directly.
Christopher: There's a barrier for me to learn new programming languages. This touches on Skewer mode. Before I get into a language, I want to have a workflow set up in Emacs the way I like it. That's how Skewer came about. I need to learn JavaScript and web development, and I need to find some workflow in Emacs to make it work. I looked at swing.js and it didn't quite do what I was looking for. I ended up writing Skewer mode while I learned JavaScript.
Sacha: Let me see if I understand this correctly. You want to learn JavaScript, so you developed something in Emacs that talk interactivity using JavaScript to a browser, ending up writing however many lines of code in JavaScript to communicate with the Emacs process.
Christopher: Yes.
Sacha: In order to learn JavaScript?
Christopher: Yes. It's part of learning. A good exercise too.
Magnar: I think that's the best way of learning Emacs. Sitting down with someone who really knows it and well then you can just ask anytime you're stuck. “How do I save again?” “Well, it's CTRL+X, S, Enter”. And that's it. You don't have to read up or look somewhere else. You can just move on.
Sacha: Wow. It's really helpful to have that kind of side-by-side and also when they're watching you do something, you're doing it the way that you know and they're like, “No, no, no. You do it this way!”
Magnar: Yes, exactly.
Sacha: Keyboard shortcut or some tool. Yes.
Magnar: Yes, that was really fun because at first, or maybe the first week, it was just learning how to do basic stuff. But then we got into a cool game which was … if we did something that wasn't really efficient, we did it in a stupid way, the other one will say, “Hey, you should be doing some macros!” And you have to undo everything that you've done. Undo, undo, undo and do it right. That is a fun game.
Sacha: I think our definition of fun is very weird but it's awesome.
Magnar: Yes.
Karl: This time, I did it better than the first time. This time, I sat down and learned about the basic principles, about the keyboard shortcuts, and how to adapt them and so forth. Not just copy and paste from the Internet, and then wondering why something is broken or something like that. I started to learn about Emacs, and Elisp especially. But I'm not very familiar with Elisp. I still have to learn a lot to understand Elisp code. For the next couple of weeks, I plan to learn how to debug issues I have with Org Mode by myself.
Sacha: Yes. I hear from a lot of people that learning how to customize Emacs through Emacs Lisp is what gets them really into it. You basically started off with trying it out, using it as a basic editor. You spent 10 years or something like that using Vim instead. Then when you found that Org Mode really fit the way that you wanted to view your personal information management, that gave you enough reason to come back into Emacs.
Janis: To learn anything and to complete any large task… For example, when you do hand-drawn animation, you should start with the first frame, and the last frame, and then one in the middle, then one in the middle between those two, and go to the precision you need. So, you can implement this idea in any other area of your life, because you can take an Org file and make simple algorithm with the main things you have to do. Then you can put more points in and more detailed tasks in those points. So you go to the level you need to complete your task.
Janis: Cool. One thing I read something previously, there was a question, some person asked in stack overflow and I bind that into one reference like a joke but which is very true joke. Emacs is the editor which makes you a better person.
Sacha: True.
Janis: It's true and people are writing their answers for him when he asked it. “Oh, will Emacs make me a better programmer?” They're writing, “No, just use the editor which does the job and which makes you very, very comfortable enough.” Yes, in some sense, but Emacs makes you think – and if you think, then you can learn very quickly a lot of software. You can see for example on the net, you are still looking, “Oh, how should it be?” I like how people are watching YouTube videos and they do not read description and asking in the first comment on the top is, “What is the name of the song?” When he could just open the description and view there.
People do not read, they do not look. How do things actually work? They do not look in the world scientifically. It's like people think moon from the Earth is that distant as it is in the book. When you show him it's like eight meters away where the Earth is like a football ball, then they do not understand.
Sacha: Yes. I learned about it through… I think it was Bastien's Emacs Chat also, or one of those. There are all sorts of interesting conveniences in Emacs packages that are hard to come across because there's so many packages now.
Iannis: It's a way to debug actually. For a while, in the beginning it didn't look like it was more pretty. I was also used to writing pretty neat files by using Org Mode. was a bit suspicious about using it. I'm trying to be [inaudible 0:30:42] and after several months of using Org Babel for init file, I still have my doubts.
But then something happened which consolidated it, and that was something strange broke inside the init file. I could use something like tangle buffer - I think it's called, org-tangle-buffer or something like that - to recompile it until I found the very block that was from. It actually stops. It goes with a cursor at the place where the block fails. This, you don't get when you compile a buffer.
I think I've got something over 50 little blocks here, 60, 70 blocks. It's quite a long file. It would have been two hours instead of 15 minutes if I didn't do it in Org Mode Babel.
That absolutely convinced me that this is the way to go. I could go through and it would stop exactly where it had the problem. There is no question, Org Babel is the way to go, especially for init files.
John Kitchin. Very impressive. He's got data animation going on inside Org Mode live, literally, from running Python.
Sacha: Yes. Edebug is so powerful. By the way, if you can't remember C-u C-M-x, it's also the same as M-x edebug-defun.
Bozhidar: Yes and we can quit of course the debugger with q. I think that it's a great tool and more people should be using it. For some reason, it is extremely unknown. Often when I get bug reports on some of my projects, I have to tutor the users quickly how they can instrument and debug that code. I really wish it was a more popular tool.
Find-function is faster than describe-function when what you want is to go look at the source. Bind to C-h C-f or whatever.
One thing that open source has taught me is that you cannot conquer everything by yourself. You have to set the general tone and hope that you get enough traction, enough support. This is the only way to create something great, because nobody can do anything by himself/herself.
Sacha: So tell me about getting that traction. Projectile is quite popular, and Prelude as well. How do you get traction for those? You come up with an idea, you put together something on GitHub, but how do you let people know about it?
Bozhidar: I used to blog about Emacs on my personal blog as well. I guess some people found out about some of the packages there. At some point, the blog was linked to Planet Emacs, which increased the blog posts' popularity. I guess every time I create a new package, I post about it on the Emacs subreddit and in the Google+ Emacs community. I obviously tweet from time to time about the things I'm working on. These are the main communication channels that I use to promote a bit. Sort of.
Sacha: Yes, you do. This is wonderful. In fact this is an excellent opportunity to point out that thing that I noticed right away when I was reading your configuration file off Github. You organize your file with all these functions. Then at the end, you call all the functions, which is an interesting pattern. In the pre-interview, you said that you had strong opinions about this, so please feel free to share your strong opinion.
Harry: Very strong opinions about this. In my day job I write Ruby all day. That's what I do. In the Ruby world, it's considered good practice not to really use comments. Instead, it's suggested that when you have something that wants commenting, you probably have a method that's too long or a class that's too long, and you should probably break that into small parts and give it some kind of useful name. Comments… People often say that comments are just lies waiting to happen.
Sacha: Yes, I can see that.
Harry: Yes. Something will change your code, and you'll forget to change your comment. Now you have this comment which is lying to you. People will try to read your comments to get some sense of your code and it'll be a disaster. If you break this up into small named methods without comments, like treat-camelcase-as-separate-words, that pretty well tells you what that function does, but it also is evaluated. If I change that, then it will throw an error at me. It will call me on it. [Inaudible] because it combines the convenience, it combines the clarity of comments with the certainty that it will never break.
In short, Harry above puts (global-subword-mode) in a function called treat-camelcase-as-separate-words. Maybe not always needed but he prefers this over writing a comment at all. I for one would just call global-subword-mode uncommented, but it's worth realizing that the defuns hardly take space – they are just defuns, and don't add to maintainability burden.