I forked php-mode. I don’t have anything major planned, but I fixed the fontification of docblock comments.

I added PHPUnit support to test-case-mode. Consider phpunit-el deprecated.

There are a couple things missing vs. phpunit-el, some of which may need some changes to test-case-mode.

I currently have two problems with DLV:

1. It takes a lot of code to set anything. Here’s a very simple example that makes all files opened under a subdirectory read-only:

   (dir-locals-set-class-variables 'read-only
                                   '((nil . ((buffer-read-only t)))))
   (dir-locals-set-directory-class "~/Library/Preferences" 'read-only nil)
       

2. Many of my variables need to be set to paths of files within the base directory. As an example, phpunit-program needs to be $ROOT/bin/phpunit. This doesn’t map well onto the class/directory split of DLV; I have to define a class for every directory, since the values are dependent on the path. You also end up duplicating a lot of long paths inside the directory-class.

Here’s my current solution, dir-locals.

(defmacro absolute-dirname (path)
  "Return the directory name portion of a path.

If PATH is local, return it unaltered.
If PATH is remote, return the remote diretory portion of the path."
  `(cond ((tramp-tramp-file-p ,path)
          (elt (tramp-dissect-file-name ,path) 3))
         (t ,path)))

(defmacro dir-locals (dir vars)
       "Set local variables for a directory.

DIR is the base diretory to set variables on.

VARS is an alist of variables to set on files opened under DIR,
in the same format as `dir-locals-set-class-variables' expects."
       `(let ((name (intern (concat "dir-locals-"
                                    ,(md5 (expand-file-name dir)))))
              (base-dir ,dir)
              (base-abs-dir ,(absolute-dirname dir)))
          (dir-locals-set-class-variables name ,vars)
          (dir-locals-set-directory-class ,dir name nil)))

It takes two arguments, a directory and a list of variables. The directory-class is autogenerated, so you don’t need to worry about it. Here’s how you’d use it:

(dir-locals "~/Projects/hello-world"
            '((nil . ((user-mail-address . "ian@foo.com")))))

Much better.

Within your varible list, you have two special variables you can use: base-dir and base-abs-dir. These contain the root of the directory the variables apply to, and the local directory part of that, respectively.

We need this because of the way Emacs invokes processes. If you’re visiting a remote file, Emacs will spawn external processes on the remote system. To set a DLV for a remote file, the root needs to be in the form /ssh:user@host:/path/to/root. If you try to invoke a program like that, it won’t work; you need just the directory part of the path, and this is what’s available in base-abs-dir.

On the other hand, if you want per-project TAGS files, you’ll need the full path to the remote system.

Here’s how you’d use it:

(dir-locals "~/Projects/hello-world"
            `((nil . ((user-mail-address . "ian@foo.com")
                      (tags-table-list . '(,(concat base-dir "/TAGS.gz")))))
              (php-mode . ((phpunit-program . ,(concat base-abs-dir
                                                       "/bin/phpunit"))))))

The important thing to note here is the different syntax used for the variables. Rather than using a regular quote, we use a backquote, and a comma where the special variables are used.

And that’s that. Now I have one-(or two-)line setting of variables, with access to the base directory.

I prefer the yasnippet way because it uses fields in the snippet. The default way prompts you for values in the minibuffer with read-string, which I dislike. It also overrides my preferred behavior, and there’s no option to disable it.

Of course, there’s always a way in Emacs, and it can be removed with this code:

(let (python-mode-abbrev-table)
  (require 'python))

Which is simple and works, though I dislike it. I prefer to tweak behaviors with eval-after-load, since requires can be slow. Unfortunately, by the time that code executes, the damage is done.

I’ll update if I find a better way to fix it.

There are a lot of reasons, but I think the main one is that it’s such a pioneering and influential language, and most people aren’t aware of it. An astonishing number of language features we take for granted owe their existence to Lisp.

• The switch statement. In lisp, this works like so:

  (cond
      ((= var "foo")
       (message "This is the foo block."))
      ((= var "bar")
       (message "This is the bar block."))
      (t
       (message "Default case")))
  

  This is equivalent to the following code in C:

  switch (var) {
      case "foo":
          printf("foo block.");
          break;
  
      case "bar":
          printf("bar block.");
          break;
  
      default:
          printf("Default case")
  }
  

  As you can see, they both have advantages and disadvantages:

  • The lisp version is more succinct.
  • In lisp, you can test for any condition, whereas C only lets you test one expression. This is a wash, since if you want multiple tests on the same expression, you have to repeat it throughout the (cond).
  • There’s no way to fall through in lisp like there is in C.
  • …But, your condition can be an expression in Lisp, rather than a simple test for equality, so your condition could be (cond (or "foo" "bar"))
  • As a commenter points out, you can use switch(true) to test more complex expressions in your cases. While this works, it feels pretty hacky.
• Lambda functions. One of the fundamental building blocks of Lisp, lambdas have gained widespread adoption in modern languages like JavaScript, PHP, Python, Perl, Visual Basic, Ruby, and C#.
• Hand in hand with lambdas, functions are data. That is, you can pass a function to another function. A function can return a function. Using lambdas, a function can create an entirely new function, return it, and it may be passed to yet another function.
• Closures. In a nutshell, closures give you a private, inherited namespace. So if your parent closure defines a variable x = 5, and you create a closure inside it, you also can see that x = 5. If your closure changes that to x = 50, that is invisible to your parent closure, but visible (in the same way) to any closures that closure creates. Essentially, it’s a private copy-on-write namespace. Closures were first implemented in Scheme, a Lisp-descended language. Before that, the let expressions gave some of the flexibility of closures.

  (defun print-foo ()
      (message foo))
  
  (setq foo "Foo")
  ;; Calling (print-foo) will print "Foo".
  
  ;; Inside the let block, 'foo is changed to "bar".
  ;; Evaluating this prints "Bar".
  (let ((foo "Bar"))
      (print-foo))
  
  ;; This prints "Foo" again
  (print-foo)
  

• Dynamic programming. With fset, you can change any function. Common Lisp adds flet, which works the same as let, but on functions. So you can change how library code works at an extremely deep level, but keep those changes out of the way of other code which expects the stock behavior.
• Data is code. This is an extremely powerful concept, and it’s been seen more recently in JSON. The basic idea is that you leverage the language parser to parse complex data structures, rather than writing your own parser.

  '((item-one . (foo bar ))
    (item-two . (baz quux)))
  

  This is equavalent to

  {
      "item-one": ["foo" "bar"],
      "item-two": ["baz" "quux"]
  }
  

  In other words, your data is expressed in the same literal notation as if it was in your code.

• And-or trick. At least Python and Ruby have copied this feature. In Lisp, boolean expressions don’t evaluate to true or false; rather, they evaluate to the portion of the expression causing the test to pass or fail. This sounds much more complicated than it really is. Here’s are some sample expressions:

  0 || 99;
  

  In C, this will return TRUE; The zero is considered false, and non-zero is true. Since the condition is true, true is returned.

  (or nil 99)
  

  The same test in lisp. Rather than return t (Lisp’s equivalent to C’s TRUE), this expression returns 99. The value 99 is what caused the expression to terminate, so it’s value is returned.

  It’s hard to understand the power of this at first, but consider the case where you want to assign the variable x the value of variable a if it is not false, or b otherwise. In C, you have:

  if (a) {
      x = a;
  } else {
      x = b;
  }
  

  Not very elegant. You can use the ternary syntax, where it becomes:

  x = a ? a : b;
  

  This is better, but note how you have to repeat the a variable twice. Contrast this with the lisp version:

  (setq x (or a b))
  

  No repetition. While it’s actually longer than the C version in this simple example, you gain much benefit when you use more complex expressions, such as ones where you want to assign the return value of a function if it’s true. In C, you’re stuck with calling the method twice, or assigning it’s output to a variable before the test.

  In Python, you’d use:

  x = a or b
  

• References. Lisp’s basic data structure is the linked list. What’s interesting is how they’re managed. Lisp lists are constructed from cons cells, where the first half (the car)points to the data for that cell, and the last half (the cdr, pronounced "coulder") points to the next cell; the last cell in the list has a null pointer. The really neat part of this is that everything is a pointer. So every member of a list exists on it’s own, and other lists are free to point to it. Consider this:

  ;; This sets 'ex to a two-element list: (foo bar)
  (setq ex '(bar baz))
  
  ;; This creates a new list 'ey; the first cell is 'foo, and the rest of the
  ;; list is the contents of 'ex.
  ;; Evaluating 'ey will show: (foo bar baz)
  (setq ey (cons 'foo ex))
  
  ;; This sets the first element of 'ex to quux
  (setcar ex 'quux)
  
  ;; Evaluating ex now produces: (quux bar)
  ;; Evaluating ey produces: (foo quux bar)
      

  This works because ey’s cdr points to ex; it hasn’t copied ex, it’s incorporated it by reference.