Skip to content

Mill’s Methods and System Administration

Thursday, February 2, 2012

John Stuart Mill, an English philosopher during the Victorian period, proposed several methods for getting to the bottom of what is causing a particular effect under investigation. The wikipedia article provides a helpful introduction. I first came across these in an inductive logic course (Copi’s Introduction to Logic was the textbook).

While writing this blog, two of the “See also” links at the bottom of the Wikipedia page caught my attention. The first is on the Baconian method, the second on Bayesian networks. It turns out that Mill published his methods both to popularize and extend Bacon’s work. Hopefully I’ll get some time someday to read both Mill’s and Bacon’s works. Bacon’s looks particularly obtuse, clothed in idiosyncratic philosophical language that I’ll likely need to paraphrase a good deal before I understand it.

Bayesian networks look like they take Bacon’s and Mill’s methods in a more formal direction. If Bacon is philosophically murky, the Bayesian networks are mathematically imposing, but look worth the time of further investigation. Although the math looks a little above me now, it does involve two sexy areas (at least for me) of math: probability and graph theory. I’ll try to give my experience with it when I get to it.

For now, I’ll stick with Mill’s methods and how they’ve helped me in my current job.

While the Windows system currently serving the school keeps things running well overall, there often are cryptic problems that seem inexplicable when first encountered. It seems that Microsoft had good intentions about extensive and careful error logging, but so far, most error codes I come across are too generic to be meaningful. Looking these codes up on TechNet and elsewhere on the net sometimes helps, but is still more miss than hit. Also, I’m having to deal with the electrical subsystem armed only with a smattering of memories of time spent with my electrical engineer uncle and half-remembered high school general science education on electricity. I can think of several other species of problems that don’t lend themselves to immediate solution via Google.

The biggest (technical) challenge in my job seems to lie in identifying the problem. This invariably involves understanding causes and effects–the very sort of thing Mill was interested in. So what are Mill’s methods and how have they helped me in this job? Since Wikipedia has already done a good job summarizing them semi-formally, I’ll give a more informal explanation along with examples from my job.

Method of Agreement

If you have 2 or more cases of a problem, and they all have one particular thing in common, that thing is the cause, or part of the cause of the problem.

Recently, I’ve been trying to find out why 6 computers had an error getting updates from the local automatic update (WSUS). Today I dug into Event Viewer on each of these machines and looked for any errors at all. I found that the computers all had gripes about ASP.NET not finding an IIS server. So in Mill’s terminology, these cases agree on the circumstance causing the problem. Although they each have numerous differences in software, hardware, etc. from each other, they had this one thing in common. Now I was able to search more effectively and found a simple one-liner in the command line that seems to have fixed the problem since they no longer show up with an update error.

Method of Difference

If you have two cases that are mostly the same, but one has a problem and the other doesn’t, the problem lies somewhere in the difference between the two cases.

Ok, not the best paraphrase, so here’s an example. In our computer labs, the machines are mostly the same. They are the same model, bought at the same time, from the same manufacturere, and have the same OS. When I have a problem with one lab computer, I can look at the one sitting right next to it that doesn’t and see what’s different between the two. While there are often a number of differences, it still narrows the possible source of the problem down significantly.

This method tends to be a little more powerful than the method of agreement because I sometimes find different partitions of problems when I use agreement. In my example for agreement above, I actually found that 4 of the computers had a problem with ASP.NET, but 2 had problems with SQL Server 2005. The method still worked, but I had to do a little thinking to realize I was dealing with two separate problems, not the same one.

With the method of difference, on the other hand, if I’m lucky enough to have a clear idea of where the difference lies, the problem is immediately narrowed and I can hone in more directly on the nature of the problem. I can’t really explain it, but it does seem to get results faster.

