Re: Use directory-local variables to establish some coding styles in Emacs (issue 6460109)

[David Kastrup]

John Mandereau <address@hidden> writes:

> Il giorno dom, 19/08/2012 alle 18.06 +0100, Graham Percival ha scritto:
>> I think that Ian's confusion is understandable.  Files inside
>> elisp/*.el are mostly not intended for developers.  At least,
>> stuff like elisp/lilypond-mode.el seems to be aimed directly at
>> end-users, not developers.
>> 
>> 
>> David, please calm down.  We want to encourage people to review
>> patches.  The tone of your replies to Ian is not encouraging to
>> reviewers.  I agree that Ian has misunderstood a few things, but
>> these should be explained politely.  The use of multiple question
>> marks and exclamation marks is not polite.
>
> Given the large number of questions and reactions such a small patch
> raised, and the number of patches that need to be amended for more solid
> reasons than the commit message (search for Patch-needs-_work on the
> issue tracker), and given we're in a rush for 2.16 release, I'd invite
> potential reviewers to sit down a few minutes, to formulate their
> questions well and try to answer them.

This is not at all coupled to the 2.16 release.  The patch is the
resulting configuration file from setting directory-specific user
options.  It points to the relevant Emacs documentation in its file
comment.  The "obvious" interpretation of Graham is wrong, the file
itself is generated and the persistence of additional comments is
somewhat dubious.  A commit message is not really the place where to
look for information.

So there is no really discoverable place to describe the effects of this
patch in the level of required detail: it basically sneaks in
project-wide editing settings under the radar for most Emacs users.  It
is unlikely that most users would even know how to figure out what makes
their Emacs stop using tabs in the given modes or lets it use a short
line width in Texinfo modes.  Looking at the respective variables with
describe-variable, however, mentions the reason:

    fill-column is a variable defined in `C source code'.
    Its value is 66
    Original value was 70
    Local in buffer expressive.itely; global value is 70

      Automatically becomes buffer-local when set.
      This variable's value is directory-local, set by the file
      `/usr/local/tmp/lilypond/.dir-locals.el'.
      This variable is safe as a file local variable if its value
      satisfies the predicate `integerp'.

    Documentation:
    Column beyond which automatic line-wrapping should happen.
    Interactively, you can set the buffer local value using C-x f.

    You can customize this variable.

    [back]

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.

> For instance, Ian could have looked around in the source tree and read
> ROADMAP file, which would have given some hint that the .dir-locals.el
> was not added in elisp/, purposely because it didn't belong to "Emacs
> LilyPond mode and syntax coloring".

Hardly a reasonable expectation.  The patch quite obviously is not
self-explanatory, and it is far from trivial to make it such in a
satisfactorily discoverable manner.  If we expect to provide a reliable
answer to "why does my Emacs obey the LilyPond coding guidelines inside
of the LilyPond directories when I did not ask it to" beyond the
self-reflection of Emacs' variable descriptions, this will require a lot
more work than this drive-by patch.

-- 
David Kastrup