removing white space highlight

removing white space highlight

[Luca Ferrari]

Hi all,
for some reason I don't know after applying a few theme settings I
have Emacs now highlighting rows with only white spaces.
That is a little annoying to me, so I'm wondering what is the
customize-* I accidentally broke.
Any suggestion is welcome.

Thanks,
Luca

Re: removing white space highlight

[Gian Uberto Lauri]

>>>>> "LF" == Luca Ferrari <fluca1978@infinito.it> writes:

LF> Hi all, for some reason I don't know after applying a few theme
LF> settings I have Emacs now highlighting rows with only white
LF> spaces.  That is a little annoying to me, so I'm wondering what is
LF> the customize-* I accidentally broke.  Any suggestion is welcome.


It should be show-trailing-whitespace that has been set to t.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: removing white space highlight

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 18, 2016 at 11:54:52AM +0100, Luca Ferrari wrote:
> On Thu, Feb 18, 2016 at 11:19 AM, Gian Uberto Lauri <saint@eng.it> wrote:
> > It should be show-trailing-whitespace that has been set to t.
> 
> 
> No, it is nil.
> Trying to change the face trailing-whitespace does not take any
> effect, so I suspect there is something hidden somewhere else.
> 
> Any idea?

whitespace-mode?

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlbFnTsACgkQBcgs9XrR2kbIFgCdElr9JzTN7FJQYDOmGGkvyHeE
1xMAniBystsB4pqpdc7KGobrJdly+BdJ
=97tl
-----END PGP SIGNATURE-----

Re: removing white space highlight

[Luca Ferrari]

On Thu, Feb 18, 2016 at 11:19 AM, Gian Uberto Lauri <saint@eng.it> wrote:
> It should be show-trailing-whitespace that has been set to t.


No, it is nil.
Trying to change the face trailing-whitespace does not take any
effect, so I suspect there is something hidden somewhere else.

Any idea?

Luca

Re: removing white space highlight

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 18, 2016 at 02:34:20PM +0100, Luca Ferrari wrote:
> On Thu, Feb 18, 2016 at 11:30 AM,  <tomas@tuxteam.de> wrote:
> > whitespace-mode?
> 
> No it is disabled, however I found that all spaces up to the end of line.
> Hope this helps finding out what is the custom setting.

Hm. I'm out of my depth here.

Try to move point (aka cursor) to one of those highlighted characters.
Then do M-x describe-char <RET>. This should show you some info about
the character; at the very bottom "There are text properties here:"
it tells you among other things which face it's displayed with.

Perhaps the name of the face tips you off towards which little djinn
is doing that.

Regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlbFxGIACgkQBcgs9XrR2kZzrQCeJkMOurDTq4YEur9Ss2jrJvT9
9LoAn2OFJW7pqJ++FLFeXEwj+q5/NDVA
=WlpU
-----END PGP SIGNATURE-----

Re: removing white space highlight

[Luca Ferrari]

On Thu, Feb 18, 2016 at 11:30 AM,  <tomas@tuxteam.de> wrote:
> whitespace-mode?

No it is disabled, however I found that all spaces up to the end of line.
Hope this helps finding out what is the custom setting.

Thanks,
Luca

Re: removing white space highlight

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 18, 2016 at 03:37:57PM +0100, Luca Ferrari wrote:
> On Thu, Feb 18, 2016 at 2:17 PM,  <tomas@tuxteam.de> wrote:
> > Try to move point (aka cursor) to one of those highlighted characters.
> > Then do M-x describe-char <RET>. This should show you some info about
> > the character; at the very bottom "There are text properties here:"
> > it tells you among other things which face it's displayed with.
> 
> Uhm...it's font-lock-constant-face but customizing it does not solve
> the problem (there is no highlight nor background).

Hm. Either this is the (major mode) fontification, which would be
strange -- or someone else has hi-jacked the face.

What happens if you toggle font-lock mode? (M-x font-lock-mode)

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlbF0hAACgkQBcgs9XrR2kY9vACfeCKSE7mmGwac8x4P/SnaK8rv
6qQAn1PXk1bykEezGvk5G6dpqSEWdGxu
=UNR6
-----END PGP SIGNATURE-----

Re: removing white space highlight

[Luca Ferrari]

On Thu, Feb 18, 2016 at 2:17 PM,  <tomas@tuxteam.de> wrote:
> Try to move point (aka cursor) to one of those highlighted characters.
> Then do M-x describe-char <RET>. This should show you some info about
> the character; at the very bottom "There are text properties here:"
> it tells you among other things which face it's displayed with.

