From: Emanuel Berg <embe8573@student.uu.se>
To: help-gnu-emacs@gnu.org
Subject: Re: removing white space highlight
Date: Mon, 29 Feb 2016 01:52:11 +0100 [thread overview]
Message-ID: <871t7wnxs4.fsf@debian.uxu> (raw)
In-Reply-To: 87povgvh8v.fsf@robertthorpeconsulting.com
Robert Thorpe <rt@robertthorpeconsulting.com> writes:
> Every line that has whitespace removed is flagged as
> modified. It's added to the repository with my name,
> date and a new revision number. So, the problem I've
> described still occurs.
The improvement is that the code gets cleaned up.
Which has to be done once, then invisible-to-everyone
automatization makes sure no more trailing whitespace
can ever be added.
> After a long time (maybe a decade), the vast
> majority of lines in all the files would have been
> changed. After that the problem wouldn't arise
> again, but it's a very high price to pay.
This is completely free of charge with no penalty to
it whatsoever. Today, if done to the entire project,
the code will look better. Tomorrow, if automatization
is added, the problem will be gone forever and can by
definition not re-enter the project nor any other
projects with the same technology at work.
> In a large project, are you going to tell people
> that they can't use front-ends to version-control?
>
> Let's say, for example, that Vim doesn't support
> those switches. Are you going to say "I'm sorry Vim
> users, you have to use command line svn."
It shouldn't be put on the level of the
"client"/editor/singular user. It should be put on the
"server" or most centralized level which holds the
answer to the question "what are the current files for
project P version XYZ?".
Before anything enters there, cleaning is
automatically done, but not logged (well, not logged
as normal edits are anyway) - then, when people get
the most recent files (i.e., the files that are
exactly P:XYZ), people always get clean files.
And they can't mess them up even if they try because
such edits are silently ignored and discarded...
The theoretical reason why this is possible and easy
is that nobody (human nor machine) has any interest in
or benefits from trailing whitespace. It is just
a matter of automatically dealing with a bunch of
data, a transformation from one state to another,
where everything is very straightforward.
--
underground experts united
http://user.it.uu.se/~embe8573
next prev parent reply other threads:[~2016-02-29 0:52 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
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 [this message]
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=871t7wnxs4.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.