The grand indentation unification project

The grand indentation unification project

[Daniel Hackney]

While working on adding configurable lisp paths to package.el, I noticed
that many whitespace-only changes were created, cluttering up the diffs.
It would make patches smaller and more focused if there were a single
whitespace style applied throughout all of the elisp sources. This
doesn't mean radically changing things; but rather applying the current
style throughout. From what I see, the current source has
`indent-tabs-mode' non-nil and a `tab-width' of 8 and mostly sticks to
this formula.

There are some places where it deviates from this style, such as using 8
spaces rather than a tab for indentation in some parts, having a space
before a tab, or a single-semicolon comment at column 1. `indent-region'
does not catch all of these, especially indentation using 8 spaces
rather than a tab (because `indent-to' specifically avoids changing
spaces to tabs if there are the right number of spaces).

I propose adding to the `emacs-lisp-mode' section of ".dir-locals.el" in
the source root `(indent-tabs-mode . t)' and a definition for
`whitespace-style' to use tabs for indentation. Then, when committing
changes, the buffer would be run through `indent-region' and
`whitespace-cleanup'. This would ensure whitespace consistency for all
files in the repo and prevent diff conflicts which consist entirely of
whitespace changes.

As an extra guarantee of consistency, use "emacs -Q" when re-indenting
files so that no user customizations can change the indentation.

--
Daniel M. Hackney

Re: The grand indentation unification project

[Glenn Morris]

Daniel Hackney wrote:

> I propose adding to the `emacs-lisp-mode' section of ".dir-locals.el" in
> the source root `(indent-tabs-mode . t)'

We've been here before. Eg:

http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00820.html
    
    space-vs-tabs-vs-aliens doesn't matter, as long as it's indented to the
    right position.  That's my opinion on this matter.
    
    > In any case, the current situation of inconsistent use of spaces and
    > TABs is IMO much worse than any of the consistent alternatives.
    
    It's completely irrelevant and a waste of time to even discuss it.

http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00219.html

etc, etc

Re: The grand indentation unification project

[Juri Linkov]

> http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00219.html
>
> etc, etc

The most useful is this one:
http://lists.gnu.org/archive/html/emacs-devel/2005-09/msg00860.html

Another promising thing to pay attention to
http://emacswiki.org/emacs/SmartTabs

Re: The grand indentation unification project

[Daniel Hackney]

Glenn Morris <rgm@gnu.org> wrote:
> Daniel Hackney wrote:
>
>> I propose adding to the `emacs-lisp-mode' section of ".dir-locals.el" in
>> the source root `(indent-tabs-mode . t)'
>
> We've been here before. Eg:

I should have known I wasn't the first one to have this idea ;)

I understand not wanting to reawaken this bikeshedding thread, but I
would like to submit this humble one-liner which goes through all of the
elisp source and indents each file.

find -name '*.el' -exec emacs -Q --batch '{}' --eval '(progn (setq
make-backup-files nil) (indent-region (point-min) (point-max)))' -f
whitespace-cleanup -f basic-save-buffer-1 \;

Not the most efficient, but it gets the job done. If you guys don't
think it's worth it even with this hack, I'll drop it.

--
Daniel M. Hackney

Re: The grand indentation unification project

[Miles Bader]

Daniel Hackney <dan@haxney.org> writes:
> I understand not wanting to reawaken this bikeshedding thread, but I
> would like to submit this humble one-liner which goes through all of
> the elisp source and indents each file.

Your original proposal (".dir-locals => indent-tabs-mode = t") seems
fairly innocuous, as it won't, for the most part, change any line that
isn't being changed already for some reason.  So it would basically
would result in minimal churn.

_This_, on the other hand, would probably result in _massive_
pointless code churn...

-miles

-- 
Joy, n. An emotion variously excited, but in its highest degree arising from
the contemplation of grief in another.

Re: The grand indentation unification project

[Daniel Hackney]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

I really don't want to waste any more of people's time, and I know this is
a very minor point, so please feel free to say "this isn't worth the
electrons it's printed on" and I'll let it go.

I do think having a uniform whitespace style (no spaces before tabs, etc.)
would be useful, but it isn't worth any real mental effort.

"Miles Bader" <miles@gnu.org> wrote:
>
> Daniel Hackney <dan@haxney.org> writes:
> > I understand not wanting to reawaken this bikeshedding thread, but I
> > would like to submit this humble one-liner which goes through all of
> > the elisp source and indents each file.
>
> Your original proposal (".dir-locals => indent-tabs-mode = t") seems
> fairly innocuous, as it won't, for the most part, change any line that
> isn't being changed already for some reason.  So it would basically
> would result in minimal churn.
>
> _This_, on the other hand, would probably result in _massive_
> pointless code churn...

Yes, it would, but the idea would be to set `indent-tabs-mode' to t, add
`whitespace-cleanup to `before-save-hook', and have a single massive,
horrible, ugly "whitespace unification" commit, and then everything after
that follows the tab indent and whitespace styles. That way, you'd have one
big patch with all the whitespace changes, but future patches wouldn't have
any whitespace-only diffs.

[-- Attachment #2: Type: text/html, Size: 1658 bytes --]

Re: The grand indentation unification project

[Stefan Monnier]

> Yes, it would, but the idea would be to set `indent-tabs-mode' to t, add
> `whitespace-cleanup to `before-save-hook', and have a single massive,
> horrible, ugly "whitespace unification" commit, and then everything after
> that follows the tab indent and whitespace styles. That way, you'd have one
> big patch with all the whitespace changes, but future patches wouldn't have
> any whitespace-only diffs.

Still sucks for everyone who's got a branch to keep in sync.

The problems you complain about (conflicts due to whitespace changes)
pretty much only show up because of such "helpful" commits.

So, no, we don't want any of that.  OTOH we would accept changes which
will enforce such "canonical spacing" in future commits (i.e. enforce
this canonicity but only on lines which are already changed for other
reasons anyway, thus not introducing new gratuitous conflicts).


        Stefan