Also, the method of difference often works well even if the machines are not both lab computers and have greater differences. Although a computer in a teacher’s classroom may be a completely different model and have a different OS, they are still both computers filling very similar roles. More often than not I already know the problem lies on the networking layer and can begin by looking at differences in how they are handling DNS or if they are both pinging well or whatever. The greater the similarity between two cases, the easier it is to determine the area of difference. The very purpose of a scientist’s controlled experiment is to try to create two cases in which everything is the same except one purposely introduced difference. However, there are many areas of science where experimentation simply isn’t possible, only observation. The method of difference can still be used to good effect, just with more effort and less forceful conclusions.

A smart cookie might think about combining the methods of agreement and difference, and that’s just what Mill did…

Joint Method of Agreement and Difference

Not much to say here, and honestly, every definition I’ve read confuses me more than enlightens, so I’ll go directly to an example.

Let’s say I ended up with many different computers all over campus having a problem connecting to the domain. I would start eliminating possibilities of the source of the problem using both methods:

Do all computers point to the same server? No. But the ones with problems point to 192.168.1.253 (agreement).

If I point one of the problem computers to a different server, do I still have a problem? No. It works now. So the problem has to do with the difference between the working machines and the broken ones, and that difference involves that IP or the server using that IP (difference).

If I change the IP of the server for the machines that have a problem, and then point one of them to the new IP, do I still have a problem? Yes. So the problem is not with the address itself, but with the server (difference. Or is it agreement?)

Anyone reading this who does troubleshooting goes through steps like these, probably without thinking for a moment about Mill’s methods. Most troubleshooters may have never even heard of Mill. I didn’t need Mill’s methods to fix a problem like this, but I’ve found that being aware of them has increased the clarity I have regarding a problem and encouraged me to be more guided in my experimentation.

From all this, I’ve learned to continually (almost continuously) ask two simple questions, which embody the methods discussed so far:

“What is the difference between the machines that are working and those that are not?”

“Of the machines that have a problem, what do they have in common?”

Finally, once things are narrowed down, carefully introducing differences to test what is in common that might be the problem often yields results.

That’s the end of my post today. But wait! There’s more! We still have two more methods to cover, and we will in a later post.

Filed in System Administration | Tagged , , | Comments (0)

Is a Windows domain a sustainable environment for a penguin?

Monday, January 30, 2012

With help from two techs, I manage about 80 computers at an international school. The computers are Windows: half Win7, half XP. While I generally dislike proprietary and closed-source software, I must admit I’m grateful for ActiveDirectory, WSUS, PowerShell, and WMI. The system supports an environment where students, teachers, and administrative staff need access to their files from random places around campus along with security appropriate to their roles. While I am often thinking of how I might re-implement the system with Linux, I must consider the maintainability of the system. I’m thankful that those before me set this up since I’m still new, and it does the job well. Besides, I’m introducing a Linux web server and some webapps like Moodle to start shifting the teachers to rely more on Linux and open-source software without their even knowing it. If things go well, four years from now the school will require Linux expertise from IT workers they hire from then on [evil, plotting laugh here].

Already, working in this environment has given me plenty of opportunities to suspend judgment, tolerate ambiguity, and think grey (c.f. earlier post on switching from Vim to Emacs). I could say a number of unkind things about Mr. Gates, but I haven’t yet attained a mastery of it that would allow me to pass judgment on it. It annoys me when people revile atheists, fundamentalist religions, kinds of food, types of government, or just about any object of conversation without having attained any greater understanding of what they revile. Some of my most regrettable moments in life have been when I’ve let my mouth run just as I’ve described.

I am not a relativist, however, since I believe that in a collection of similar objects, certain ones will be better in terms of a given criterion than the others. The problem is that most controversial topics are controversial because the various aspects in question do not suggest an obvious winner–even among the masters of the topic qualified to give a valuable opinion.

I would rather be supporting Linux systems, along with open-source software to help the teachers and students learn. However, I can already see why Windows and other Microsoft products are an ideal fit for certain kinds of organizations. Rather than focusing on the more obviously disappointing qualities of Microsoft, we who believe in open source should seek to learn what actually is appealing about their products. How else can we create software and systems that are as good or better than theirs?

