I'm happy to announce the release of Patcher version 4.0. This is a major release introducing many new features and enhancements.

Patcher is a tool designed to automate and ease the maintenance of archive-based projects. It provides assistance in building, reporting and committing patches, as well as in handling the corresponding ChangeLog entries, for example by creating skeletons. Patcher is the official tool for XEmacs development.

NEW FEATURES

• Support floating projects and temporary relocation allowing to use the same project descriptor for various directories.
• Support for automatic detection of submodules via the :submodule-detection-function project option and the patcher-detect-submodules function. Currently supported RCS submodules are Mercurial and Git via the functions 'patcher-hg-detect-submodules.
• Support ephemeral ChangeLogs thanks to a new :change-logs-status project option. Ephemeral ChangeLogs are not stored in ChangeLog files, but exist only temporarily for mail or log message insertion (See ChangeLogs Status in the documentation).
• ChangeLog minor mode providing easy navigation through the mail/ChangeLog buffers cycle via C-c C-p n, C-c C-p p, C-c C-p N, C-c C-p P and C-c C-p m (See ChangeLogs Navigation in the documentation).
• Support for switching to mail buffer and inserting ChangeLogs at once via C-c C-p l from ChangeLog buffers.
• patcher-mail-insert-change-logs gets a prefix argument allowing to temporarily change the ChangeLogs appearance. It also supports inserting ChangeLogs even when the project is set not to.
• Additional binding for patcher-logmsg-commit: C-c C-p c
• Commit command buffer is now editable Commit is done via C-c C-p c or C-c C-c (patcher-cmtcmd-commit).
• Fontification of commit command and log message buffers with comment syntax and initial informative help. See new Patcher faces.
• Support for commit or log message canceling via C-c C-z.
• Support for project abortion via C-c C-p k or C-c C-k in all relevant buffers, including ChangeLogs.
• Support Subject: header modification in mail adaptation routines via a new project option :subject-rewrite-format.
• Support project-wide dynamic subject modification via C-c C-p S in both mail and log message buffers.
• Implement :kill-source-files-after-sending project option
• Support for source file saving
• Support for CVS diff's broken exit code policy via a new project option: :ignore-diff-status.

FIXES AND IMPROVEMENTS

• Improved support for temporary subprojects making them behave like permanent ones (with a specific subdirectory and set of files).
• Much better error handling including exit code checking for external processes.
• Improved support for overlapping Patcher instances through buffer and file referencing for both ChangeLog and source files.
• Documentation rewrite and sections organization cleanup
• More checks for project consistency including missing or spurious ChangeLog entries, source diffs, undiffable and uncommittable projects etc.
• Improved project rediffing including support for partially generated ChangeLog skeletons, and interactive prompting for skeleton un/re-generation.

BACKWARD INCOMPATIBLE CHANGES

• Mercurial themes renamed from 'mercurial to 'hg in order to remain consistent with the other RCS theme names.
• ChangeLogs insertion in mail buffers rebound to C-c C-p l
• Compressed ChangeLogs insertion in logmsg buffers rebound to C-c C-p L
• Removed directory-sep-char hacks until the need for it raises again. Probably better implemented via project options anyway.
• Diff commands can no longer be changed from patcher-mail-adapt but instead, the prefix argument allows for temporary subproject specification.
• patcher-*-subproject entry points removed since they are no longer needed (see above).
• Removed :kill-source-file-after-diffing option
• :kill-source-files-after-sending renamed to :kill-sources-after-sending
• patcher-mail-check-change-logs-insertion is now a project option named :check-change-logs-insertion.
• patcher-mail-check-commit-action is now a project option named :check-commit.
• :change-logs-diff-command option now understands nil instead of 'diff
• The 'packed ChangeLogs appearance has been renamed to 'pack

Here's another new face property in XEmacs. This one is probably not going to be used ever, but still it fixes one particular problem. Until now, XEmacs used the background and foreground colors to display a face background bitmap (as opposed to a regular pixmap). This basically rendered the text unreadable.