Uhm...it's font-lock-constant-face but customizing it does not solve
the problem (there is no highlight nor background).

Luca

Re: removing white space highlight

[Luca Ferrari]

On Thu, Feb 18, 2016 at 3:15 PM,  <tomas@tuxteam.de> wrote:
> What happens if you toggle font-lock mode? (M-x font-lock-mode)

Spaces are still highlighted and other lines are (of course) plain text.
Please note I'm running spacemacs, if that does matter.

Luca

Re: removing white space highlight

[Emanuel Berg]

Luca Ferrari <fluca1978@infinito.it> writes:

> Spaces are still highlighted and other lines are (of
> course) plain text. Please note I'm running
> spacemacs, if that does matter.

You can do the "binary search". It is a pretty name
for a sluggish tho capable method.

1. First do 'emacs -Q'. If this solves the problem,
   the problem is in a configuration/extension file.

2. Then proceed to comment out half of your
   initialization code.

3. If this solves the problem, you know where the
   problem is. If this doesn't solve the problem, you
   know where the problem is. With the newfound
   "problem chunk of code", redo steps 2-3 until you
   have found the misconfiguration.

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: removing white space highlight

[Drew Adams]

> You can do the "binary search". It is a pretty name
> for a sluggish tho capable method.

Nope.  Not sluggish at all.  Blind, maybe (but nothing prevents
one from applying some thought, as well).  But not sluggish.

It can seem silly or sluggish at first, but ... well, it's
exponential, so keep with it...

There is little in our Universe that is less sluggish, at the
end of the day, than exponential behavior.

> 1. First do 'emacs -Q'. If this solves the problem,
>    the problem is in a configuration/extension file.
> 
> 2. Then proceed to comment out half of your
>    initialization code.
> 
> 3. If this solves the problem, you know where the
>    problem is. If this doesn't solve the problem, you
>    know where the problem is. With the newfound
>    "problem chunk of code", redo steps 2-3 until you
>    have found the misconfiguration.

Yup.  Good.

Re: removing white space highlight

[Marcin Borkowski]

On 2016-02-19, at 01:23, Emanuel Berg <embe8573@student.uu.se> wrote:

> Luca Ferrari <fluca1978@infinito.it> writes:
>
>> Spaces are still highlighted and other lines are (of
>> course) plain text. Please note I'm running
>> spacemacs, if that does matter.
>
> You can do the "binary search". It is a pretty name
> for a sluggish tho capable method.
>
> 1. First do 'emacs -Q'. If this solves the problem,
>    the problem is in a configuration/extension file.
>
> 2. Then proceed to comment out half of your
>    initialization code.
>
> 3. If this solves the problem, you know where the
>    problem is. If this doesn't solve the problem, you
>    know where the problem is. With the newfound
>    "problem chunk of code", redo steps 2-3 until you
>    have found the misconfiguration.

Or do it automatically.

https://github.com/Malabarba/elisp-bug-hunter

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: removing white space highlight

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> Or do it automatically.

Here, we only consider serious suggestions :)

About 'binary search' being "sluggish", the algorithm
itself isn't sluggish. Actually it is great when the
outcome (the test or the search) is almost instantly
extractable from any "length" of the material, *and*
when the material is possible to divide arbitrarily.