I’m still learning Emacs and using it daily at my job. I felt that writing about my experiences with system administration might be helpful to others, too, so that’s why I’ve opened this category.

Filed in System Administration | Tagged | Comments (0)

Setting up Emacs on Windows 7

Friday, January 13, 2012

Two days ago, I got Emacs set up on the command line on Windows 7 at my workplace. I’m the chief sysadmin of a small school, and we’ve been busy getting ready for the spring semester. I’m fortunate to have inherited a solid infrastructure of two labs of forty desktops each, plus desktops for the teachers, school administration, and a few other odd machines here and there (the oddest perhaps being a Slackware machine with aspirations to become the webapp server).

I’ve been working here half a year. I prefer Linux over Windows or Mac, but the school has been using Windows for 15 years. I’ll probably be blogging on my experiences as a Windows sysadmin as well since it involves a great deal of “suspending judgment, tolerating ambiguity, and thinking gray” that I promoted in the earlier post on choosing to learn Emacs. So far, Emacs involves much less pulling out of hair.

So as I was saying, two days ago I found myself needing to do some more extensive text editing, so I invested some time I didn’t have into setting Emacs up on one of the machines. I wanted full command line integration, not the funky white window/GUI. It had already become apparent that unless I get Emacs to where I’m using it instead of Vim at work, I may not succeed in really learning Emacs.

Fortunately, apart from a few minor issues, Emacs is much easier to set up for the style of usage I want than on OSX. Perhaps the most confusing thing initially was figuring out how to force emacs to use the command line instead of the gui, but this is easily achieved with “emacs -nw”. The more difficult thing was to figure out a way to abbreviate things in Powershell so I didn’t have to type so much. I finally found that using a wrapper function, not the seemingly straightforward ‘Set-Alias’ command, worked nicely. The problem with Set-Alias is that it doesn’t allow you to use arguments with the newly made alias. In other words, you can’t just tab-complete to open a file or files at the same time as invoking Emacs. So aliases in Powershell are not much like Bash aliases at all.

Another difficulty I had was in finding where my .emacs file was. Actually, I ended up having to make a _emacs instead because Emacs simply didn’t load it unless it used the underscore instead of the period. No problem, this is well-documented in the Emacs helps, and it’s the same for Vim on Windows (you need _vimrc).

I like to use a very simple markdown system, Text2Tags (or txt2tags or whatever) for most of my documents since it’s fancier than plain text, but very portable. I can write once and publish to several desirable formats. I’ve used this on Vim for several years, so since I would be using that on the project at hand, I looked for a mode. Vimmers, looking for a editing mode is almost a knee-jerk reaction for Emacs users. A mode is mostly similar to how Vim handles various programming language formats (e. g. syntax highlighting, special language-specific commands). Modes seem a little more coherent and fleshed out in Emacs. The downside seems to be that you have to become accustomed to the idiosyncracies of each mode to use them well, but there seem to be some informal conventions as to which keys should be used for roughly similar tasks across different modes.

So the main problem I had with the txt2tags mode for Emacs was that the character encoding for the init file was in Western-iso-whatever ascii-ish thing, but the browser didn’t detect it since it was a strange extension (.el). Once I got the encoding matchign up right for the unicode in Emacs, there was no problem. It seems that the txt2tags mode in Emacs does little more than syntax highlighting, but that’s all you get with Vim, too.

Still having Vim motion command withdrawal, but still excited about learning Emacs.

Filed in Learning Emacs | Tagged , | Comments (1)

b is for Backslide

Thursday, January 5, 2012

In Vim, typing ‘b’ sends you back a word. I have to confess that I’ve sneaked some Vim time in, backslidden a bit if you will. The first slip-up was when I absentmindedly edited my .bashrc or .bash_profile. I didn’t even think about it; before I knew it I’d already added a line at the end of the file, saved, and exited before I realized I did it all in Vim.

