Tag Archives: emacs

OpenStack

OpenStack Emacs Tools

9 Comments

Over the past few weeks I’ve been tweaking my emacs configs, and writing some new modes to help with OpenStack development. Here is a non comprehensive list of some of the emacs integration I’m finding useful in developing for OpenStack (especially things that have come up in conversation). URLs provided, though I won’t walk through all configuration in depth.

tramp

Tramp is a built in facility in emacs that lets you open files on remote machines via ssh (and other protocols). This means your emacs runs locally, with all the latency gains that has, as configured as you would like, but editing can be done across multiple systems. A remote file url looks like /servername:/file/path. All the normal file completion that you expect works after that point.

I tend to do code that doesn’t need a full stack run locally on my laptop or desktop, but full stack code happens on my NUC devstack box, and tramp lets me do that from an single emacs instance.

More info about tramp at emacswiki.

fly-hack

Emacs has an in-buffer syntax checker called flymake. There are various tutorials out there for integrating pyflakes or flake8 into that. However in OpenStack we have hacking, which extends flake8 with new rules. Also, every project turns on custom ignores. Also, many projects extend flake8 further with custom rules for that repo.

screenshot_151

fly-hack uses the flake8 in the .tox/pep8 venv for each project, and uses the tox.ini config for each project, so when in Nova, nova rules will be enforced, when in Cinder, cinder rules will be enforced. Mousing over the error will pop up what it is (you can see the H306 in that screenshot). It has a fallback mode when using it over tramp that’s a reasonably sane flake8 least common denominator for OpenStack projects.

More info at fly-hack github page – https://github.com/sdague/fly-hack

stacktest

Our testr / subunit / testtools testing toolchain gets a bit heavy handed when trying to iterate on test development. testr discovery takes 20 – 30s on the Nova source tree, even if you are trying to only run 1 test. I became inspired at the Ops Summit in Philly to see if I could do better. And stacktest.el was born.

screenshot_153

It’s mostly a port from nosemacs which allows you to run tests from an emacs buffer, however it does so using tox, subunit, or testtools, depending on whether you want to run a top level target, test a file, test an individual test function, and/or use pdb. It works over tramp, it works with pdb, and it uses the subunit-trace tooling if available.

I’ve now bound F12 to stacktest-one, which is a super fast way to both iterate on test development.

More info at the stacktest github page – https://github.com/sdague/stacktest

pycscope

OpenStack is a lot of code, and uses a ton of libraries. git grep works ok in a single repo, but the moment some piece of code ends up calling into an oslo library, that breaks down.

Peter Portante, OpenStack Swift contributor, maintains a pythonized version of cscope. It parses the AST of all the files to build a quite rich symbol cscope database. This lets you search for definitions (searching down), calling points (searching up), and references (searching sideways). Which very quickly lets you dive through a code path and figure out where you end up.

screenshot_155

The only draw back is the AST parse is consuming on something as large as the Nova tree, especially if you index all the .tox directories, which I do to let myself get all the way back through the library stacks that we include.

You can learn more about pycscope at it’s github page – https://github.com/portante/pycscope

flyspell-prog-mode

Emacs includes a spell checker called flyspell. Very useful for text files. What I only learned last year is that there is also a flyspell-prog-mode, which is like flyspell, but only acts on comments and strings that are semantically parsed by Emacs. This helps avoid a spelling mistake when writing inline documentation.

screenshot_156

More information at Emacs wiki.

lambda-mode

This is totally gratuitous, but fun. There is a small mode that does a display adjustment of the word ‘lambda’ to an actual ‘λ’. It’s a display adjustment only, this is still 6 characters in the buffer. But it makes the lambda expressions pop out a bit more.

screenshot_157

More information at Emacs wiki.

The important thing about having an extensible editor is actually extending it to fit your workflow. If you are an emacs user, hopefully this will give you some fun things to dive into. If you use something else, hopefully this will inspire you to go looking into your toolchain for similar optimizations.

Software

Emacs Tip: Make CSS mode sane

Leave a comment