Here, the test is the existence of unwanted behavior
and the material is Elisp code, so this is so, or
almost so, because you can't cut the code in half
entirely anywhere you want (e.g., it is not possible
in the middle of a defun), but mostly, it should be
possible to divide fairly freely as the code is
probably either written "in sequence" (e.g., as single
.emacs file) *or* if it is modular (e.g., the .emacs
file is a bunch of `loads' of other files).

Once again modular code makes life easier. Start Emacs
with '-Q', confirm the unwanted isn't there, then
bring up the "load" .emacs file:

(load-file "file.elc-1")
(load-file "file.elc-2")

         ...
         
(load-file "file.elc-n")

This makes it much easier to comment out and in code.
Either do that the binary way (for a lot of files) or
just evaluate file after file until the
problem arises.

What is "sluggish" about it is rather that you don't
even attempt to make an educated guess where the
problem is. But if you have absolutely no "education"
to your guess, isn't that the right thing to do - not
to do it?

Well, yes and no. In isolation, it makes sense not
doing something that isn't there. In the long run tho,
making educated guesses is a skill just as any I'd
say. Probably the sooner you start doing them, the
better they get.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Marcin Borkowski]

On 2016-02-19, at 21:43, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Or do it automatically.
>
> Here, we only consider serious suggestions :)

I was serious.  Have you looked at the link I provided?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: removing white space highlight

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>>> Or do it automatically.
>>
>> Here, we only consider serious suggestions :)
>
> I was serious.

I know. I wasn't.

> Have you looked at the link I provided?

I did look at the link but it looked like most links
I've seen to this day :)

Actually, I'd say solving the OPs problem
automatically with just about any tool is a minor
hacker achievement. If you, or anyone else does it,
I'll be impressed to the degree I'll read just about
anything including the collected travels of
Ryszard Kapuscinski.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Bob Proulx]

Luca Ferrari wrote:
> for some reason I don't know after applying a few theme settings I
> have Emacs now highlighting rows with only white spaces.
> That is a little annoying to me, so I'm wondering what is the
> customize-* I accidentally broke.
> Any suggestion is welcome.

I didn't see anyone suggest actually fixing the file to remove those
lines with trailing whitespace but I think is the best answer.  That
is the entire reason for the trailing whitespace highlighting in the
first place.  Make them visible instead of invisible so that they will
be addressed.

I know that a lot of people will say that it is whitespace and they
don't care.  Many years ago I would have been one of those people.
But now that version control is everywhere (among other things) I am
now sensitive to whitespace causing useless diffs in files.
Whitespace that I never cared about before is now cruft that I always
clean in order to avoid noisy diffs.

Therefore I suggest cleaning the whitespace cruft from those files and
then the annoying highlight face won't be shown anymore. :-)

Bob

Re: removing white space highlight

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

> now that version control is everywhere (among other
> things) I am now sensitive to whitespace causing
> useless diffs in files. Whitespace that I never
> cared about before is now cruft that I always clean
> in order to avoid noisy diffs.

Of course, there shouldn't be any superfluous
whitespace trailing individual text lines *or* the
file contents itself.

Here one way to do it:

    ;; (setq before-save-hook nil)
    (defun before-save-hook-f ()
      (delete-trailing-whitespace) )
    (setq before-save-hook #'before-save-hook-f)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Bob Proulx]

Emanuel Berg wrote:
> Of course, there shouldn't be any superfluous
> whitespace trailing individual text lines *or* the
> file contents itself.
> 
> Here one way to do it:
> 
>     ;; (setq before-save-hook nil)
>     (defun before-save-hook-f ()
>       (delete-trailing-whitespace) )
>     (setq before-save-hook #'before-save-hook-f)

That is one way to do it.  However I don't think it is a good idea to
do this automatically every time.  I would rather see that it needs to
be done and the do it intentionally.  Usually I will do one whitespace
only cleanup with no other changes and do it first.  That way diff -b
or -w or -B or other combination will show as clean with no
non-whitespace changes.  And then I make the change I want to make.
If it is automatic then this mixes those two things both at the same
time.  I would rather see them distict.

Bob

Re: removing white space highlight

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

>> Of course, there shouldn't be any superfluous
>> whitespace trailing individual text lines *or* the
>> file contents itself.
>> 
>> Here one way to do it ...
>
> That is one way to do it. However I don't think it
> is a good idea to do this automatically every time.
> I would rather see that it needs to be done and the
> do it intentionally.

Why?

> Usually I will do one whitespace only cleanup with
> no other changes and do it first. That way diff -b
> or -w or -B or other combination will show as clean
> with no non-whitespace changes.

If there is nothing to do,
`delete-trailing-whitespace', doesn't do anything.

Also, I have RET `newline-and-indent'. I never thought
about it, but what it does is it removes extra blanks
and breaks the line after the last char instead.

This is also something I can recommend for `C-k':

(defun kill-line-remove-blanks ()
  (interactive)
  (if (looking-at "[[:space:]]*$")
      (let ((end (point-max)))
        (delete-blank-lines)
        (when (= end (point-max))
          (delete-horizontal-space)
          (delete-char 1))
        (when (and (= (point-min) (point))
                   (looking-at "[[:space:]\n]") )
          (kill-line) ))
    (kill-line) ))

It works like this - if we let that the char for full
stop (or "period", i.e. "." ) represent point
position:

    Text line which isn't empty 1...
    .
    Text line which isn't empty 2...

Here, the result of invoking the command will be

    Text line which isn't empty 1...
    Text line which isn't empty 2...

But here -

    Text line which isn't empty 1...
    .

    (add arbitrarily blank lines here)
    Text line which isn't empty 2...

- the result will be:

    Text line which isn't empty 1...
    .
    Text line which isn't empty 2...

Interesting!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Bob Proulx <bob@proulx.com> writes:
>
>>> Of course, there shouldn't be any superfluous
>>> whitespace trailing individual text lines *or* the
>>> file contents itself.
>>> 
>>> Here one way to do it ...
>>
>> That is one way to do it. However I don't think it
>> is a good idea to do this automatically every time.
>> I would rather see that it needs to be done and the
>> do it intentionally.
>
> Why?

Most people want to delete whitespace because of version control.
They're working in a team that uses a VC program of some sort.  There's
little reason to delete whitespace otherwise, it doesn't cause any
problems for editing or take up much hard disk space.

In that case the programmer wants to make changes to a specific part of a
file.  Deleting whitespace from the whole file will cause other changes
elsewhere.  Causing spurious changes for whitespace reasons is frowned
upon in most teams.

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

>> Why?
>
> Most people want to delete whitespace because of
> version control. They're working in a team that uses
> a VC program of some sort. There's little reason to
> delete whitespace otherwise, it doesn't cause any
> problems for editing or take up much hard
> disk space.
>
> In that case the programmer wants to make changes to
> a specific part of a file. Deleting whitespace from
> the whole file will cause other changes elsewhere.
> Causing spurious changes for whitespace reasons is
> frowned upon in most teams.

Yes, so why not have it automatized once and for all
and then never have to think about it?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Marcin Borkowski]