The second setback was at my workplace. I can’t yet justify using company time to install emacs on my work machines because we’re in the middle of an unusually busy time. I have MIT-Scheme Emacs on a few machines, but not a commandline version of Emacs for all my shell editing. I did just install it in a Linux Mint VirtualBox machine which I use for things that just aren’t worth trying to do with Windows. Hopefully things will slow down enough for me to make the switch there, too.

Related to that was work I needed to do on a pfSense box that didn’t even have Vim, just Vi on it. Things were fine except I kept haning on there being no ‘gg’ to go to the top of the file. In Vi you have to do ‘1G’. I think I’ll leave it that way, though, because I don’t want to put anything on the pfSense that I don’t have to.

Filed in Learning Emacs | Tagged , | Comments (1)

Brief Reflections on Stallman’s GNU Manifesto

Monday, January 2, 2012

Brief Reflections on Stallman’s GNU Manifesto

While re-reading some Emacs basics in the info pages, I noticed that there was a manifesto by Stallman. I’d run across his name for many years on Slashdot, books on open source and a number of other places, so I thought I’d read about it. I was blown away. Even as a lover of open source for quite a few years now, and even though Stallman wrote this essay back in the 80s, I was blown away. Stallman is one of those rare thinkers who has both vision and pragmatism. His sense of where things were going, or could go, was acute.

If you use open source software, or if you are interested in copyright law, it’s worth a read. I expected a raving anti-copyright demi-pirate (not that there’s anything wrong with that), but instead, he was level-headed, and discussed conditions where copyright has been useful in the past. The essay does not argue for the abolition of copyright, patents, and the like, but rather a communal banding together to provide great alternatives to the stuff that’s locked down.

I now feel I owe much more to Stallman than I knew, perhaps more than to Torvalds. These, and the many who have worked to make their visions a reality, have made inestimable contributions to society in general. Of course the founder of Vim is active working with disadvantaged children in Uganda and pushes for helping them out. I don’t think there’s much point in arguing over whose societal contributions are worth more, it’s just really cool that they are doing what they can to make this world a better place. I have not given a penny to the kids in Uganda even though I’ve used Vim for years. I have not given a penny to the Free Software Foundation, even though I probably use at least on or another of their Gnu applications on a daily basis without thinking of it. I haven’t even submitted a bug report, written any code, given feedback, or done any translation work. This has bothered me for some months, and I plan to start giving back as best as I can, in whatever way I can, so that all can benefit (I have given to Wikipedia a few times, and I’d encourage you to do the same–even $5 USD can make a huge difference).

Filed in Learning Emacs | Tagged , , , , , | Comments (0)

Vim to Emacs: Initial Impressions

Monday, January 2, 2012

Today is my first post on my actual experience with Emacs in comparison with Vim. I’ve been using it lightly for a few weeks, and seriously for about 3 days. Hopefully my first impressions are still fresh.

Installation

Right off I should make it clear that my Emacs needs are a little unusual for the average Mac user (but not for the average Linux user). I want to be able to use Emacs completely within a shell, in this case Bash in Terminal.app. If you use an OS other than OSX, or you revile the command line, my setup is of little use to you.

I’ve been using MacPorts for almost a year to cover my Linux software cravings and have been pretty happy with it so far, so I did a quick “$ sudo port install emacs” and was done with it. Maybe I had to uninstall an existing OSX version of Emacs or at least point the bin to the MacPorts version, but that was it–at least initially.

The first problem I ran into was the meta key, one of the two main combo/prefix keys used in Emacs. On most keyboards it is the ‘alt’ key, but since most alt+key commands used in Windows tend to be apple/command+key on Mac, meta defaults to the command key. This is a nuisance when using Emacs since many window management commands also use the command key (command + q quits a program for example). Fortunately the fix is pretty easy, and I didn’t have to resort to the internet to find it. You just need to set Terminal to use the alt key as meta in the preferences for Terminal.

