Please stop making extra unnecessary work for us all.

Please stop making extra unnecessary work for us all.

[Alan Mackenzie]

Hello, Emacs and Stefan K.

I'm referring to

commit 0a7bab689c4a113dd295c9db55d8e76a34d5f9e1
Author: Stefan Kangas <stefan@marxist.se>
Date:   Mon Sep 27 23:56:55 2021 +0200

    ; Minor stylistic fixes found by checkdoc

, and several other similar changes.  Yes, that was the entire commit
message for an assemblage of patches many hundreds of lines long, not
even mentioning the files changed, never mind the defuns.  Sadly, git
has no features for amending inadequate commit messages.

But the point of this post is that these changes are surely unnecessary
with a miniscule benefit, much like pure whitespace changes.

And like pure WS changes, they mess up git blame, they make searches in
history more difficult.  In some instances they introduce solecisms in
English usage.

Many non-functional changes have been made in CC Mode.  That
additionally means that patches from standalone CC Mode are even less
likely to apply cleanly in the Emacs branches than they were already.
That means extra unwanted tedious work for me.

And what are these changes?  In at least two instances the case of a
letter in warning messages following a colon was changed from lower to
upper.  Or was it the other way around?  Come on, please, this is
madness.  Who would even notice the case of a letter after a colon in a
warning message, much less care about it?

I protest at these changes.  As far as I can remember, there was no
discussion on emacs-devel preceding them.  They are disruptive changes.
Can we please not have any more such.

Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Please stop making extra unnecessary work for us all.

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> But the point of this post is that these changes are surely unnecessary
> with a miniscule benefit, much like pure whitespace changes.

They aren't like whitespace changes -- these cleanups result in prompts
and doc strings (visible to the users) that are better than they were
before.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Please stop making extra unnecessary work for us all.

[Campbell Barton]

On Tue, Oct 12, 2021 at 11:41 PM Alan Mackenzie <acm@muc.de> wrote:
>
> Hello, Emacs and Stefan K.
>
> I'm referring to
>
> commit 0a7bab689c4a113dd295c9db55d8e76a34d5f9e1
> Author: Stefan Kangas <stefan@marxist.se>
> Date:   Mon Sep 27 23:56:55 2021 +0200
>
>     ; Minor stylistic fixes found by checkdoc
>
> , and several other similar changes.  Yes, that was the entire commit
> message for an assemblage of patches many hundreds of lines long, not
> even mentioning the files changed, never mind the defuns.  Sadly, git
> has no features for amending inadequate commit messages.
>
> But the point of this post is that these changes are surely unnecessary
> with a miniscule benefit, much like pure whitespace changes.
>
> And like pure WS changes, they mess up git blame, they make searches in
> history more difficult.  In some instances they introduce solecisms in
> English usage.

You can use ".git-blame-ignore-revs" to exclude white-space only changes.

Although it's best to limit this "strictly" to whitespace only
commits, since including more general cleanups could obscure
functional changes.

There is still the down-side of causing patches not to apply cleanly
and other things you've mentioned.

> Many non-functional changes have been made in CC Mode.  That
> additionally means that patches from standalone CC Mode are even less
> likely to apply cleanly in the Emacs branches than they were already.
> That means extra unwanted tedious work for me.
>
> And what are these changes?  In at least two instances the case of a
> letter in warning messages following a colon was changed from lower to
> upper.  Or was it the other way around?  Come on, please, this is
> madness.  Who would even notice the case of a letter after a colon in a
> warning message, much less care about it?
>
> I protest at these changes.  As far as I can remember, there was no
> discussion on emacs-devel preceding them.  They are disruptive changes.
> Can we please not have any more such.
>
> Thanks.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>


-- 
- Campbell

Finding the culprit (was: Please stop making extra unnecessary work for us all)

[Stefan Monnier]

>> And like pure WS changes, they mess up git blame, they make searches in
>> history more difficult.  In some instances they introduce solecisms in
>> English usage.
> You can use ".git-blame-ignore-revs" to exclude white-space only changes.

FWIW, I find `vc-region-history` works much better than `git blame`
(aka `vc-annotate`) when I want to know where code comes from.

This is true both with and without "gratuitous" changes.


        Stefan

Re: Please stop making extra unnecessary work for us all.

[Stefan Kangas]