On 2016-02-21, at 04:31, Emanuel Berg <embe8573@student.uu.se> wrote:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>>> Why?
>>
>> Most people want to delete whitespace because of
>> version control. They're working in a team that uses
>> a VC program of some sort. There's little reason to
>> delete whitespace otherwise, it doesn't cause any
>> problems for editing or take up much hard
>> disk space.
>>
>> In that case the programmer wants to make changes to
>> a specific part of a file. Deleting whitespace from
>> the whole file will cause other changes elsewhere.
>> Causing spurious changes for whitespace reasons is
>> frowned upon in most teams.
>
> Yes, so why not have it automatized once and for all
> and then never have to think about it?

This assumes that /everyone/ on the team does the same, right?  It need
not be the case.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: removing white space highlight

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> This assumes that /everyone/ on the team does the
> same, right? It need not be the case.

Yes: this solution must be applied otherwise it
won't work.

Still, if everyone else messes it up you sleep well
knowing the files that you dealt with were always
passed on in excellent condition.

Another idea is to have your collaboration software
*ignore* changes in non-semantic whitespace (i.e., not
ignoring blanks in strings and so on where it produces
a different result).

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Feb 21, 2016 at 04:31:01AM +0100, Emanuel Berg wrote:

[...]

> Yes, so why not have it automatized once and for all
> and then never have to think about it?

Because it's a very rude thing to do when working with others?

If a (biggish) project has "whitespace issues", the sensible way of
doing it is:

 - agree that it's an issue. Otherwise *do nothing*. Introducing
   whitespace diffs at this stage "because I thing it's the right
   thing, dammit" is arrogant and unpolite -- and might result
   on being scolded. Rightfully so.

 - agree on a strategy. It could be "whenever a file is touched
   for whatever reason (a) or in a orchestrated series of commits (b)

 - in case (a) it's still meaningful to dedicate one commit to
   the whitespace change itself

 - in case (b) it'd make sense to agree on some time frame.

Of course, this wouldn't apply on a "clean" slate, where such
tools are definitely a plus. Still I'd prefer an indication to
a silent fix -- when fixing whitespaces in other's code, I'd
*always* ask first.

Working with others has its price.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlbJpB4ACgkQBcgs9XrR2kaBKgCdEaQSE3VEzPr2c2IZV0ilA2pj
+IoAn1NhPsvuKKR6GIWTLJ3obYUYLWwT
=RiPF
-----END PGP SIGNATURE-----

Re: removing white space highlight

[Emanuel Berg]

<tomas@tuxteam.de> writes:

>> Yes, so why not have it automatized once and for
>> all and then never have to think about it?
>
> Because it's a very rude thing to do when working
> with others?

It is a generous thing. They see how the problem can
be solved so they can solve it themselves if they
haven't already and thus elevate their games further.

> agree that it's an issue. [...]
> agree on a strategy [...]
> agree on some time frame [...]

*yawn*

Wake me up when it is time to start working!

> Otherwise *do nothing*.

Not likely.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Luca Ferrari]

