Shame
I had to; I couldn't take it.
(define-key view-mode-map (kbd "j") '(lambda ()
(interactive) (scroll-up 1)))
(define-key view-mode-map (kbd "k") '(lambda ()
(interactive) (scroll-down 1)))
I'm so ashamed.
I had to; I couldn't take it.
(define-key view-mode-map (kbd "j") '(lambda ()
(interactive) (scroll-up 1)))
(define-key view-mode-map (kbd "k") '(lambda ()
(interactive) (scroll-down 1)))
I'm so ashamed.
We recently returned from a tour. While on the road, I'm still working. I have a slick bean bag chair, curtains and MiFi router, which makes it possible to get my work done while cruising down the freeway. This is something I've discussed before.
My two recent annoyances with my setup are not having an automatic way of completing an email address and slow updates to the server. So far, the slow updates will probably involve setting up a local IMAP server to sync to and from. It is something that I've started looking into, but haven't spent that much time on it. It ends up being easy enough to just ignore email and save the time. What is rather annoying is having to enter email addresses.
It is not that bad, but it is relatively time consuming. My typing could be much better and it can be easy to make mistakes. Also, there are many times I'm copying the email address from some other resource such as a web page or IRC, in which case, there is a lot of buffer management to deal with. Again, not a huge deal but enough to warrant looking into solutions.
Fortunately, like most things in the Emacs landscape, there was already a good solution in place. The BBDB or the Insidious Big Brother Database. I initially tried using the tips mentioned on emacs-fu but found it didn't work. Fortunately, I found the solution was incredibly convenient and directly in the Wanderlust docs. The result, is now I'm collecting email addresses for completion much like I would get in gmail in addition to having an actual addressbook I might consider using. Pretty nice ROI for googling a bit.
This is realization you need a feature is a pretty common occurance in Linux. The conceptual basis is usually there to create a solution, but often times it takes a bit of work to really get things configured. Emacs is very similar, with the exception being it is almost expected that the configuration might very well be writing a new mode or piece of functionality yourself. It serves as a good reminder that I shouldn't go recommending Emacs to my parents anytime soon. Although it would be pretty cool if I did get a call from my dad asking about setting up a keybinding for some lisp function he wrote.
I've been meaning to blog about this for some time, so I suppose now
is as good an opportunity as any. This is going to be a very "stream
of consciousness"-esque posting, so bear with me. Some of these are
things that have radically changed the way I use emacs. Others are
minor changes that I like. Feel free to pick and choose from them.
sudo apt-get install python-ropemacsAfter that, just a couple of lines of elisp in your .emacs file and
(require 'pymacs) (pymacs-load "ropemacs" "rope-") (setq ropemacs-enable-autoimport t)
(require 'anything-config) (require 'anything-match-plugin) (global-set-key "\C-ca" 'anything) (global-set-key "\C-ce" 'anything-for-files)Then, prepare to spend a lot less time searching for files!
(require 'linum) (global-linum-mode 1)
sudo apt-get install pyflakes...and some elisp:
(when (load "flymake" t)
(defun flymake-pyflakes-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "pyflakes" (list local-file))))
(add-to-list 'flymake-allowed-file-name-masks
'("\\.py\\'" flymake-pyflakes-init)))
(setq uniquify-buffer-name-style 'reverse) (setq uniquify-separator "/") (setq uniquify-after-kill-buffer-p t) ; rename after killing uniquified (setq uniquify-ignore-buffers-re "^\\*") ; don't muck with special buffers (or Gnus mail buffers)
sudo apt-get install python-modeAnd add some elisp:
(autoload 'python-mode "python-mode" "Python Mode." t)
(add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode))
(add-to-list 'interpreter-mode-alist '("python" . python-mode))
In this post I'll cover the setup I use for developing my Compojure/GAE app.
EmacsCompojure
You can download a tarball of the Compojure sources from http://github.com/weavejester/compojure/downloads, but I'd recommend cloning the git repository at git://github.com/weavejester/compojure.git. Either way you'll build the compojure.jar from source using ant.
One of the commands I use most often in Emacs, especially when editing code, is delete-blank-lines (C-x C-o). Documentation:
On blank line, delete all surrounding blank lines, leaving just one. On isolated blank line, delete that one. On nonblank line, delete any immediately following blank lines.
Very nice. But I want it do more. I want it to fix up the indentation after it removes, and I want it to join lines. It seems silly to me that calling it once removes all but one blank line, calling it twice removes the last blank lines, and calling it thrice—does nothing. It should join the lines.
The source code for the function is pretty straightforward. It sets two variables, thisblank and nextblank, and behaves according to their values. So I wrote an advice.
(defadvice delete-blank-lines (around salcher/delete-blank-lines-indent-or-join activate compile) "After removing blank lines, indent; without blank lines, join." (let (thisblank nextblank) (progn (save-excursion (beginning-of-line) (setq thisblank (looking-at "[ \t]*$")) (setq nextblank (progn (forward-line) (beginning-of-line) (looking-at "[ \t]*$")))) (cond ;; if this and next are blank, do it then indent ((and thisblank nextblank) (progn ad-do-it (unless (eq comment-start nil) (progn (indent-according-to-mode))))) ;; if this isn't blank but next is, do it then indent the next line. ((and (not thisblank) nextblank) (progn ad-do-it (unless (eq comment-start nil) (progn (save-excursion (forward-line) (indent-according-to-mode)))))) ;; join if no blank lines ((and (not thisblank) (not nextblank)) (join-line 1)) (t ad-do-it)))))
This is probably the only piece of Elisp I've written that I use almost every day.
(I know, I overuse progn. I don't have a feel for it yet.)
(This was a test of how Posterous handles code formatted by htmlize. It failed the first time—stripped the <pre> tags from the email. Had to paste it in by hand.)
(Finally. I've always wanted to write a blog post with N ways to do something.)
To begin with, I reject two obvious steps: run a different, lighter distro; and don't use KDE.
I use Ubuntu on my laptop for one overriding reason: hardware compatibility. Slackware was my first distro, and I loved it. I love it still. On my desktop it worked fine. On my laptop—it didn't. I spent insane amounts of time—months—trying to make X work on that laptop. I learned a lot about Linux. I learned so much about Linux that my next distro was… Cygwin.
I never ever want to go through that again. I never ever even want to be reminded of that experience again. On a desktop, I am willing to try other distros. Never on a laptop.
As for KDE: this is my caprice. I just like KDE better than GNOME or Xfce. It just seems better thought out. Take a simple example: shutdown scripts. It's easy enough in any desktop environment to create scripts to run on startup. Only KDE provides a straightforward facility to run scripts on shutdown. (This saves me having to explicitly kill the Emacs daemon every time I shut down.)
(To be honest, KDE4 has been severely testing my patience, but they seem to have their act together now. I rarely have to switch to a virtual console and pkill -9 kscreenlocker anymore.)
(I know there's a whole world of tiling window manager's out there, but they strike me as gimmicky, like most efforts to Emacsify things that aren't Emacs. I love Emacs. I'm writing this in Emacs. But anything beyond readline compatibility just crosses my wires—frustrates me with false expectations. I want all of Emacs or nothing.)
Anyway, there were supposed to be instructions.
I assume you know the basics: turn your modem off when you're not using it, lower the screen brightness, leave the sound off, etc.
The first way to save power: turn off the Flash plugin. This isn't Ubuntu-specific, but it's the best place to start. Just having the flash plugin on—without having any Flash video playing—accounts for half the processor activity on the machine.
(In Opera you can toggle plugins on & off with two keystrokes: <f12> u. I assume there are ways to do this in Firefox. Google it.)
The second way to save power: lower the swappiness. Swappiness weights how likely the kernel is to use swap. The default for Ubuntu is 60—absurdly high. On a laptop you never, ever want to use swap. The performance penalty of not using swap is always preferable to the battery drain of requiring the hard disk to mimic RAM. You can try this out:
sudo bash
echo 10 > /proc/sys/vm/swappiness
(You could set it to 0 but this might screw things up if you run something very demanding, which you shouldn't do, but you might do without meaning to. I keep it at 10 and the machine never uses swap.)
(sudo bash in the above is a gutless root shell. You could sudo su root or sudo -i too but this won't work with your usual sudo make -blt sandwich approach.)
To make this permanent put vm.swappiness = 20 in sysctl.conf
The third way: mount /tmp as a ramdisk. This is as simple as adding a line to the end of your /etc/fstab:
tmpfs /tmp tmpfs defaults,nosuid,size=1g,mode=1777 0 0
N.B. Whenever you are watching Flash video, the video is being written to /tmp. If you must use Flash on battery power, this makes it a lot easier on the battery.
(You could also write a autostart script to create a series of folders in /tmp & symlink all your browser cache folders to them. Exercise for the reader.)
The fourth and fifth ways: powertop and laptop-mode. Powertop is a neato program that analyzes processor activity and show you what's hogging cycles (like Flash). Laptop-mode (included but deactivated in Ubuntu) is a neato kernel feature that spools and spaces out writes to the disk. They come together in this list because although Powertop will suggest and execute changes to your system, it can't make any of these changes permanent. Laptop-mode lets you do that. First run powertop. Write down all of its suggestions. Then go to /etc/laptop-mode/conf.d/ and start poking around. All of the changes laptop-mode suggests can made permanent by altering the appropriate configuration files here.
(And turn laptop-mode on: in /etc/laptop-mode/laptop-mode.conf set ENABLE_LAPTOP_MODE_ON_BATTERY=1.)
And that's five. With just these five changes I actually get the battery life (under normal use) that the ad said I would.
Today I had the desire to write something down, but really didn't have a concise idea of what to write about. So this post is just going to be a small summary of some thoughts and experiences.
I recently read the RMS opinion on Codeplex and Miguel's response. After a quick glance over at planet gnome I noticed a few people taking sides and it occurred to me that the whole argument is rather silly. When I was in college the concept of free software made a ton of sense. Looking back it was because I didn't have any money, so generally anything free made a ton of sense. Now that I'm a full fledged tax paying adult, the glamour of free software has lost its glitz. It is not that free software has become unimportant or useless. What has happened, in my mind at least, is the arguments associated with free software have become rather stale. By stale, I simply mean it isn't anything exciting for me personally. I think free software is critical, but I have better things to do than care about it in its own right. I'm probably just getting old, but it was an interesting realization for me nonetheless.
At work I've been trying to improve my tests. By "improve" I really mean write them in earnest. It is a really difficult thing to write code using TDD. It is a similar approach to modeling in that it forces you to consider an abstract idea of what some code should do and look like. TDD is sort of like UML in the age of Ruby on Rails, which is kind of funny as the recent web frameworks and NoSQL all suggest rapid prototyping over planning before coding. While both UML and TDD are doing pretty much the same in terms of hashing out code, the obvious benefit of TDD is that you get something that can be used in the future. At the same time, a well tested code base is not that important if the tests are bad and are hard to run. Testing in web browsers is the most obvious case in point. The larger point then is obviously that planning, whether through tests, visio or some hodge podge of tools, is helpful for writing better code. It might also be argued that it is faster since the design is fleshed out to some extent, but I would ask if the time spent planning is included in that calculation and if it is a real calculation at all. Programmers have a nasty habit of estimating because of the constant requirement to create hypotheses in debugging. My bet is that many of the virtues of TDD (like UML as well) are overblown and the only real benefit is forcing a developer to focus on what the problem is. One of my issues is that it creates a whole new class of code that deals with testing. This is totally fine, but where are tests for the tests! It seems like a story that we'll probably never see the end of.
I'm going to suggest that if you're a programmer, it would treat you well to try out a good text web browser. My recommendation is w3m due to its Emacs integration, but anything that can keep you in your work environment works. My guess is vimmers would get similar usage from links/lynx assuming the terminal is their environment. The reason being is that if you are constantly editing text and reading it in your dev environment, browsing the web textually can be a helpful tool to keep focus. For me, I get the same keybindings, easy copy and pasting, and simpler window/frame/buffer management. Beyond this though, it feels faster when it comes to reading documentation and finding helpful code. Your milage may vary, but it sure couldn't hurt to try.
At work we recently rolled out a new system. It isn't actually new, but is in fact the latest step in an improvement to a current system. What always strikes me about the smart folks I work with is how gracefully they walk the line between system administrator and programmer. The two fields are completely intertwined, but the best programmers are those that have the better understanding of both sides. This is probably partly why I'm not that great of a programmer! For whatever reason, my mind doesn't ever seem to really indulge in the system administration side of things. It is always a challenge for me to make pre-existing software work the way I think it should. That doesn't mean I'm not trying of course! But it does mean that I have a ton to learn and will for the foreseeable future.
This past weekend was ACL in Austin and it was a blast. We saw Them Crooked Vultures, The Walkmen, School of Seven Bells, Broken Social Scene and some guys from Phoenix DJ. We also played a show with The Riverboat Gamblers and The Soldier Thread. It was a ton of fun. On the road we don't really get to hang out that much. There is usually somewhere to drive, something to load or unload or something to sell that usually keeps us busy. It was great to come home, rest and then have a great weekend of music and friends. We didn't go to ACL proper and I'm glad. There were plenty of bands I would have liked to catch but the weather was horrid and my guess is I would have been pretty miserable in the mud. Hopefully next year there will be some nicer weather. Who knows, maybe we'll even get to play!
I read email with Gnus from Gmail via IMAP, using a Labs feature that
makes Gmail behave more like a standard IMAP server. One very nice
behavior is that mail splitting in Gnus creates corresponding labels in
Gmail without my having to do anything else.
It has taken a long time, but I've finally managed to get email working relatively well in Emacs! In the end Wanderlust was the client of choice for me. It has a pretty simple file format for organizing mail and the keybindings have already begun to be rather natural. The reasoning behind my quest for merging my email and emacs had more todo with my recent tour than an actual desire or need for checking mail in my text editor. I was perfectly happy with Gmail and in fact I'm technically still using it through IMAP. The real reason was that I wanted to try and reduce my bandwidth usage. On tour I had a 5 Gig cap on my network usage. Having never really monitored this sort of thing before, I had no idea how much bandwidth things like IRC might use when you're talking about every day, all day usage. To make things worse, I forgot to grab the USB cable that would let me check my current usage for the month, so I was essentially flying blind!
My fear of an enormous bill made me consider what I could do reduce my bandwidth. The obvious avoidance of listening to music and watching videos was easy. Also, reading local versions of docs was another helpful tactic. This lead me to see a few things about w3m, which I had tried to use before in Emacs. It dawned on me that things like code examples viewed in a text based web browser makes nothing but sense in my text editor. It makes things like copying and pasting code samples a breeze. After getting used to w3m in Emacs it became clear that I should really try to finally tackle email. As I said, Gmail has been just fine, so the motivation wasn't very strong to move. The killer feature in my mind was tying things into my todo list and avoiding Gmail's constant stream of Ajax requests. I'm sure the bandwidth savings are practically nothing, but nonetheless, it seemed like if I got things working it might really be helpful in ways similar to w3m.
Once things were configured and I managed to get everything working, I did notice some helpful bits. Silly annoyances that really should never have been a problem smoothed out. I'm talking about basic copy and paste issues I noticed here and there when working with Emacs and the rest of my desktop. Little things like working with Trac was also a good deal faster, although it was something of a let down that I couldn't submit updates to tickets. Finally, it seems more reasonable to keep up with mailing lists as most of the necessary content (code) is close at hand. This last aspect seems to be the biggest draw of using Emacs. I primarily write code and keeping more tools inside Emacs makes it faster to transition between those tools and the code I'm working on. Of course it does seem kind of cool in a geeky way to work almost solely in text, but the main nicety is actually being more productive. I'm hoping in the next couple weeks things can continue to become a little more streamlined. The killer app that I would like to find a good Emacs replacement for is my feed reader. Google Reader is great but something more bare might help to move through things faster and generally filter out the cruft. That said, blogs were one of the first things I cut out in my quest to lower bandwidth. My desire to check what is new in the blogosphere has greatly diminished since taking a break. I'd like to potentially keep it that way for a while.