Campbell Barton <ideasman42@gmail.com> writes:

> You can use ".git-blame-ignore-revs" to exclude white-space only changes.

A proposal to use git-blame-ignore-revs was rejected here:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43117

But magit-blame ignores whitespace changes by default.  I think
vc-annotate should do the same, if it doesn't already.

Re: Please stop making extra unnecessary work for us all.

[dick]

I've observed similar bristling over superfluous changes in the past.  I can
only assume the bristlers are of "a certain age" (which I am as well) who cut
their teeth on CVS or RCS.

It is a bad state of affairs when your development process cannot tolerate
whitespace changes since at the core of every good developer is an
insufferable grammarian who obsesses over straight lines and chamfered edges.

Git is singularly designed to make these cosmetic changes non-events via
switches like `git diff -b` and `git merge -X ours`.

I've long grown accustomed to digging several levels to properly assign
git-blame.  Generally if the code in question is complicated enough, the
person responsible is never the first name that shows up.

Re: Please stop making extra unnecessary work for us all.

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> Many non-functional changes have been made in CC Mode.  That
> additionally means that patches from standalone CC Mode are even less
> likely to apply cleanly in the Emacs branches than they were already.
> That means extra unwanted tedious work for me.
>
> And what are these changes?  In at least two instances the case of a
> letter in warning messages following a colon was changed from lower to
> upper.  Or was it the other way around?  Come on, please, this is
> madness.  Who would even notice the case of a letter after a colon in a
> warning message, much less care about it?

I do apologize if these changes lead to a large amount of extra work for
you.  I'm not familiar with how CC-mode is developed, so I had assumed
that you would merge the Emacs tree into yours or the other way around,
which seems to be the most common solution to merge conflicts.  I will
think twice before making any changes to cc-mode in the future.

The background is this:

I was running checkdoc in an automated way on the entire Emacs codebase.
This allowed me to fix many real issues in our documentation and clear
violations of our style.  Every time there was an issue, if I could fix
it, I did, as it slowed this process down -- for me, and anyone that
might do this later.  (Checkdoc stops on every single one for review.)
Some of them I couldn't fix, so I left them alone.

If someone wants to, they can now run checkdoc on all our Lisp code in
an automated way and relatively quickly find any newly introduced
issues, for example shortly before releasing a new version.  My hope is
that this will lead to more consistency in our documentation and
messages.  I expect that you value such things as much as I do.

Parts of your message unfortunately seems to be suggesting that these
changes were insignificant and/or useless taken as a whole.  I think
that such a view is mistaken, and misses the point.  For example, one
outcome of this work was improvements to checkdoc.el, another was an
improvement to our coding conventions.  These things would not have
happened without first running checkdoc.el on our code.

Your claim that some of the changes were minor is true.  I cannot agree
that they were therefore not worth doing; if you take such a line of
reasoning too far, we should also not run spell checkers, as typos don't
matter.  Most of the changes under discussion are clear mistakes that
should have been fixed.

But I concede that some changes might have slipped through that were not
very important to make.  I'm only human, I do my best.  I hope that you
can accept my limitations and mistakes in this regard.  Meanwhile, I'm
willing to accept that the best analogy you could find here is
"whitespace changes".

Re: Please stop making extra unnecessary work for us all.

[Jean-Christophe Helary]

> On Oct 13, 2021, at 0:00, Stefan Kangas <stefan@marxist.se> wrote:
> 
>>  Who would even notice the case of a letter after a colon in a
>> warning message, much less care about it?

People who read warning messages and care about them?

I've spent a few months in 2017-2018 to learn elisp and correct the mess that was packages.el with automated English formatting that added wrong plurals, etc. and I've corrected spelling mistakes in other places (texinfo ?) as well (some were not valid because I am not a native, but that's a different issue).

English syntax corrections should be considered valid.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

CC-mode fork (was: Please stop making extra unnecessary work for us all)

[Stefan Monnier]

Hi Alan!

> That additionally means that patches from standalone CC Mode are even
> less likely to apply cleanly in the Emacs branches than they
> were already.

Why don't you keep the two identical?  I had sent you patches to do that
and I believe those patches used code which should be acceptable both
for your standalone branch (e.g. they intended to preserve backward
compatibility and compatibility with XEmacs) and for Emacs.


        Stefan