On Sat, Feb 20, 2016 at 8:08 PM, Bob Proulx <bob@proulx.com> wrote:
> I didn't see anyone suggest actually fixing the file to remove those
> lines with trailing whitespace but I think is the best answer.  That
> is the entire reason for the trailing whitespace highlighting in the
> first place.  Make them visible instead of invisible so that they will
> be addressed.

A good point indeed, but I don't want to see whitespaces in every kind
of buffer (e.g., programming ones are the one that make more sense),
and moreover being able to find out what is causing them emphatized
allows me to set my custom settings. So far I've  a dark theme with
whitespaces in lime, that as you can immagine is quite a punch in the
eye.

Luca

Re: removing white space highlight

[Emanuel Berg]

Luca Ferrari <fluca1978@infinito.it> writes:

> and moreover being able to find out what is causing
> them emphatized allows me to set my custom settings.

Well, sometimes "For everyone who asks receives" but
don't rely on it, instead go for the "he who seeks
finds".

So start examining your settings line by line with any
method you'd like...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

>> agree that it's an issue. [...]
>> agree on a strategy [...]
>> agree on some time frame [...]
>
> *yawn*
>
> Wake me up when it is time to start working!
>
>> Otherwise *do nothing*.
>
> Not likely.

If I were running a team and you were on it, I have a feeling you'd get chucked off it rather quickly.

I the problem is worse than Tomas mentions.  What about past
programmers?  How do we get those to behave themselves regarding
whitespace?  Sadly it's impossible.

BR,
Robert Thorpe

Re: removing white space highlight

[Robert Thorpe]

Luca Ferrari <fluca1978@infinito.it> writes:

> On Sat, Feb 20, 2016 at 8:08 PM, Bob Proulx <bob@proulx.com> wrote:
>> I didn't see anyone suggest actually fixing the file to remove those
>> lines with trailing whitespace but I think is the best answer.  That
>> is the entire reason for the trailing whitespace highlighting in the
>> first place.  Make them visible instead of invisible so that they will
>> be addressed.
>
> A good point indeed, but I don't want to see whitespaces in every kind
> of buffer (e.g., programming ones are the one that make more sense),
> and moreover being able to find out what is causing them emphatized
> allows me to set my custom settings. So far I've  a dark theme with
> whitespaces in lime, that as you can immagine is quite a punch in the
> eye.

Did you say you're using Spacemacs?  If so, you could try their mailing
list.

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> I the problem is worse than Tomas mentions.
> What about past programmers? How do we get those to
> behave themselves regarding whitespace?
> Sadly it's impossible.

Have the software do this automatically. Then past,
present, and future programmers can misbehave all
they want.

Or submit correct files to begin with. Their choice.

It is like a calculator.

One person inputs 3 + 7 and another 11 - 1 for the
number of fingers. The calculator still shows 10.

Dig?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> I the problem is worse than Tomas mentions.
>> What about past programmers? How do we get those to
>> behave themselves regarding whitespace?
>> Sadly it's impossible.
>
> Have the software do this automatically. Then past,
> present, and future programmers can misbehave all
> they want.

How do you do that without creating lots of check-ins to the VC system?

Of course, making the VC program treat whitespace specially is an
option.  I think it's one some people are looking into.  AFAIK it's not
there yet though.

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> How do you do that without creating lots of
> check-ins to the VC system?
>
> Of course, making the VC program treat whitespace
> specially is an option. I think it's one some people
> are looking into. AFAIK it's not there yet though.

Upon submission:

    emacs -Q -batch FILE -eval '(delete-trailing-whitespace)' -f save-buffer

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> How do you do that without creating lots of
>> check-ins to the VC system?
>>
>> Of course, making the VC program treat whitespace
>> specially is an option. I think it's one some people
>> are looking into. AFAIK it's not there yet though.
>
> Upon submission:
>
>     emacs -Q -batch FILE -eval '(delete-trailing-whitespace)' -f save-buffer

Suppose a programmer makes a small change to a file.  Then the above is
run, because of whitespace changes that could lead to hundreds of
changes.  After that, how does anyone make sense of the VC annotated
version of the file?

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Suppose a programmer makes a small change to a file.
> Then the above is run, because of whitespace changes
> that could lead to hundreds of changes. After that,
> how does anyone make sense of the VC annotated
> version of the file?

It will be easier then before to make sense of that
file, because after the hundreds of changes it'll look
a lot better.

People will get the new version and that will replace
their local ones which will also be upgraded (to the
better).