The new face property is called "foreback" (I'm running short of sensible property names these days). It's the "foreground of the background" if you will. When a face has a background bitmap, it uses the regular background color for bitmap's background, but the foreback color for the bitmap's foreground. See the attached screenshot for a concrete example of the problem it fixes.

The bitmap I used for this example is X11's xsnow bitmap. Nice Christmas XEmacs screenshot, isn't it? :-)

In order to set a face's foreback color, either use the Custom interface, or the set-face-foreback function.

Just a quick note to mention the release of CL-RCFiles 2.0. This version adds pre-loading initialization files. From the README file:

This very small Common Lisp library provides a way to add initialization files to ASDF systems. Every time ASDF loads <system>, one or several corresponding <system>.lisp files are loaded automatically afterwards. This lets you conditionally plug in additional behavior on a per-system basis without cluttering up any global Common Lisp init file.

By default, these initialization files are expected to be found in: - ~/share/common-lisp/rc/pre/ for pre-loading initialization, - ~/share/common-lisp/rc/post/ for post-loading initialization.

For backward-compatibility, files found directly in the rc/ directory are considered to be post-loading initialization files.

You can modify the rc-files location by changing the values of the global variables *directory*, *pre-directory*, and *post-directory*.

Get it here.

John McCarthy, the creator of the most elegant and powerful language ever, has died. I won't repeat what others in the Lisp community are and will be saying all over the place in the next few days. There is only one thing I would like to say right now: I remember him, and I am very happy (for him) that he was still here with us to celebrate the 50th anniversary of his wonderful baby...

EDIT: the paper is now freely available for non TUG members.

I'm happy to announce that my contribution to TUG 2011, the next TeX Users Group International conference, has been accepted. Please find the title and abstract below.

Towards LaTeX Coding Standards

Because LaTeX (and ultimately TeX) is only a macro-expansion system, the language does not impose any kind of good software engineering practice, program structure or coding style whatsoever. As a consequence, writing beautiful code (for some definition of "beautiful") requires a lot of self-discipline from the programmer.

Maybe because in the LaTeX world, collaboration is not so widespread (most packages are single-authored), the idea of some LaTeX Coding Standards is not so pressing as with other programming languages. Some people may, and probably have developed their own programming habits, but when it comes to the LaTeX world as a whole, the situation is close to anarchy.

Over the years, the permanent flow of personal development experiences contributed to shape my own taste in terms of coding style. The issues involved are numerous and their spectrum is very large: they range from simple code layout (formatting, indentation, naming schemes etc.), mid-level concerns such as modularity and encapsulation, to very high-level concerns like package interaction/conflict management and even some rules for proper social behavior.

In this talk, I will report on all these experiences and describe what I think are good (or at least better) programming practices. I believe that such practices do help in terms of code readability, maintainability and extensibility, all key factors in software evolution. They help me, perhaps they will help you too.

Sometimes, I miss the string concatenation capability of C. I mean, the way that you can split a long string into smaller ones and have them automatically concatenated together. The format function has a tilde (~) directive that does something along these lines, but there are two problems:

• first, I'm not necessarily facing the problem in format calls,
• next, my favorite text editor cannot properly indent the string contents when I press the TAB key.

Here's an example:

(defclass sample ()
  ((slot :documentation
	 "A very long slot documentation, that doesn't even fit in 80 columns, which is a shame...")))

If that were C code, I could write this:

(defclass sample ()
  ((slot :documentation
	 "A very long slot documentation, "
	 "that doesn't even fit in 80 columns, "
	 "which is a shame...")))

But (thank God) this is not C code. We can come very close to that however. Here's a small reader function that will automatically concatenate strings prefixed with a tilde (~) character (in honor of format's directive):