The default CSS mode in emacs does very funny things with indentation if you like leaving the brace on the same line as the definition. As with everything in emacs, this is fixable with a few lines of config. In this case:

 ;;; Fixes totally weird default css formatting.
 (require 'css-mode)
 (setq cssm-indent-level 4)
 (setq cssm-newline-before-closing-bracket t)
 (setq cssm-indent-function #'cssm-c-style-indenter)
 (setq cssm-mirror-mode t)

I can’t remember where I found this on the internet, but here it is, repeated again, so more folks can find it.

Uncategorized

Productivity Tip: Learn your tools

Leave a comment

At the web design meetup the other day there was a bit of chat about editors afterwards which turned into a normal geek fest of poking fun at each other for our choices. One new truth that came out of this a good editor doesn’t make someone more productive, but it does allow them to become more productive.

Vim vs Emacs

As an emacs guy, that can navigate around in vi reasonably, I’ve was always somewhat surprised that people actually use vi to program. But there are plenty of folks that hold that position, and are as equally surprised that I use emacs. Over the years I tried to look for some common thread. What makes someone choose one or the other, and hold to that choice so firmly. A few years ago I came around to the best predictor. With probably ~ 90% accuracy you can predict which editor a person will use based on what editor their mentor used when they first got serious about computers. People pick up the tools of their ancestors. What looks like free will is basically dictated by heredity.

So, that’s how you figure out which one people use. So, which one is better? The answer to that is simple, whichever one you know the best.

Tools Require Skill

There is this naive assumption that using a “better” editor will make you more productive. The answer is, maybe, but don’t stop there. If you aren’t willing to put in the time to learn how your editor is configured, take time every month to learn a new trick with your editor, give up on either vim or emacs, and go back to gedit. Learning an editor well is going to mean learning how to do very complex activities with complex key strokes. There just aren’t enough keys on the keyboard to be able to do what you want to do without combining them together.

Every couple of months I spend a bit of time to learn a few more emacs tricks. It’s hard for me to even enumerate what these are, because they are just part of my normal workflow, like water. Buffer changing, remote editing, multi language buffers, integrated source management. I am also aware of other things I could be doing, which include interactive debugger control, which don’t warrant the time and skill for me to set them up yet. But I know they are there, and I even know how I would get started in configuring them if I needed to.

Which also brings another point, if your tools themselves aren’t extensible, you will be limited in your growth. I have never met a system that I like 100%, though I’ve met many which did 98% or 99% of what I wanted. This is one of the reasons I’m a really big fan of open source. Couple 98% complete with an easy way to extend it, plus open source so you can really understand what it is doing behind the scenes, and you’ve got a winning combination.

Become Better

tldr; – If you want to be a better programmer, spend a lot of time getting to know your editor.

If you are not already deeply invested in an editor, I’d heartily recommend emacs, fire it up, then hit “F1 t” or from the menus, Help -> Tutorial. It will walk you through an interactive tutorial of basic key commands, including detecting if your local installation has changed any of the keybindings and alerting you appropriately.

If you are already invested in an editor, commit to yourself that you’ll take 1/2 a day a month, for the rest of 2011, and spend that time reading and learning about other capabilities of the editor you are using now. You’ll be a better programmer for it by far by the end of the year.

Uncategorized

Ed is the standard text editor

1 Comment

This is an old joke, but increasingly one that people haven’t seen.  Given that I stuck a vi/emacs question at the end of the mhvlug survey, I thought it would be worth reposting for posterity.  The original version is here.

When I log into my Xenix system with my 110 baud teletype, both vi and Emacs are just too damn slow. They print useless messages like, ‘C-h for help’ and ‘“foo” File is read only’. So I use the editor that doesn’t waste my VALUABLE time.

Ed, man!  !man ed

ED(1)               Unix Programmer's Manual                ED(1)

NAME
     ed - text editor

SYNOPSIS
     ed [ - ] [ -x ] [ name ]
DESCRIPTION
     Ed is the standard text editor.

—

Computer Scientists love ed, not just because it comes first alphabetically, but because it’s the standard. Everyone else loves ed because it’s ED!

“Ed is the standard text editor.”

And ed doesn’t waste space on my Timex Sinclair. Just look:

-rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
-rwxr-xr-t  4 root     1310720 Jan  1  1970 /usr/ucb/vi
-rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user’s disk quota by 100K; and 3) RUNS ED!!!!!!

“Ed is the standard text editor.”

Let’s look at a typical novice’s session with the mighty ed:

golem$ ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?

—

Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.

“Ed is the standard text editor.”

Ed, the greatest WYGIWYG editor of all.

ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

When I use an editor, I don’t want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren’t even WORDS!!!! ED! ED! ED IS THE STANDARD!!!

TEXT EDITOR.

When IBM, in its ever-present omnipotence, needed to base their “edlin” on a Unix standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.

Ed is for those who can remember what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED “VISUAL” EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!

?

Uncategorized

Remotely editing files securely with emacs

Leave a comment

A long time ago I used the built in ftp support for emacs to be able to remotely edit files on another system.  This gave me all the convenience of a local editor (especially on slower links), with the ability to do edits right in place on other systems.  On whim I did a quick search to see if there was a way to do this over an encrypted session while trying to fix some php templates.

Low and behold, there is.  It only takes the following 2 lines in your .emacs file:

(require 'tramp)
(setq tramp-default-method "scp")

Then you just open /servername:directory.  Relative directories base off your home dir, absolute do what you would expect.  This is just far too handy, and I can’t believe I’ve gone this long without knowing about it.

Uncategorized

The switch from xemacs -> emacs

Leave a comment
I’ve always felt the root of the emacs vs. vi holy war (which is one of the longest standing holy wars in free software) basically came down to the following key point:

When you first were learning Linux / Unix, did your mentor use vi or emacs?

The answer to that is at least 90% correlation to your preferences. Much like most people share the politics of their parents, most people share the editor preferences of their mentors. Switches don’t tend to happen unless mentors switch as well.

And in that camp, I’m an emacs guy. I learned it in college when I took my first programming class (which was in lisp). Our professor gave us a starting .emacs file, pointed us at the tutorial, and built macros that helped us out in our efforts.

A near decade with XEmacs

Then I graduated from college, and my first mentor at IBM was also an emacs guy, except he was an xemacs guy. It was emacs, but prettier. So I piled on, and was there ever since. Over the years I tried a couple of times to go back to emacs, but their font handling was never as good. I love programming in arial, as it’s just really pleasant on the eyes (this shocks and horrifies people that line up = signs in declarations, but I don’t much care. 🙂 ).

A few years ago, just as emacs was getting reasonable variable width font support, xemacs integrated anti-aliased fonts into their CVS tree, and now I had another reason to stay on xemacs, because now everything looks pretty. Using xemacs was sometimes a pain, as a number of modes didn’t really work right on it. I never had a reasonable html mode working that did indentation like I wanted.

Steve Yegge’s Rant

Last month Steve Yegge had a post entitled Xemacs is Dead, Long Live Xemacs which was basically a call to unify around emacs because it had finally caught up, and it is being very actively maintained. I was skeptical, but decided to try again. Using the Ubuntu packages I lost my anti-aliasing, which meant this was a failed experiment.

But, after some research, I realized that emacs cvs not only has xft support in the tree, but that since March it’s been the default. This is what will be emacs 23. I was already running xemacs out of cvs, so taking the same leap with emacs cvs wasn’t such a big deal.

It’s taken a couple of weeks to tweak my configuration to get me the same, or better, results with emacs as I had with xemacs. Last night I finally understood what I needed to get nxhtml to do my html.erb files correctly (ruby and html bits independently highlighted, and mode switching automatically when moving between code blocks). Minus 1 font issue with planner, I can definitely say I’m fully converted.

I’m also enjoying diving into elisp again. For whatever reason, life seems a bit more stable on emacs than it did on xemacs. And once emacs 23 actually makes it to distros, I won’t even need to have my own binary builds. 🙂