Next time there is an edit there will be no need to
fix hundreds of meaningless whitespaces.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Luca Ferrari]

On Thu, Feb 25, 2016 at 1:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
> People will get the new version and that will replace
> their local ones which will also be upgraded (to the
> better).

That's the problem: I don't want to have a lot of checkins due to
someone in my team just removing white spaces.
Try it at home: checkout a file, remove all the spaces and do a
diff....and try to find out what line of code you changed amongst the
space removal!



Luca

Re: removing white space highlight

[Christian Kruse]

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

Hi,

Luca Ferrari <fluca1978@infinito.it> writes:

> On Thu, Feb 25, 2016 at 1:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
>> People will get the new version and that will replace
>> their local ones which will also be upgraded (to the
>> better).
>
> That's the problem: I don't want to have a lot of checkins due to
> someone in my team just removing white spaces.
> Try it at home: checkout a file, remove all the spaces and do a
> diff....and try to find out what line of code you changed amongst the
> space removal!

Despite the discussion itself: you can ignore lines with only space
changes in all VCS:

git diff -w
svn diff -x -b
diff -b
bzr diff --diff-options='-w'
hg diff -w

Best regards,
-- 
Christian Kruse
https://wwwtech.de/about

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> Suppose a programmer makes a small change to a file.
>> Then the above is run, because of whitespace changes
>> that could lead to hundreds of changes. After that,
>> how does anyone make sense of the VC annotated
>> version of the file?
>
> It will be easier then before to make sense of that
> file, because after the hundreds of changes it'll look
> a lot better.

Certainly the file itself will be better.  Only slightly in my opinion,
whitespace at the end of lines doesn't both me much.

The question is what about the *VC annotated* file?  If I blame a
particular section of a file how do I know who wrote that code and when?
The problem is I can't tell because any particular check-in could be a
whitespace change.  I'd actually have to start digging through older
versions.

Christian Kruse is correct that diffs can be handled, but they're not
the only problem.

BR,
Robert Thorpe

vc-region-history promotion (was: removing white space highlight)

[Stefan Monnier]

> The question is what about the *VC annotated* file?  If I blame a
> particular section of a file how do I know who wrote that code and when?
> The problem is I can't tell because any particular check-in could be a
> whitespace change.  I'd actually have to start digging through older
> versions.

I agree such "unrelated changes" are generally undesired.
[ In the case of Emacs's own source code, we try to follow a policy where
people are allowed to "fix whitespace" but only in those places where
they're making other changes as well.  So a whose-file cleanup of
trailing whitespace is not accepted.  ]

This said, I recently stopped using vc-annotate and so don't care nearly
as much any more: instead I use vc-region-history, which gives me much
more detailed information where such whitespace games aren't very much
of a problem.  I'd been dreaming of a functionality like
vc-region-history ever since I started using TLA (i.e. before Bazaar
existed), and oddly enough so far only Git offers that feature, AFAIK.

vc-region-history also solves the problem of vc-annotate's blindness to
code removal (the vc-annotate output won't tell you where code was
removed, and even less by whom).


        Stefan

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> The question is what about the *VC annotated* file?

That will only be the case once.

After that the code looks good - everyone gets the
good code - and no one is capable of adding whitespace
that creates the situation again.

You can't make an omelette without breaking eggs, as
the Russians said in the 30s...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> The question is what about the *VC annotated* file?
>
> That will only be the case once.

No it won't.  It'll be like that until every line that has had
whitespace changes ceases to be current.  That could take decades.
There's still plenty of GNU Emacs that comes from the first check-in to
version-control in 80s.

Perhaps vc-region-history is the answer, as Stefan says, I haven't used
it.  But, as he says, it only works on git.

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

>> That will only be the case once.
>
> No it won't. It'll be like that until every line
> that has had whitespace changes ceases to be
> current. That could take decades. There's still
> plenty of GNU Emacs that comes from the first
> check-in to version-control in 80s.

I'll be like that once for every file.

You can even do it all at once!

After, add automatization and people can't break it
even if they want to:

1. There is no trailing whitespace anywhere in
   the source.

    - and -

2. It is impossible to add any because it is
   automatically removed upon submitted changes
   including the addition of new files...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>>> That will only be the case once.
>>
>> No it won't. It'll be like that until every line
>> that has had whitespace changes ceases to be
>> current. That could take decades. There's still
>> plenty of GNU Emacs that comes from the first
>> check-in to version-control in 80s.
>
> I'll be like that once for every file.

Yes, for decades.

That's far too high a price to pay for being perfectionist about
whitespace.