(defun tilde-reader (stream char)
  "Read a series of ~\"string\" to be concatenated together."
  (declare (ignore char))
  (flet ((read-string (&aux (string (read stream t nil t)))
	   (check-type string string "a string")
	   string))
    (apply #'concatenate 'string
	   (read-string)
	   (loop :while (char= (peek-char t stream nil nil t) #\~)
		 :do (read-char stream t nil t)
		 :collect (read-string)))))

Let's add it to the current readtable:

(set-macro-character #\~ #'tilde-reader)

And now I can write this:

(defclass sample ()
  ((slot :documentation
	 ~"A very long slot documentation, "
	 ~"that doesn't even fit in 80 columns, "
	 ~"which is a shame...")))

Everyday of my life I thank Common Lisp for being so flexible. The next step would be to make cl-indent.el aware that tilde-strings really are the same object, and hence should be vertically aligned in all contexts. I'm not there yet. Jeeze, this indentation hacking will never end... :-)

It's been two months since ELS 2011 is over and I didn't have the time to give my impressions as the programme chair until now. I still don't have much time, so it's going to be quick, but before that, here are two announcements in this transition phase:

• the proceedings are now available as a single PDF file.
• eventhough a couple of options are already under consideration, we are still looking for volunteers to be next year's local chair. If this is of interest to you and you have the ability to locate ELS 2012 at your place, please contact us.

About ELS 2011 now. I'd say that it was a great success, perhaps the most successful of the 4 occurrences. We got two full days of interesting talks on various topics and of different forms. We gathered more than 60 persons from all around Europe and also a quite a few from the US (ITA contributed greatly to that :-). The final panel was very nice (something quite rare these days). The local organization went also pretty smoothly.

In retrospect, and as the person in charge of the contents, I have several hypothesis on what makes such an event successful, especially in those days where academic events suffer from a decreasing level of attendance.

1. Having a "special focus" helps. Having an important one (like Parallelism and Efficiency) helps even more.
2. Having a regularly occurring event also helps a lot, especially for academicians. This is not new, but it really is important to know that ELS will always happen roughly at the same period every year. Academicians (at least) need to plan their work that long in advance.
3. I also like more and more the formula of a "mixed" conference where you invite formal (technical) papers, demonstrations, position papers etc. Some people know how to write technical papers, some people don't, are not so good at it, or just don't have the time for it, but it doesn't mean they have nothing interesting to say. ELS 2011 had about 50% formal presentations and 50% demonstrations. I decided to create the different sessions not by grouping talks based on format, but based on topic, and I think this went pretty well. The sessions didn't look completely heterogeneous to me.
4. Having invited speakers helps. This is of course not new at all, but here, I would just like to answer something I've read recently about ELS 2011; a blogger (I don't remember who) saying that he didn't understand why 2 out of the 3 guests were not speaking about Lisp at all. My opinion on this is simple: as a community (in general; not speaking of Lisp in particular), we have a tendency to be separated from the rest of the CS crowd and loose track of what's going on next door. We don't talk to each other enough. Hell, it's already so difficult to stay up-to-date with your own crowd sometimes! So when I attend a very focused conference, like a language-specific one, I'm always happy to be served a couple of talks that can broaden my view of things, even if they have no direct connection with my own activities. In our specific case, I was very happy with Craig Zilles'presentation and I can see how this could be of interest to us in the long term.

So, that's it for now. Stay tuned for next year's location, and in the meantime, remember that some other Lisp events are already planned: ECLM in Amsterdam, and ILC in Kyoto... simply my favorite place in the world!

UPDATE: since the original publication of this blog entry, Nikodemus Siivola and I have done some more work on various other aspects of Common Lisp indentation, and I must say that the result is pretty satisfactory. Nikodemus has merged all the changes into Slime, and I have done so for XEmacs. If you're an XEmacs user, you don't need to use the slime-indentation contrib to get these improvements. Simply upgrade the "prog-modes" package and load cl-indent.el.

I have just modified XEmacs to improve the indentation of Common Lisp code. This change involves two things: the support for multiple method qualifiers in a call to defmethod and, much more importantly, a cleaner and more flexible scheme for indenting lambda lists. The patch has also been submitted to the GNU Emacs developers. Below is a more detailed description of what you get with these changes.

Method qualifiers

Until now, only one method qualifier was understood. Below are some examples demonstrating that the one method qualifier and the argument list are indented by 4 characters, and the method's body only by 2:

(defmethod foo :around ()        (defmethod foo :around
  do-this)                           ()
                                   do-this)
(defmethod foo
    :around ()                   (defmethod foo
  do-this)                           :around
                                     ()
                                   do-this)

Now let's add a second method qualifier:

(defmethod foo comb :around ()        (defmethod foo	    
	   do-this)		          comb :around () 
				          do-this)

Woops. Neither is correct. But now, you get this instead:

(defmethod foo comb :around ()        (defmethod foo	    
  do-this)			          comb :around () 
				        do-this)

Three more examples to show how confused we were:

(defmethod foo comb :around     (defmethod foo comb     (defmethod foo 
  ()				    :around	   	    comb       
  do-this)			  ()		   	    :around    
				  do-this)         	  ()	       
							  do-this)

And how better we just got:

(defmethod foo comb :around     (defmethod foo comb     (defmethod foo
    ()			   	    :around	   	    comb      
  do-this)		   	    ()		   	    :around   
				  do-this)         	    ()	      
							  do-this)

Indeed, you can see that everything between the method's name and its body is now correctly indented by 4.

Lambda Lists

The next round of changes deals with the formatting of lambda-lists. As such, this will apply everywhere a lambda-list is expected, such as defun, defgeneric, defmethod etc. First of all, here are two examples showing that we were not very clever before:

(defun foo (mand1 mand2
	    &optional opt1
	    opt2
	    &rest args
	    &key key1 key2
	    (key3 val3) &aux aux1
	    aux2)
  do-this)

(defun foo (mand1 mand2 &optional opt1
	    opt2
	    &rest args
	    &key key1 key2
	    (key3 val3) &aux aux1
	    aux2)
  do-this)

Basically, everything was blindly aligned at the beginning of the lambda-list. Here is what you get now:

(defun foo (mand1 mand2
	    &optional opt1
	      opt2
	    &rest args
	    &key key1 key2
	      (key3 val3) &aux aux1
			    aux2)
  do-this)

(defun foo (mand1 mand2 &optional opt1
			  opt2
	    &rest args
	    &key key1 key2
	      (key3 val3) &aux aux1
			    aux2)
  do-this)

The difference is that keyword parameters are indented with respect to their corresponding keyword. The amount of indentation is provided by a new customizable user option named lisp-lambda-list-keyword-parameter-indentation (oh boy, what a mouthful). If you prefer, you can also have the parameters vertically aligned with each other. Set the new customizable user option named lisp-lambda-list-keyword-parameter-alignment to t and you will get this instead:

(defun foo (mand1 mand2
	    &optional opt1
		      opt2
	    &rest args
	    &key key1 key2
		 (key3 val3) &aux aux1
				  aux2)
  do-this)

(defun foo (mand1 mand2 &optional opt1
				  opt2
	    &rest args
	    &key key1 key2
		 (key3 val3) &aux aux1
				  aux2)
  do-this)

Finally, just as you could align keyword parameters together, you can also align the keywords together. Set the new customizable user option named lisp-lambda-list-keyword-alignment to t, and you will get this (only the second example differs):

(defun foo (mand1 mand2 &optional opt1
				  opt2
			&rest args
			&key key1 key2
			     (key3 val3) &aux aux1
					      aux2)
  do-this)

These are in fact my preferred settings, although both alignment options default to nil. Here is a final example demonstrating how you could format a long lambda-list with plenty of arguments:

(defun foo (mand1 mand2
	    &optional
	      opt1 opt2 opt3
	    &key
	      key1 key2 key3
	    &aux
	      aux1 aux2 aux3)
  do-this)

These indentation problems have been a huge peeve of mine for quite a long time. I hope you will find the changes useful!

At long last, there is a new release of XEmacs 21.5. A lot of stuff has happened in this release, but the most important thing is that this is the last GPLv2 version of XEmacs. Future versions (including the current trunk) will be licensed GPLv3 or later. In fact, the first GPLv3 release, 21.5.31, is expected to follow this one by a couple of days. Thanks mostly to Aidan Kehoe, I'm also quite happy that XEmacs Lisp is more Common Lisp'y than ever.