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