I don't think you understand how useful blaming is to people who do
maintenance programing.  I'm not sure you really understand what I mean.

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

>> I'll be like that once for every file.
>
> Yes, for decades.

Are there so really so many files that are left
untouched for so long?

Why can't you do it once for all files?

Or, by all means, do it as it goes along. It should
only happen when a file is edited or added. If it is,
all the better: it is forever fixed. If it isn't
edited this isn't an issue as nothing will
happen anyway.

> That's far too high a price to pay for being
> perfectionist about whitespace.

Being a perfectionist in the negative sense is
spending too much time on stuff that doesn't mean
anything, really, and/or being neurotic about it.

This discussion for example is perhaps closing in on
that :)

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...

> I don't think you understand how useful blaming is
> to people who do maintenance programing.

If this is automatized like I've described the issue
should forever be removed from the realm of humans.
Only the machines will know about it before long...

But I'm fine ending the discussion. I'm not
maintaining any cooperative software anyway and
I don't plan to, ever. I'm a solo climber. When there
is one person, he knows where the rope is. When there
is twenty everyone subconsciously relax and suddenly
at the attack camp there is a bottleneck and the guy
first in line says: "Where is the gear? Where is
the equipment?" Uh-oh!

I know where my rope is - here:

    ;; (setq before-save-hook nil)
    (defun before-save-hook-f ()
      (delete-trailing-whitespace) )
    (setq before-save-hook #'before-save-hook-f)

:)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Bob Proulx]

Emanuel Berg wrote:
> Robert Thorpe writes:
> >> I'll be like that once for every file.
> >
> > Yes, for decades.
> 
> Are there so really so many files that are left
> untouched for so long?

I have been staying out of this because Robert has been doing an
excellent job of stating the issues.  But I guess I will do my part
too.

> Why can't you do it once for all files?

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.

While producing a changeset it isn't enough simply to produce any old
set of changes.  Any slacker can made a random change and produce a
truly awful large patch.  It is the excellent programmer that
understands the entire development process and produces a change that
is easily reviewed so that it will be quickly accepted.  I assume that
if you are making a change that you are wanting it to be accepted.  If
not then why bother at all?

I think that is the main point you are missing.  You are thinking
about yourself but you should be thinking about the reviewers who will
look at the work you have done.  If you are not thinking about their
job then you are making their job much harder.  If you make their job
too hard they should simply reject your change and send you back to
work on it further.

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.

> > That's far too high a price to pay for being
> > perfectionist about whitespace.
> 
> Being a perfectionist in the negative sense is
> spending too much time on stuff that doesn't mean
> anything, really, and/or being neurotic about it.

You discover a small chip of paint flaking off of the side of your
house.  Nothing is stopping you from immediately sanding, doing a full
paint preparation with all of the needed caulking, then priming, then
painting.  Nothing is stopping you from doing this quite expensive,
multiple day task immediately.  Except that you may have been leaving
for the airport to go on travel and just don't have time to do that
before your flight takes off.  And you might be out of budget for
painting the house right now.  You will probably not do all of these
needed things /right now/ but queue them up for doing at some later
time.  And it is only a paint chip.  A small thing.  That later time
might be years later.

In the way that life is often busy with multiple things going on at
the same time the same is true for software development.  On large
long running projects there will be many files that are doing their
job fine but perhaps are not perfect in the abstract.  While fixing a
showstopper critical security hole bug in someone else's project that
needs to make a minimum changeset immediately if not sooner you might
see other things that could be polished up.  You could drop everything
and then spend six months fixing up that other project.  But you
can't.  You need to make a minimum changeset patch to fix that problem
/right now/.  It needs to get through peer review and deployed.  It
can't wander about and tinker with other random things.  And there is
other work that needs to be done.

This is why I think cleanup should be done explicitly as an explicit
action and not as a side effect of other random changes.

> 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.

Remember that with great power comes great responsibility.

Bob

[[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.]]

Re: removing white space highlight

[Emanuel Berg]

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

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> This discussion for example is perhaps closing in on
> that :)

Yes.  I'll have one last go at it though.

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>>> I'll be like that once for every file.
>>
>> Yes, for decades.
>
> Are there so really so many files that are left
> untouched for so long?

Not files, no, I'm talking about *lines*.

Perhaps an example will clarify things....  Here is the (fictional)
output of "svn annotate" on a fictional file:

$ svn blame nasty.c
     103      sally /* important_parameter should be */
     103      sally /* set for modern memory sizes. */
     115      harry int important_parameter = 42;
     103      sally

