Search posterous

Search all posts and users. Type a name, type a favorite song title, whatever! See what comes up.
  

More posterous blogs











More recommended blogs »

Here are posterous posts filed under emacs...

Paul says...

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.

Filed under: emacs

elarson says...

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.

Filed under: emacs

amnorvend says...

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.

I'll assume you're running Ubuntu. Also, not all of these are Python
specific. But I feel that they will be useful to most Python
programmers who use emacs.

I should also note that (like most emacs users), most of these things
are tricks that I've picked up from various sources along the way. If
you wrote something that I put in here, thanks!

Ropemacs

Ropemacs is among the tools I love the most and hate the most. When
it works, it opens up a new world of automated refactorings for you.
But it seems to be a bit buggy at times. That said, setting it up is
really easy. Firstly, you need to have ropemacs installed. This is
pretty easy:

 
sudo apt-get install python-ropemacs 

After that, just a couple of lines of elisp in your .emacs file and
you're good to go!

 
(require 'pymacs) 
(pymacs-load "ropemacs" "rope-") 
(setq ropemacs-enable-autoimport t) 

Anything

Anything is almost like Quicksilver for emacs. To begin, you need to
download anything.el and anything-config. I also use 
anything-match-plugin. Then you just need the following lines of elisp:

 
(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!

Line number mode

When you're pair programming, nothing is more helpful than being able
to direct people to a certain line of code. This lets you spend less
time saying "hey, see that over there? It's about 3 lines up. No,
too far! go down another two lines." Installing this is really easy.
You just need linum.el and two lines of elisp:

 
(require 'linum) 
(global-linum-mode 1) 

Flymake through pyflakes

In case you miss the automatic error highlighting of the Visual Studio
world, you should realize that emacs has a similar system built-in.
It's called flymake. And you can make it work with Python as well. I
personally prefer to use pyflakes for this. All that's needed is
pyflakes:

 
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))) 

Uniquify

How many __init__.py buffers do you have open at this moment? If
you're using emacs for Python programming, probably a lot. This is
where emacs's uniquify functionality is useful. It gives you a more
useful name for your buffers other than just appending a number at the
end. I have mine use the reverse of the directory. For instance, if
I have foo/__init__.py and bar/__init__.py open, they will be named
__init__.py/foo and __init__.py/bar respectively.

You just need this in your .emacs:

 
(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) 

python-mode

To be totally honest with you, I haven't used the built-in emacs mode
for python. I just installed python-mode because I was told it was
better. What I can tell you is that there is an occasional plugin
that requires python-mode. Installing it is easy. Just install
python-mode:

 
sudo apt-get install python-mode 

And 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)) 

Pylookup

Pylookup is useful for those moments when you find yourself asking
something like "Is join in os or os.path?" Unfortunately, the setup
can be complex, but well worth it. There are instructions here.

     
Click here to download:
7_tools_for_working_with_Pytho.zip (49 KB)

Filed under: emacs

Christian says...

In this post I'll cover the setup I use for developing my Compojure/GAE app.

Emacs
Of course you can use any editor you like to edit your source code, but Emacs has some great features for editing Lisp code that make developing in Clojure a pure joy. When properly set up, you can add new or modify existing code and inspect all your data while the application is running.

I followed the instructions at http://technomancy.us/126 to set up Slime/Swank for Clojure and it worked flawlessly without any modifications. I can also recommend the Emacs Starter Kit that is mentioned in the above post.

Clojure
There are several options for getting the clojure.jar that you'll need:

Compojure
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.

Compojure has a few dependencies. You can download a zip file containing all needed jars (including clojure.jar and clojure-contrib.jar) from the download link above, or you can just run ant dep, which will download the zip for you.

Google App Engine SDK
Download the latest GAE SDK from http://code.google.com/intl/de-DE/appengine/downloads.html. Choose the SDK for Java and unzip it somewhere.

In the next post I'll create a simplistic Hello World Compojure app.

Filed under: emacs

ssiva says...

The bash shell is got some nice key bindings that are of great use when you just get familiar with those. When you are an emacs user, you will find these bindings so emacs-intrinsic. These key bindings are configured through bind command that defines how readline is interpreted. In case if you are interested to know the current key bindings, type "bind -P or bind -p", which would give you the key bindings list. Here there are few easy to remember, yet sophisticated key bindings:

M stands for meta key (ALT)

C-a - Move to the beginning of the line
C-e - Move to the end of the line
C-f, C-b - Move one char forward and backward respectively
M-f, M-b - Move one word forward and backward respectively
C-l - Clear the screen
C-r, C-R - Search command history backward
M-backspace, C-u - Delete the whole thing you just types
C-k - Delete forward from cursor
C-t - Transpose chars
M-t - Transpose words
M-u - uppercase the chars from cursor
M-l - lowercase the chars from cursor
M-c - Capitalize the
C-/ - Undo
C-p, C-n - Recall previous/next commands from history
M-< - Beginning of history
M-< - End of history

More info available in man pages of readline, set and bind. Peteris Krumnis had compiled nice cheat sheets on bash+vi and bash+emacs.

Filed under: emacs

Paul says...

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.)

Filed under: emacs

Paul says...

(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.

 

 

Filed under: emacs

elarson says...

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.

Free Software and Open Source

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.

Test Driven Development

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.

Text Browsing

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.

Administering Systems

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.

ACL Wrap Up

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!

Filed under: emacs

Paul says...

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.

But some things are still weird. I stumbled over one yesterday. If you
tell Gnus to split a message into a group that has the same name as an
existing label in Gmail, & if you haven't told Gmail to make that label
visible in IMAP, the message disappears from Gmail—at least temporarily.
This happened to me yesterday. I thought it was gone—it wasn't in All
Mail or Trash or anywhere—but now it's back, and in the correct group.
My guess would be that Gnus still had it cached and added it back.
Weird.

Filed under: emacs

elarson says...

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.

Filed under: emacs