lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use directory-local variables to establish some coding styles in Ema


From: David Kastrup
Subject: Re: Use directory-local variables to establish some coding styles in Emacs (issue 6460109)
Date: Mon, 20 Aug 2012 08:28:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

John Mandereau <address@hidden> writes:

> Il giorno lun, 20/08/2012 alle 00.39 +0200, David Kastrup ha scritto:
>> The only reasonable way to address the amount and kind of concerns
>> voiced here is not to apply the patch.  Instead, one should likely
>> explain in CG how to use M-x add-dir-local-variable RET to achieve its
>> equivalent.  In that case, nobody will have his Emacs' behavior get
>> silently changed from under him to obey LilyPond coding standards while
>> inside of LilyPond source directories.
>> 
>> It may also be feasible to add a lengthy explanation to the CG that on
>> sufficiently new Emacs versions, the coding standards might be obeyed
>> automatically on some points.
>> 
>> Writing a treatise of that kind is quite beyond the scope of the
>> original patch.  Analyzing the effect of reformatting the whole Scheme
>> directory with Emacs' default Scheme indentation, whether or not using
>> tabs, is also wildly outside of the scope of the patch.
>> 
>> I don't see myself in a position to deal with the can of worms opened by
>> this patch in a reasonable manner.
>
> Neither am I, and probably it's not a so good idea to force Emacs
> settings without the  knowing it...

As I said: if you are surprised by the settings and ask Emacs to
describe them, it will mention their source.  And the settings are only
made within the LilyPond work directory, so unless you make it a habit
to store unrelated software in the LilyPond tree, they don't affect
anything that they should not.

The possibly contentious case is when the user has put up an independent
.dir-local.el file.  Git will complain before overwriting that without
confirmation, so you'll get warning (not for git reset --hard or similar
though).

> an explanation in the CG that tells the contributor to generate
> herself the .dir-locals.el, and adding this file to .gitignore, could
> be a better way to go.

Well, it is the choice between those 95% of developers that have not
bothered to read and/or understand the CG unwittingly obeying the coding
standards, or those 95% of developers unwittingly ignoring them.

Among those 5%, probably less than a fifth will want additional settings
_right_ _there_ (and we don't currently have more than hundred active
developers).  They will be inconvenienced, having to set a
.dir-locals.el in subdirectories instead, or configuring per-file
variables in the top directory.

One could let .dir-locals.el load an optional user-written file, but
add-dir-local-variable would still pick the default file for placing its
information.  I doubt we should bother unless somebody actually
complains.

> Graham, what do you think?

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]