dot-emacs trickery (emacs-fu)

It's been a while, and to be honest, emacs-fu has been doing such a great job putting up useful snippets of Emacs information...

He just put up a question asking for folk's favorite dot-emacs tricks. I added my two cents with:

(defun tj-find-file-check-make-large-file-read-only-hook ()
 "If a file is over a given size, make the buffer read only."
 (when (> (buffer-size) (* 1024 1024))
   (setq buffer-read-only t)
   (buffer-disable-undo)
   (message "Buffer is set to read-only because it is large.  Undo also disabled.")))
    

(add-hook 'find-file-hooks 'tj-find-file-check-make-large-file-read-only-hook)

Don't Like It? Code it Yourself!

Jeff Atwood writes on a topic that's interested me for quite a while:

Coding Horror: Don't Like It? Code it Yourself!

To me, at least, sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project. For example, I've sponsored several bugfixes in a key .NET open source library that we use for Stack Overflow. These are bugfixes they considered low priority, but were serious issues for our site. I was happy to give back to the project, and it was certainly a more realistic option than us carving out a chunk of our own development time to contribute the bugfixes ourselves.

That said, I am concerned that this sort of aggregated sponsorship system hasn't naturally evolved on its own by now. Is it not sustainible, or incompatible with the kind of intrinsic motivations that drive most open source development?

In my previous job, we wrote software that heavily relied upon open source and GPL'ed software. The entire department developed and deployed software (primarily) for Linux systems, used gcc, Tcl/Tk, and a bunch of smaller open source tools. When compared to the more proprietary systems used (AIX, HP-UX), the savings were huge - both in software, hardware, and overall productivity.

At one point, the department decided to look into providing a "better"(?) debugging experience. After some research, they settled on a proprietary debugger. A year passed, licenses were finally purchased, and ... it was quietly released into the department, with very little fanfare.

I eventually found out about it, tried it out, and found the experience to be underwhelming to say the least. Several of the touted "features" were still in development (visualization of STL containers) and not to be delivered for another year, and the rest of the "features" had been in DDD/GDB for years. As an added hassle, it required the object files to be post-processed to obtain debugging symbols in their proprietary format.

To make a long story short(er), I found out we had paid many times my annual salary for a set of licenses for software that didn't have the features found in open-source software, and we had to pay this amount annually.

I fed this information up the chain of command, which just got the manager of software-development-environment angry at me. I proposed we use the money to instead hire a contractor to work on any bugs/enhancements for GDB/DDD, using the logic that not only would it be cheaper, it'd provide a return on investment faster, as well as be available to the entire department/company/world from here on out - at no extra cost. At the very least, it seemed to me, it was a tiny price to pay for the company's ability to use the open source Linux systems for development.

Management wasn't interested, not in the slightest. About the only argument they'd give me for keeping the status quo was that companies preferred working with other companies, and not contractors.

This always seemed to be more of a duck than a real argument.

I figured, if the software was good enough to use, it should be good enough to pay to improve.

More Advice

Way back when I wrote a tip about Emacs Lisp's advice.

How I wish other languages had this capability. A couple of questions came up recently on stackoverflow.com that were (imo) best answered using advice. So, if you're struggling to see when to use advice, I think they're pretty good examples.

"Diff, save or kill" when killing buffers in emacs

Can I change emacs find-file history?

Dynamic Modal Bindings (auto prefixing)

A guy posted an interesting question on stackoverflow:

Most emacs modes include some sort of prefix to activate their features. For example, when using GUD "next" is "C-c C-n". Of these modes, many provide special buffers where one can use a single key to activate some functionality (just 'n' or 'p' to read next/previous mail in GNUS for example).

Not all modes provide such a buffer, however, and repeatedly typing the prefix can be tiresome. Is there a well-known bit of elisp that will allow for ad-hoc specification of prefix keys to be perpended to all input for some time? (Until hitting ESC or some other sanctioned key, for example)

Very intriguing, how does one go about solving that?

I don't think you want that (in general) because many of the prefix commands contain an extensive set bindings which clobber too many useful keys. That being said, I'm sure there are places this could come in handy.

I wrote up a solution that prompts you for a key sequence, and it promotes the prefix command keymap to the toplevel (associated with this particular minor mode). The minor mode is buffer specific, and it only allows one prefix command to be promoted at a time.

Check out my answer (won't put the code here in case I need to make an update).

Emacs Tip #28: e-blog

There are a number of different packages purporting to enable blogging from Emacs, but most people (including myself) have failed to get any of them to work.

I recently heard about: http://code.google.com/p/e-blog/, as a simple blogging package specifically for blogger.

This is my first post.

Note: It does depend on curl.

stackoverflow.com

If you read Coding Horror or Joel On Software, you already know about stackoverflow.com. In a nutshell, it's a place where you can ask coding questions and receive answers quickly. You can also participate by voting answers up/down and answering questions.

stackoverflow.com works really well, the overall design is very simple, clean, and easy to use.

The emacs community there is pretty small, but questions do come up now and then. In general the answers are fairly good (I think mine are stupendous, feel free to look at them and vote them up).

Like any good (modern) web page, this one has plenty of RSS feeds. This is the feed I use to watch questions tagged emacs elisp emacs-lisp dot-emacs.

Emacs Tip #27: midnight-mode

I generally have a single emacs session that runs for a couple weeks, up to about 3 months (when work does it's quarterly preventative maintenance reboot), and because of this, I often have dozens of buffers open. Periodically I'd go through them and remove a bunch - mostly to free up memory.

Luckily, there's a mode that already does that for you, periodically flushing unused and old buffers:

(require 'midnight)

The following variables can be used to customize the behavior of the clean-buffer-list (which is run daily at midnight). It responds to settings of the following variables:

clean-buffer-list-kill-buffer-names
clean-buffer-list-kill-regexps
clean-buffer-list-kill-never-buffer-names
clean-buffer-list-kill-never-regexps
clean-buffer-list-delay-general
clean-buffer-list-delay-special

I love finding packages that implement functionality I hadn't realized I wanted. It is very relieving, like accidentally scratching an itch I didn't know was bothering me.

Edited to reflect proper require statement.