Whitespace cleanup

Whitespace cleanup

[Jordi Gutiérrez Hermoso]

Elisp code almost invariably contains a mixture of tabs and spaces.
Whenever I open a new elisp file, I almost always have to turn on
whitespace-mode and guess what tab width, if any, makes it this
mixture of tabs and spaces ident and align properly.

Can we fix this at least for the elisp shipped with Emacs? It
shouldn't be a big deal. All modern diff programs, including bzr's
own[1] can ignore whitespace changes.

Thanks,
- Jordi G. H.

[1] https://bugs.launchpad.net/qbzr/+bug/327317

RE: Whitespace cleanup

[Drew Adams]

> Elisp code almost invariably contains a mixture of tabs and spaces.
> Whenever I open a new elisp file, I almost always have to turn on
> whitespace-mode and guess what tab width, if any, makes it this
> mixture of tabs and spaces ident and align properly.
>
> Can we fix this at least for the elisp shipped with Emacs? It
> shouldn't be a big deal. All modern diff programs, including bzr's
> own[1] can ignore whitespace changes.

I believe this has been discussed before, but someone might correct me.  I
believe it was decided not to replace tabs by spaces and/or to require using
only spaces going forward.  (But I don't recall all the reasons.)

I, for one, would like to see the tabs replaced by spaces in the Lisp code that
is shipped.  It's not a big deal, but I invariably find myself later cleaning up
pieces in code of mine that might have parts originally copy+yanked from vanilla
code.

But like I say, not a big deal at all.
`C-x h M-x untabify', and you're done.

Re: Whitespace cleanup

[Stefan Monnier]

> Elisp code almost invariably contains a mixture of tabs and spaces.
> Whenever I open a new elisp file, I almost always have to turn on
> whitespace-mode and guess what tab width, if any, makes it this
> mixture of tabs and spaces ident and align properly.

If an Elisp file requires a tab-width different from 8 to be indented
properly, that's a bug.


        Stefan

Re: Whitespace cleanup

[Glenn Morris]

Not really sure what you are proposing, but it sounds familiar...

http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00483.html

Re: Whitespace cleanup

[Jordi Gutiérrez Hermoso]

On 22 August 2012 11:44, Drew Adams <drew.adams@oracle.com> wrote:
> I, for one, would like to see the tabs replaced by spaces in the Lisp code that
> is shipped.  It's not a big deal, but I invariably find myself later cleaning up
> pieces in code of mine that might have parts originally copy+yanked from vanilla
> code.
>
> But like I say, not a big deal at all.
> `C-x h M-x untabify', and you're done.

That only works after you figure out what the correct tab width should
have been to begin with.

On 22 August 2012 12:07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> If an Elisp file requires a tab-width different from 8 to be indented
> properly, that's a bug.

The indentation offset is rarely 8, so I guess tabs get inserted only
after 4 levels of indentation, creating a horrible mix.

Can we just run M-x whitespace-cleanup on all elisp shipped by Emacs,
since someone always misunderstands how to use tabs correctly? This
cleanup does some additional things like removing trailing spaces. I
thought the complaint against this is that we don't want to see
whitespace changes in diffs, but those can be hidden now.

On 22 August 2012 12:15, Glenn Morris <rgm@gnu.org> wrote:
>
> Not really sure what you are proposing, but it sounds familiar...
>
> http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00483.html

I'm proposing to not mix tabs and spaces, but since not everybody
understands why this is desirable, let's just run M-x
whitespace-cleanup instead.

- Jordi G. H.

Re: Whitespace cleanup

[Juanma Barranquero]

On Wed, Aug 22, 2012 at 9:02 PM, Jordi Gutiérrez Hermoso
<jordigh@octave.org> wrote:

> The indentation offset is rarely 8, so I guess tabs get inserted only
> after 4 levels of indentation, creating a horrible mix.

In the Emacs sources? I have tab-width set to 8 and I've never seen
any misalignment caused by tab width.

> Can we just run M-x whitespace-cleanup on all elisp shipped by Emacs,
> since someone always misunderstands how to use tabs correctly? This
> cleanup does some additional things like removing trailing spaces. I
> thought the complaint against this is that we don't want to see
> whitespace changes in diffs, but those can be hidden now.

What you propose will make most lines in elisp files to be "new" from
Bazaar's POV, sabotaging the usefulness of "bzr annotate".

    Juanma

Re: Whitespace cleanup

[Thierry Volpiatto]

Glenn Morris <rgm@gnu.org> writes:

> Not really sure what you are proposing, but it sounds familiar...
>
> http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00483.html

Using a local value of `indent-tabs-mode' for each file 
(or a directory local value) in emacs
would avoid ending with crap indentation like in e.g `count-lines'.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Whitespace cleanup

[Jordi Gutiérrez Hermoso]

On 22 August 2012 15:58, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Aug 22, 2012 at 9:02 PM, Jordi Gutiérrez Hermoso
> <jordigh@octave.org> wrote:
>> Can we just run M-x whitespace-cleanup on all elisp shipped by Emacs,
>> since someone always misunderstands how to use tabs correctly?
>
> What you propose will make most lines in elisp files to be "new" from
> Bazaar's POV, sabotaging the usefulness of "bzr annotate".

Hm, hg's annotate and diff can be told to ignore whitespace changes. I
understand bzr's diff also can. So it's just a matter of making bzr
grow another feature?

- Jordi G. H.

Re: Whitespace cleanup

[Juanma Barranquero]

On Thu, Aug 23, 2012 at 2:55 PM, Jordi Gutiérrez Hermoso
<jordigh@octave.org> wrote:

> Hm, hg's annotate and diff can be told to ignore whitespace changes. I
> understand bzr's diff also can. So it's just a matter of making bzr
> grow another feature?

Perhaps, though we don't control Bazaar development.

And even if the option existed, why bother? What's the problem you
want to fix? Do you see misalignment with tab-width = 8 in the current
sources?

Also, as I said, this issue has been discussed before. Did you read it?

    Juanma

Re: Whitespace cleanup

[Dan Nicolaescu]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On 22 August 2012 11:44, Drew Adams <drew.adams@oracle.com> wrote:
>> I, for one, would like to see the tabs replaced by spaces in the Lisp code that
>> is shipped.  It's not a big deal, but I invariably find myself later cleaning up
>> pieces in code of mine that might have parts originally copy+yanked from vanilla
>> code.
>>
>> But like I say, not a big deal at all.
>> `C-x h M-x untabify', and you're done.
>
> That only works after you figure out what the correct tab width should
> have been to begin with.
>
> On 22 August 2012 12:07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> If an Elisp file requires a tab-width different from 8 to be indented
>> properly, that's a bug.
>
> The indentation offset is rarely 8, so I guess tabs get inserted only
> after 4 levels of indentation, creating a horrible mix.

If you use (a new enough) emacs to edit emacs sources tab-width is set
to 8 automatically.  So no problem here.

Re: Whitespace cleanup

[Jordi Gutiérrez Hermoso]

On 23 August 2012 09:16, Juanma Barranquero <lekktu@gmail.com> wrote:
> And even if the option existed, why bother? What's the problem you
> want to fix? Do you see misalignment with tab-width = 8 in the current
> sources?

On 23 August 2012 09:23, Dan Nicolaescu <dann@gnu.org> wrote:
> If you use (a new enough) emacs to edit emacs sources tab-width is set
> to 8 automatically.  So no problem here.

If tab-width has to be 8 for Emacs sources to properly align because
they mix tabs and spaces, then can we require every Emacs file to set
this local variable? If I change my tab width, I have to remember "oh,
change it back to 8, I'm looking at Emacs source code now". I know the
tarball has a .dir-locals.el that does this, but this file isn't
always present with the corresponding file you're editing. The Emacs
source isn't always in its original tree.

Also, what's the point of even using tabs if you require a pre-defined
tab-width to properly read the sources?

Futhermore, I find Emacs's default behaviour odd, if I understand it
correctly:

    * The indentation offset and the tab width are independent
      variables.

    * When the indentation or alignment level exceeds the tab width,
      both measured in spaces, start using as many tabs as possible.

    * Otherwise, indent or align with spaces.

Why do this at all? Why use tabs like this? The only purpose this
seems to serve in my eyes is to mess up the alignment if someone for
whatever reason decides to change tab-width.

On 23 August 2012 09:16, Juanma Barranquero <lekktu@gmail.com> wrote:
> Also, as I said, this issue has been discussed before. Did you read
> it?

I read the one message I was linked to, but I didn't read the others.
Are my concerns above already addressed in another message?

- Jordi G. H.

Re: Whitespace cleanup

[Juanma Barranquero]

On Thu, Aug 23, 2012 at 4:28 PM, Jordi Gutiérrez Hermoso
<jordigh@octave.org> wrote:

> The Emacs
> source isn't always in its original tree.

If you're editing Emacs sources outside the Emacs tree, you can add a
.dir-locals.el file.

    Juanma

Re: Whitespace cleanup

[Stefan Monnier]

> Why do this at all? Why use tabs like this? The only purpose this
> seems to serve in my eyes is to mess up the alignment if someone for
> whatever reason decides to change tab-width.

I strongly discourage changing tab-width with very few exceptions.
If someone does change it either globally and or elisp-mode buffers,
he's on his own and we'll complain about the patches he may submit
for inclusion.


        Stefan

Re: Whitespace cleanup

[Stefan Monnier]

> Hm, hg's annotate and diff can be told to ignore whitespace changes.
> I understand bzr's diff also can. So it's just a matter of making bzr
> grow another feature?

The TAB-vs-SPC is a non-problem, really.  Whereas the problems with
annotate, diff, and merge are real.  Maybe they can solved, but
why bother?


        Stefan

Re: Whitespace cleanup

[Jordi Gutiérrez Hermoso]

On 23 August 2012 10:50, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Why do this at all? Why use tabs like this? The only purpose this
>> seems to serve in my eyes is to mess up the alignment if someone for
>> whatever reason decides to change tab-width.
>
> I strongly discourage changing tab-width with very few exceptions.

There is a lot of code out there besides' Emacs own. I have to keep
changing my tab width to be able to read it all. Sometimes it's 8,
usually it's 4, rarely it's 2 or 3, and if people are mixing tabs and
spaces, I have to figure out what tab width they intended to use if
they don't explicitly state it somehow. It's a minor annoyance I'd
like to at least fix in Emacs's own source code.

> If someone does change it either globally and or elisp-mode buffers,
> he's on his own and we'll complain about the patches he may submit
> for inclusion.

But again, what is the point of having tabs at all other than promote
breakage if tab-width for whatever reason changes?

On 23 August 2012 10:52, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Hm, hg's annotate and diff can be told to ignore whitespace changes.
>> I understand bzr's diff also can. So it's just a matter of making bzr
>> grow another feature?
>
> The TAB-vs-SPC is a non-problem, really.  Whereas the problems with
> annotate, diff, and merge are real.  Maybe they can solved, but
> why bother?

Tabs apparently are not a problem for you, but they are for me. If you
don't care either way about tabs, you won't care if we get rid of tabs
in the Emacs tree either assuming I can get bzr to grow the option to
ignore whitespace in diffs and annotate, correct?

On 23 August 2012 10:44, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Aug 23, 2012 at 4:28 PM, Jordi Gutiérrez Hermoso
> <jordigh@octave.org> wrote:
>
>> The Emacs
>> source isn't always in its original tree.
>
> If you're editing Emacs sources outside the Emacs tree, you can add a
> .dir-locals.el file.

Assuming I have write permissions to that directory. Sometimes I am
reading the source files from a location my sysadmin installed them
in.

Yes, there are more workarounds, but why create a situation in which
workarounds need to exist in the first place?

Look, obviously you guys think that nothing needs to be done. I do.
I'm not asking anyone to do the work, but if I do that work, I just
ask that you accept my work if you don't care either way. I care.

- Jordi G. H.

Re: Whitespace cleanup

[Paul Eggert]

On 08/23/2012 08:02 AM, Jordi Gutiérrez Hermoso wrote:
> It's a minor annoyance I'd
> like to at least fix in Emacs's own source code.

The .dir-locals.el file does fix that in Emacs's own source code.

If you'd like to use a tab-width of 8 everywhere for Elisp code,
you can put a find-file-hook into your .emacs file, to do that.

> what is the point of having tabs at all

Originally, I think tab==8 was partly as a convenience when
typing makefiles and C files, and partly to save memory.  It still
has these functions, though admittedly this is not a big deal these
days, for most purposes.  Some other GNU projects have decided
to expand tabs to spaces (except for makefiles and changelogs,
where they're part of the format), but the Emacs developers are
relatively conservative about making changes like that, and I
doubt whether this discussion will change things.

As you say, it's only a minor annoyance.

Whitespace cleanup

[Juanma Barranquero]

[Resending; sent private by accident]

On Thu, Aug 23, 2012 at 5:02 PM, Jordi Gutiérrez Hermoso
<jordigh@octave.org> wrote:

> I'm not asking anyone to do the work, but if I do that work, I just
> ask that you accept my work if you don't care either way. I care.

Oh, but I do care. I use bzr annotate quite a lot, for example.
Hypothetical command options do not help me here and now.

And I think what you propose adds a lot of unnecessary changes for
nothing. I know. I once removed every trailing whitespace in the Emacs
sources. I was naïve. I wouldn't do it  today.

    Juanma

Re: Whitespace cleanup

[Jordi Gutiérrez Hermoso]

On 23 August 2012 16:40, Juanma Barranquero <lekktu@gmail.com> wrote:
> [Resending; sent private by accident]
>
> On Thu, Aug 23, 2012 at 5:02 PM, Jordi Gutiérrez Hermoso
> <jordigh@octave.org> wrote:
>
>> I'm not asking anyone to do the work, but if I do that work, I just
>> ask that you accept my work if you don't care either way. I care.
>
> Oh, but I do care. I use bzr annotate quite a lot, for example.
> Hypothetical command options do not help me here and now.

Well, as long as the command line options are hypothetical, so is the
whitespace cleanup. Once the options are there, can we clean up the
whitespce?

- Jordi G. H.

Re: Whitespace cleanup

[Juanma Barranquero]

On Thu, Aug 23, 2012 at 10:52 PM, Jordi Gutiérrez Hermoso
<jordigh@octave.org> wrote:

> Well, as long as the command line options are hypothetical, so is the
> whitespace cleanup. Once the options are there, can we clean up the
> whitespce?

It's not my decission, obviously, but IMO, perhaps we can discuss it
again "once the options are there".

    Juanma

Re: Whitespace cleanup

[Stefan Monnier]

> There is a lot of code out there besides' Emacs own. I have to keep
> changing my tab width to be able to read it all. Sometimes it's 8,
> usually it's 4, rarely it's 2 or 3, and if people are mixing tabs and
> spaces,

8 has been, is, and apparently always will be the standard, so please
complain to those idiots who use some other setting, not to those like
us who use the standard value.

> Tabs apparently are not a problem for you, but they are for me. If you
> don't care either way about tabs, you won't care if we get rid of tabs
> in the Emacs tree either assuming I can get bzr to grow the option to
> ignore whitespace in diffs and annotate, correct?

No.  We already have way too many cosmetic commits.

> Assuming I have write permissions to that directory. Sometimes I am
> reading the source files from a location my sysadmin installed them in.

(add-hook 'emacs-lisp-mode (lambda () (setq tab-width 8)))

will solve it for you.  I haven't seen an Elisp file using another
tab-width yet.

> Look, obviously you guys think that nothing needs to be done. I do.
> I'm not asking anyone to do the work, but if I do that work, I just
> ask that you accept my work if you don't care either way. I care.

I'm really tired of resolving spurious conflicts due to cosmetic
changes, and have much better things to do with my time.
So, no, I'm firmly opposed to such a change.


        Stefan

Re: Whitespace cleanup

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm really tired of resolving spurious conflicts due to cosmetic
> changes, and have much better things to do with my time.
> So, no, I'm firmly opposed to such a change.

I also think that those changes does more bad than good. Nevertheless,
inconsistent tab usage and trailing whitespace are a nuisance and there
is one thing we could do to improve things: require from the committers
to not add to the problem, which does not only means to do the right
thing on new lines, but to fix withespace problems on modified lines as
well. So the problem will slowly go away.

There are ways to highlight withespace on diffs to warn about
modified/added lines. If bzr supports a commit trigger to reject patches
that does not conform to whitespace rules, it would be a good thing to
use it too (at Savannah).