For each line the revision is given when the file was changed, and the
person who changed it.  You can get this with C-x v g from Emacs.

Let's say that version 115 was a reasonably recent.  In that case it's
likely that Harry set tuned important_parameter for current memory sizes
at that time.

But, what if Harry just deleted some extraneous whitespace from the end
of the line?  In that case we can't be sure when important_parameter was
last set.  It may be very old.

Removing the whitespace change we may have the situation:

$ svn blame -x -b nasty.c
     103      sally /* important_parameter should be */
     103      sally /* set for modern memory sizes. */
      24      terry int important_parameter = 42;
     103      sally

This shows that the last actual change was in revision 24, which was
years ago.

In the Subversion manual it explicitly mentions this situation.
Subversion has a command to deal with it, "-x -b", which ignores
whitespace changes.  Not all version controls systems have that.  It's
also not very well known and tools that use the VC system (GUIs and
Editors) may not use it.  Stefan mentions that Git has a way of doing
this too.

When all the tools deal with this situation well then I'll be happy with
indiscriminate whitespace changes, but we're not at that point yet.

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> But, what if Harry just deleted some extraneous
> whitespace from the end of the line? In that case we
> can't be sure when important_parameter was last set.
> It may be very old.

You can do it to the entire project once (and do
nothing else at that point). Then add automatic
cleaning upon submission, don't log the cleaning, and
last propagate the correct files to anyone who doesn't
have them.

> Not all version controls systems have that.

Apparently not :)

But I do (phew)

> It's also not very well known and tools that use the
> VC system (GUIs and Editors) may not use it.

The editors don't need it, tho it can be useful for
other purposes (e.g., your own files) and it doesn't
hurt having it there as well.

The automatization doesn't fare ill from you having it
in your editor as well, as then it doesn't have to
execute (nothing to do).

Obviously the VC needs it because that is were the
automatization should kick in.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> But, what if Harry just deleted some extraneous
>> whitespace from the end of the line? In that case we
>> can't be sure when important_parameter was last set.
>> It may be very old.
>
> You can do it to the entire project once (and do
> nothing else at that point).

Let's say I remove whitespace from the entire project.  I then check the
project back in.  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.

To go back to my previous example

$ svn blame nasty.c
     103      sally /* important_parameter should be */
     103      sally /* set for modern memory sizes. */
     110      rob   int important_parameter = 42;
     103      sally

Here, I have removed all the whitespace at revision 110.  That makes it
look as though I set the value of important_parameter then.  In fact, it
was set much earlier.

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.

Of course, if it were possible to modify the version control program
then this would be possible.  Doing that is "non-trivial", as they say.

> Then add automatic
> cleaning upon submission, don't log the cleaning, and
> last propagate the correct files to anyone who doesn't
> have them.
>
>> Not all version controls systems have that.
>
> Apparently not :)

You don't understand version control systems.  You can't change how they
work easily.

>> It's also not very well known and tools that use the
>> VC system (GUIs and Editors) may not use it.
>
> The editors don't need it, tho it can be useful for
> other purposes (e.g., your own files) and it doesn't
> hurt having it there as well.

This part of the discussion was about what happens if the version
control system has an option to deal with whitespace changes.  For
example, "-x -b" in Subversion.

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."

BR,
Robert Thorpe

Re: removing white space highlight

[Emanuel Berg]

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

Re: removing white space highlight

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> 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.

We all agree about the improvement.  The problem is making it happen
without destroying the power of version control.

> This is completely free of charge with no penalty to
> it whatsoever.

How do you remove the penalty then?  How do you make blame/annotate and
similar tools work properly despite the changes in whitespace?

Are you arguing that annotate and diffs with previous version don't
matter?

> Before anything enters there, cleaning is
> automatically done, but not logged (well, not logged
> as normal edits are anyway)

Most VC systems don't support that.  The only way you can do that is by
either:
* Writing a feature into the version control program itself.
* Writing a program that understands the file format that the VC
  repository is in.
Neither path is easy.  Version control programs are long and complex.
Many are longer than 50000 lines.  The file formats they use for the
repository are complex too and very difficult to reverse engineer.  I
know because I had to reverse engineer one of them once.

> The theoretical reason why this is possible and easy
> is that nobody (human nor machine) has any interest in
> or benefits from trailing whitespace. 

Yes, it's simple in theory, but very difficult in practice.  I'm
disappointed to see you of all people confuse the theoretical and the
practical.

BR,
Robert Thorpe