Wandering Thoughts archives

2012-06-27

One root of my problem with GNU Emacs

I have a GNU Emacs problem. It is at least sort of one of the reasons that I don't use GNU Emacs as much as I could.

The origin of my problem is that back what is now two decades ago (in the days of GNU Emacs 18) I was very into GNU Emacs; in fact, you could say that I was immersed in it. Then, slowly and for various reasons, I drifted partly away from GNU Emacs and especially had little contact (at least that I remember) with versions after version 18.

(I have a vague and possibly incorrect memory that many of the systems I used stayed on GNU Emacs 18 for close to a decade for various reasons.)

Those of you with GNU Emacs experience probably understand the problem now. You see, when you are deeply immersed in GNU Emacs, one of the things that happens is that you build up a bunch of personal ELisp code and .emacs customizations; you almost can't not do this. I was no exception and since I was young and enthusiastic, I wound up with quite a pile. All of which was written for GNU Emacs 18.

For those of you who have never used it (which would be almost everyone), let me assure you that GNU Emacs has changed a lot since version 18, including the ELisp environment and the effective GNU Emacs 'API' that your ELisp uses. If I had stayed immersed in progression of GNU Emacs versions over the two decades since version 18, this would be no problem; as an active user, I would have been on top of the waves of changes and progressively forward-ported or modified all of my pile of ELisp to accommodate them.

Instead, I am more like Rip van Winkle. The past two decades of GNU Emacs evolution plus my neglect have left me nursing a (reduced) tottering pile of ELisp code and .emacs hackery, much of which I barely remember any more. My code and customizations are probably doing things the wrong way now and sometimes probably the wrong thing to boot, but I'm too out of touch to know what the right thing is any more. In turn this mess feeds my disengagement from GNU Emacs (and discourages me from trying to fix any of the bits that irritate me about editing various things in GNU Emacs).

I suspect that the right solution to this mess is a rewrite from scratch; throw out my existing, hacked up .emacs and all of my remaining ELisp code, then redo everything that I still need or want. The good part of forgetting much of what I once knew about GNU Emacs programming is that I will have no choice but to look everything up in the current documentation (and thus I will get current information about how to do things right).

The downside of this, and why I shy away from the very idea of it, is that it will make using GNU Emacs painful for a while and require me to spend a bunch of time immersing myself in it again, all in order to return me to more or less where I am today.

(This would be a much easier sale if I was convinced that GNU Emacs was the editor I wanted to use all the time, but I'm not. And just pragmatically I'm always going to use vi a bunch no matter what editor I actually like best.)

PS: this problem would not be improved by using an IDE instead of GNU Emacs. If anything, an IDE would make it worse and GNU Emacs has actually been remarkably stable over those two decades. I'm pretty sure that there's no active, currently maintained IDE where you could basically ignore the past decade of new versions; instead, I'd expect that you'd pretty much have to start all over from scratch if you tried to jump from a decade old version to the current one.

programming/MyEmacsProblem written at 03:01:06; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.