mercurial/crew at 13301: 6 outgoing changesets

Martin Geisler mg at aragost.com
Thu Jan 27 03:55:19 CST 2011


Adrian Buehlmann <adrian at cadifra.com> writes:

> On 2011-01-27 08:59, Martin Geisler wrote:
>> Matt Mackall <mpm at selenic.com> writes:
>> 
>>> On Wed, 2011-01-26 at 13:00 +0100, Mercurial Commits wrote:
>>>> http://hg.intevation.org/mercurial/crew/rev/613b8bd2284e
>>>> changeset:   13297:613b8bd2284e
>>>> user:        Martin Geisler <mg at aragost.com>
>>>> date:        Wed Jan 26 12:05:01 2011 +0100
>>>> summary:     specify C indention style using Emacs file local variables
>>>
>>> Yuck.
>
> Agreed. I was close to send an email it about myself.
>
> Near as I can tell, neither the Linux kernel sources nor the C sources
> for CPython do something similar.

What does that have to do with anything?

>> Why don't you like this? This style is something that is (somewhat)
>> enforced by check-code and so I find it very natural that the files
>> themselves specify the necessary settings for common editors.
>
> Depends on the definition of common. My editors here I use don't know
> about the comment blocks you inserted and I doubt common editors on
> Windows do so.

Well, if they support something similar, then let's insert a comment for
them too. I did actually search a little to find the equivalent modeline
for vim -- in order not to be too Emacs-centric.

Accept it or not, but Emacs and vim are common editors. This is also why
you specify the file encoding of a Python file (PEP 263) with

  coding[:=]\s*([-\w.]+)

so that this works for Emacs:

  # -*- coding: <encoding name> -*-

and this works for vim:

  # vim: set fileencoding=<encoding name> :

>> Yes, that might work, but why require everybody to do that when we
>> can solve it out of the box with file variables?
>
> Because not everybody likes to have to look at these ugly comment
> blocks in the sources?

I don't see why you find them ugly? Will you argue this point?

I will argue they are good and unobtrusive: they serve a very simple and
useful purpose. They sit discretely at the bottom of the files where you
will mostly likely never notice them.

> Let's simply revert this change and move on, so we can do something
> more interesting.

I've been working on a C extension lately and I find it very nice that
the Mercurial code now informs my editor about the desired layout. It is
a good change for me.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/


More information about the Mercurial-devel mailing list