The bigger problem came along later when I was wanting to use the super key for one method of cutting and pasting from Emacs in Terminal to another app like Firefox. The super key seems to be used only rarely for common, and even less common, commands in Emacs. I still don’t know how to set the super key, even following several lisp settings recommended on the EmacsWiki and other sites (lots of “(setq

In short, installation seemed a breeze, but the default MacPorts configuration, or perhaps using Terminal.app, leave some things to be desired.

First Experiences

I could give some typical gripes a Vi/Vim user is likely to have with the interface, but instead I’ll just repeat (for the benefit of fellow Vimmers), “Suspend Judgment!” Sure, I miss the myriad of movement keys tailored for atomic, sophisticated editing and on-the-fly macro-making. I also miss my familiar %s/[find-regex]/[replace-regex]/ syntax for find and replace. I’m not going to say I love the reliance on multi-key combos because I don’t yet, and might not. But by stifling my gag reflex, I’ve already enjoyed the following:

  • Better help system
  • I finally understand “info” files
  • Evaluation buffers are cool. Vim eval yanks you out into the quasi-command line in a clumsy way.
  • I finally understand the default key behavior on the bash command line
  • I know more about GNU in general
  • It’s nice not having to type C-[ or Esc to leave insert mode
  • Typing text just seems to flow (in Vim, I love/hate the continual awareness of the mechanical dissection of the text into beginings/ends of words/sentences/paragraphs/lines etc)
  • Everything being lisp deep down is pretty cool.

Many Vimmers probably already understand info files or could take exception to many of my points above. I do not claim their greatness for everyone, but they have been of use to me. Also, a number of areas that don’t yet seem obviously superior or inferior still give me insight into why Vim does things a certain way, or an alternate way to do the same job. I’m thinking, in particular, of buffer handling.

Without knowing the reason behind it, I am annoyed with the temporary files emacs makes. Vim/gVim for Windows is bad enough with its swp files it leaves all over the place until you fix it in the vimrc. This install of Emacs, though leaves at least two kinds of tmp/backup files around, the ‘#’ prefixed ones, and the ‘~’ affixed. Someday I’ll read up on it, and maybe I’ll love or at least respect the reasons, but little pointless files junking up my home directory is a pet peeve of mine. OSX leaves DS_Store files. Windows throws thumb.ini’s. I’m actually a fan of the hidden config files for programs in Unix (like .vimrc, .emacs), but I don’t want to see backups and partials unless there’s a crash (then I’m thankful for them). Emacs already asks at least twice if I want to trash a buffer I haven’t saved, so I don’t see the point of putting up a ‘#’ file on top of it.

I think the intro tutorial for Emacs is well-written. It got me up to speed in minutes, and if I had a few days between using it, I could just do a brief review and be on track again. Unfortunately, for me, the lengthy section at the end of the tutorial on how to get further help was more confusing than helpful. I latched on to trying C-h a to explore commands, but this was only moderately useful. What really helped was using M-x info. The info pages are incredible, and for me, it would have been much more useful for me. Navigating through the info pages seems more natural than the Vim help since in Vim you have to use the peculiar bindings ctrl-] and ctrl-o to move between links. I used to hate info pages in general, but now that I’ve navigated through them using Emacs, they make sense, and that’s worth a good deal since I now have another resource besides man pages to turn to for in-depth offline information.

I’d have to say that Emacs’ help edges out Vim’s. The important thing for a new user of either editor is to dig into it as soon as possible–they have a wealth of information (unlike the generally disappointing or nonexistant help in for Apple and Windows products).

Well, it’s late, and I could do a full post on a number of these items in the list above, so I’ll call it quits. Until next time, C-x C-s, C-x C-c.

Filed in Learning Emacs | Tagged , | Comments (1)

From Vim to Emacs Day 2 – Methodology

Friday, December 30, 2011

In the previous post, I gave my reasons for wanting to blog about learning Emacs (I’ve been a satisfied Vim user for years). Today I want to give my methodology and maybe some first impressions.

Philosophy Behind the Methodology

Learning something new and significant with computers feels similar to learning a new language and culture. At first everything is strange and unfamiliar, and it feels like you’re getting nowhere. It makes you just want to retreat back into what you’re comfortable with: your own language and culture. Occasionally you have flashes of insight only to realize (often shortly after the same flash of insight) that what you thought you understood is only useful in limited contexts, or that a slight nuance in your expression undermined your efforts.

The farther you get with the basics of a new language, the closer you get to really learning the culture behind the language. The extent to which the Sapir-Worf Hypothesis is true (if at all) is a heated debate, but at the very least, the differences in grammar and vocabulary cause one to become more aware of philosophical implications of one’s own language and culture contrasted with possibilities of difference in the host culture. What one gains from really learning another language is more than just the ability to communicate with a larger segment of the world population (which would be reward enough depending on one’s goals and line of work). One gains a deeper understanding of one’s self, one’s own culture, and new tools for understanding life experiences.

This may sound too humanities-oriented to be comfortable for the typical computer nerd. To put it another, more direct, way, learning a new technology gives you new tools to get a job done. Perhaps even better, learning a new technology can give you a new way of thinking about and using the tools you already possess. The bigger question then becomes, “Which tools/languages/cultures should I devote my miniscule time to?”

Methodology

Once one decides to learn something significantly new to one’s experience, the question becomes how best to learn it. If the new technology is in a completely different problem domain from anything learned so far, there is an advantage in that nothing must be unlearned to continue. On the other hand, if there is overlap between the new tech and something already learned, one can often breeze through many of the basics.

For example, if I were learning MATLAB, I would have very few hangups that others might have coming from a Mathematica background. I know almost nothing about either of the programs, so I can dive in and start learning. On the other hand, in my present case, I have a decent foundation working in Vim, and the overlap with Emacs is substantial. As I write this article in Emacs I constantly jerk my hand away from pressing ctl-[ so I can leave insert mode to do some nifty movement commands to delete a wordy sentence or paragraph (so blame the wordiness of this post on Emacs, ok?.)

There will be plenty of time to gripe about things I miss from Vim later. For now I want to call attention to a method I learned about cross-cultural adaptation that helped me get over the hump with Emacs. It is summarized in the abbreviation JAG:

  • Suspend Judgment
  • Tolerate Ambiguity
  • Think Grey

My first serious sessions in Emacs were riddled with reactions and gripes I consistently had to supress. I was often tempted to give up. “How can I make macros?” “Why isn’t there an easy way to delete a paragraph?” “How in the world am I going to remember C-x ESC C-@ b!?!?!?” To proceed one has to unlearn (temporarily) what is familiar and reassuring. Unless one can supress their mental gag reflex, it will be too easy to give up.

Suspending judgment is the first step. Tolerating ambiguity is the next and involves resignation to not understanding or knowing for an indefinite period of time. Maybe I’ll never know why Emacs doesn’t seem to highlight a region of text I’m wanting to copy from a mark. Or maybe I will. Maybe Emacs won’t work as well at the workplace on Windows desktops. Maybe I’ll like Emacs better than Vim (don’t laugh, the thought of become one of those freaks is scary to me). The important thing is to be ok with being in freefall.

Finally, there’s thinking grey. I suspect this was just thrown in by cross-cultural instructors to make a nice mantra and a sort of word for the acronym. This is just a sort of blend of the first two. If you suppress snap judgments (black and white thinking), and keep an attitude of being content with the resulting ambiguity, you’ll be more likely to continue and see positives where you would otherwise have seen negatives.

If you are not already and Emacs or Vim user, you probably think these head games are over-the-top just for a stupid text editor. I would challenge you to find someone who has used either almost exclusively for at least 5 years and see what happens when they try to make the switch. You might as well force a trumpet player to try the alto sax–after all, aren’t the two just wind instruments? There are a lot less keys involved in the switch between these than between Vim/Emacs, so it should be pretty trivial, right? At worst, the trumpet player just has to learn how to blow a bit different. Anyone who’s played an instrumetn should be laughing right now. We know that there is a HUGE cultural difference between horns and sax that goes way beyond the mere technical differences.

The previous part of my methodology for learning Emacs is generally useful. I think it is essential for getting the right attitude for learning new things. The following are specific to me and my learning style. You may or may not find it helpful, and if you decide to walk the path to a different guru (or is it GNUru?), I hope you radically reassess how you would go about it.

(btw, just had to suspend judgment. I tried a key combo to finish out a tag in html major mode and ended up getting lost in a sea of key combos. C-c C- oops. Forgot. I’ll press Esc to get out. Now it’s complaining about recursive edit. Stupid piece of… Ok, suspend judgment, wait, I shouldn’t have pressed Esc again. Now I’m in some other prefix key. Grr. Maybe I should have used C-g or something like that to cancel the current key sequence…)

Ok, so this is specific for me. I’m recently learning that I do best if I do a mixture of top-down and bottom-up learning. I read some theory, then try it out writing an article like this. Or I jump in to editing a different kind of document and go as far as I can with what I already know, and play around with a few keys or look up some contextual help to keep moving. Then I read some more theory and background that helps in general understanding. I find if I stay too long on top or on bottom, I get bogged down. If top-heavy, I am constantly foiled by inexplicable behavior. If bottom-heavy, I slog through a muck of theory, math, Backus-Naur notation, etc. and don’t get much done.

I’m mostly a visual learner. I find that repetition is the key to getting to the point I’d rather be, of being creative and outside the box (after all, if you don’t know what the box is, how can you know if you’re really outside it?). I follow threads of systematic learning mixed with whatever strikes my fancy.

I am a sytemic thinker; that is, I think in terms of systems (INTP Architect tendancies). I want to know what the entire, holistic, big picture view of the system is, and I also want to have as good an understanding of the subsystems, and more importantly, the interfaces between them. This may just be another way of expressing what I said before about bouncing between top-down/bottom-up thinking.

On the whole, though, I will aim to use Emacs for most of my editing work, whether it be these blog posts, a bit of scripting in whatever language, some continuing ed. coursework, etc. I will also aim to learn at least one new thing and use it before or in my next blog post. For example, in this post, I tried out using the html major mode to insert tags as I wrote. Who knows? I might even try learning a bit of Emacs Lisp or the various operating-systemish components so often reVIled by old geezers using the other, purer ancestor of Vim.

Next post I’ll give my first impressions of Emacs compared to Vim. I will, with extreme prejudice (in at least two senses of the word), unload on things I find irritating and frustrating as a new user of Emacs. This may not reveal anything that you couldn’t already find on flamewar sites or even Wikipedia, but I hope it will serve as my first mile marker on this journey. It would be even better if it helped Emacs pros to get a picture of what new users may have problems with. Also, I already have quite a few good things to say about Emacs. I can already say that it would benefit Vim users to give Emacs a serious try for a week.

Filed in Learning Emacs | Tagged , , | Comments (1)

From Vim to Emacs Day 1

Thursday, December 29, 2011

I’ve been using Vim almost exclusively as my text editor for 5 years. At first I used Vim like a clumsy version of Notepad++. It would be fair to say that at the end of two years, I knew only five or six movement keys, one way to enter insert mode (and get out), next to nothing about visual mode and ex mode, and nothing about registers. I kind of knew what buffers were and could load files into buffers and move between them. I knew how to copy and paste, but only within vim, not with external programs via the system clipboard.

Despite my limitations, I stuck with vim the first two years because it was still a step up from Nano/Notepad/Notepad++ and usually was pre-installed on any distro of Linux I was using. If I had to use Windows, Vim was fairly easy to install, and I wasn’t yet using Macs. I especially loved the easy way of making and using macros combined with the few movement keys I knew. Also, prefixing a number to make something happen many times was pretty exciting. Bottom line, I could type, edit, search/replace, copy and paste (inside Vim at any rate), save, and get a bunch of built-in functionality like syntax highlighting.

I was too lazy to dig in and learn Vim better, but finally realized there was a lot out there I was missing. Over the next 5 years I learned about folding, registers, abbreviations, skeleton files, and more. Scripting is still rather weak, but that’s about it.

So why learn Emacs at this point? I certainly have a ways to go to really take advantage of all Vim has to offer. Like many others, I feel I could use Vim the rest of my life and still find techniques and tricks that make my editing even more efficient. I really enjoy the modal editing now that I’m used to it. What got me started on the Emacs path was teaching some programming to some high school students. They were gifted students, so I decided to teach them some functional programming since they had little exposure in this area. I dusted off cobwebby corners of Scheme from a few years back and downloaded the MIT-Scheme distro for Windows (we were unfortunately working in a Windows-only campus). I soon realized it was some hacked-up version of Emacs tailored for Scheme. I went through the internal tutorial to get a feel for the keys again (I’d used Emacs a tiny bit in college when it made following a professor easier).

I knew that Emacs had its own version of Lisp, and I used introductory sections from Structure and Interpretation of Computer Programs (SICP) for my lessons on this unit. I was loving the functional paradigm more than ever, and there was a much smoother feel for working with Scheme code in Emacs than in Vim. The built-in interpreter and indentation just worked.

The more I’ve used Emacs, the more intrigued I’ve become with what it seems to offer. Over the last week or so, I’ve been going through tutorials and familiarizing myself with Emacs (not the MIT distro, but whatever came with OSX or via Ports). Even so, this seems the right time to blog on this since I am still fresh enough with Emacs that I am often typing Vim commands that get Emacs cussing at me pretty quick.

It may be that I end up using Emacs just for Lisp/Scheme coding. Or I might come to find it superior to Vim. For me, it’s just an exercise in learning alternative mindsets and approaches. For example, I grew up using Windows because I didn’t know anything else existed. Then I learned Linux and have been sold on Linux for a decade. However, what I’ve learned in Linux has helped me understand Windows better. Learning OSX (my current main system) has helped me understand the Apple world, BSD, and even Linux a bit better. Everything I’ve learned in life has been useful in some way.

My plan is to use Emacs as much as possible, and at least for my playing around with Scheme and writing these blog posts. I will try to give impartial comments on my impressions (labeled as such) and deeper observations. I’m in a very weird time in my IT life, so it is possible I will end up talking about using GUI/non-GUI versions of Vim/gVim/Emacs on Mac OSX (Snow Leopard), Windows 7, Linux Mint, Slackware, and maybe some others. Most of the time I’ll be on OSX, working in a purely command line verison of Emacs in a Bash Terminal, but I may mention others if the OS, distro, or interface seems pertinent.

Note: Throughout this blog, I consistently compare Vim, NOT Vi, to Emacs. Traditionally the war has been between heavyweight Emacs and lightweight Vi. I have never really used anything other than Vim among the Vi clones so can’t speak with any authority on Vi. However, I can say that knowing Vim leads to few problems when using a system that just has Vi. Deleting and changing text feels a bit weird at first, and you miss a few creature comforts, but really not a big deal. While Vim is quite a bit larger than Vi, it is still about a tenth smaller than Emacs (using a very rough comparison based on the standard Windows installers for the two). The important thing, reader, is to be aware that it is Vim, not Vi we’re talking about here. For text-editor heathens out there still using MS Word, this might sound like distinguishing Southern Baptists from Anabaptists.

Filed in Learning Emacs | Tagged , | Comments (1)