From: Emanuel Berg <embe8573@student.uu.se>
To: help-gnu-emacs@gnu.org
Subject: Re: removing white space highlight
Date: Fri, 26 Feb 2016 20:48:51 +0100 [thread overview]
Message-ID: <877fhrjlr0.fsf@debian.uxu> (raw)
In-Reply-To: 20160225221634972375976@bob.proulx.com
Bob Proulx <bob@proulx.com> writes:
> If you have placed an automated routine in your
> particular editor (remember that other people on
> your team will use different editors with differing
> capabilities) that touches every line in the file
> then you will start making changesets that contain
> a lot of noise. You will check in a result that
> cannot be reasonably reviewed by a peer review
> group. If the group is at all reasonable they will
> reject your change-set and send you back to work on
> it further.
The Elisp code I've posted and the Emacs batch command
is to show how easy this can be automatized.
For this to work at the level of peer review, it can't
be implemented exactly like that. It has do be done
centrally or at the level of the peer review software
which everyone working on the project is assumed
to use.
That clarified, I still don't think it is a difficult
thing to do.
Because bottom line, no one ever needs that trailing
whitespace. It can always be safely just dropped with
nothing to it!
> And even for those folks who are just working solo.
> Your work is your reputation. If your work is good
> then so is your reputation. If your work is crufty
> then the same with your reputation. Because of
> version control your work is not just the finished
> file but the history of the file too.
Really? Are people reviewing the history of files so
they can bash people's reputation even tho the end
result is good? If so, I'm happy I don't do that on
either side of it...
While I do not consider cleaning files to be the
spoilation of anyone's reputation, I do not suggest
anyone does this "client-side". While it'll work some
people will add more later (their reputation will drop
I suppose) and then the circus is afoot. No - it
should be done "server-side" once (with a command) and
then automatically never allowed inside again. Or the
automatization can be put to work and then file by
file will be cleaned in time.
> This is why I think cleanup should be done
> explicitly as an explicit action and not as a side
> effect of other random changes.
I guess it depends how big the files are, how active
people are reviewing them, and how specific
information you get from the software what changes has
been made. Probably it isn't difficult to see where
there has been qualitative changes and where there has
just been a bunch of trailing whitespace removed.
Even so, I agree "explicit action" to the entire
project is preferable, and my command can do this to
the entire project in one keystroke.
After that, automatization (also very simple) is
implemented to drop trailing whitespace forever on and
to not regard that as something anyone ever has to
"review". Because again, no one benefits from it so no
one should want it.
>> However not wanting to have trailing whitespace and
>> having it automatized in four lines of Elisp and
>> then have the desired behavior forever seems like
>> rather good craftmanship to me...
>
> Your good craftmanship feels to me like a buldozer
> rolling through regardless of the other traffic.
> You will get to where you want to go but no one will
> want to be near you while you are doing it.
Rather like a surgeon removing dead tissue with
a waldo robot arm holding a laser scalpel...
Recall that `remove-trailing-whitespace' doesn't do
anything if there is nothing to be done!
> Aside: What? You haven't painted your house in the
> last year? People will think your house is abandoned
> if you haven't changed the paint color at least
> every year. That is the way some software projects
> feel to me.
Definitely.
--
underground experts united
http://user.it.uu.se/~embe8573
next prev parent reply other threads:[~2016-02-26 19:48 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 10:06 removing white space highlight Luca Ferrari
2016-02-18 10:19 ` Gian Uberto Lauri
2016-02-18 10:54 ` Luca Ferrari
2016-02-18 10:30 ` tomas
2016-02-18 13:34 ` Luca Ferrari
2016-02-18 13:17 ` tomas
2016-02-18 14:37 ` Luca Ferrari
2016-02-18 14:15 ` tomas
2016-02-18 16:08 ` Luca Ferrari
2016-02-19 0:23 ` Emanuel Berg
2016-02-19 1:05 ` Drew Adams
2016-02-19 16:02 ` Marcin Borkowski
2016-02-19 20:43 ` Emanuel Berg
2016-02-19 20:50 ` Marcin Borkowski
2016-02-20 0:30 ` Emanuel Berg
2016-02-20 19:08 ` Bob Proulx
2016-02-21 0:32 ` Emanuel Berg
2016-02-21 1:34 ` Bob Proulx
2016-02-21 1:48 ` Emanuel Berg
2016-02-21 3:27 ` Robert Thorpe
2016-02-21 3:31 ` Emanuel Berg
2016-02-21 5:00 ` Marcin Borkowski
2016-02-21 6:10 ` Emanuel Berg
2016-02-21 11:48 ` tomas
2016-02-21 17:13 ` Emanuel Berg
2016-02-23 0:33 ` Robert Thorpe
2016-02-23 0:41 ` Emanuel Berg
2016-02-24 0:44 ` Robert Thorpe
2016-02-24 1:41 ` Emanuel Berg
2016-02-24 20:38 ` Robert Thorpe
2016-02-25 0:10 ` Emanuel Berg
2016-02-25 8:47 ` Luca Ferrari
2016-02-25 9:29 ` Christian Kruse
2016-02-25 19:58 ` Robert Thorpe
2016-02-25 20:10 ` vc-region-history promotion (was: removing white space highlight) Stefan Monnier
2016-02-25 22:15 ` removing white space highlight Emanuel Berg
2016-02-25 22:41 ` Robert Thorpe
2016-02-26 0:02 ` Emanuel Berg
2016-02-26 2:58 ` Robert Thorpe
2016-02-26 3:29 ` Emanuel Berg
2016-02-26 6:08 ` Bob Proulx
2016-02-26 19:48 ` Emanuel Berg [this message]
2016-02-27 20:54 ` Robert Thorpe
2016-02-28 2:43 ` Emanuel Berg
2016-02-28 18:09 ` Robert Thorpe
2016-02-29 0:52 ` Emanuel Berg
2016-02-29 2:43 ` Robert Thorpe
2016-02-22 14:05 ` Luca Ferrari
2016-02-23 0:13 ` Emanuel Berg
2016-02-23 0:34 ` Robert Thorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877fhrjlr0.fsf@debian.uxu \
--to=embe8573@student.uu.se \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.