Hi,

in the course of checking the code for call-interactively (I have a
tendency to read code rather than the documentation), I felt a bit
like coming upon an obfuscated C contest.

I attach a patch (untested though) that does nothing except hopefully
get a more readable code.

Ok, so we are in freeze anyway, so tampering with any code that works
by replacing it with code designed to be completely equivalent is
probably not worth the potential trouble.

At what stage of development (if at all) should such janitorial
changes be usually applied?

And are there others that would agree with my assessment concerning
the readability here, or that would have even better ideas how this
would be expressed more obvious?

On a completely different tangent: wouldn't it be much more readable
(though likely not completely correct in some perverse manner) if
diff-mode actually had its TAB positions in column 9,17,25... instead
of the customary 8,16,24...?  At least in context and unified diffs,
that would _much_ better reflect the relative indentation of the
actual change than the current behavior.

It does not look like `tab-width' can be made to do that, but maybe
one could use a display property in order to move the information of
column 0 into the fringe.

But it would probably be saner if tab-width were extended to allow,
say, a cons-cell of initial offset and tab-width.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum