I like the springy version, I can 'feel' the shape of the file. [LWN.net]

But why ?

Posted Oct 31, 2006 10:16 UTC (Tue) by fooker (guest, #14834) [Link]

Why would you care if you have spaces at the end of the line?

Off the top of my head:

I'd like to move from the end of line to the beginning of the next line.
I'd like to add text to the end of line.
I'd like to join two consecutive lines.
I'd like to see differences between two revisions of a file.

Each scenario is pretty common when programming, and having extra whitespace inserted randomly at the end of line by the editor is Bad Thing(tm) in each case (how does a program know when whitespace at the end of line matters and when it doesn't).

Relying on something that you can't see is very bad design anyway.

Like having whitespace appearing magically at the end of line?

Thinking about the "shape of the line" is not what you need to be doing when programming. (Well, unless you are writing a makefile, but that clearly was a terrible design mistake in make).

Yes, indeed. So terrible that Guido van Rossum copied the mistake to Python. The "shape of the line" is very important when programming in any language. That's why we indent our code and group related functionality by adding empty lines.

The only legitimate reason for having magic whitespace is writing a program in Befunge (but that also can be done just as easily by using picture-mode).

But why ?

Posted Oct 31, 2006 16:04 UTC (Tue) by mikov (subscriber, #33179) [Link]

You don't seem to understand my point at all. I don't want to start a
religious war- as I said, it is as much about habit as it is
about logic. I however have the advantage of having extensively used both
ways of editing. I am replying not show that you are wrong, but to explain
my position and hopefully to prove that it is at least as valid. It is
certainly more logical.

> I'd like to move from the end of line to the beginning of the next
line.
>I'd like to add text to the end of line.
>I'd like to join two consecutive lines.

I agree this is a valid reason. This is what the 'end' key is for, but if
you feel that you may have to press it too often (not in my experience,
but I am subjective), then this mode of editing is not convenient for you.

>I'd like to see differences between two revisions of a file.

As I said (and you obviously ignored), editors have the option to remove
the invisible spaces at the end of a line automatically. This option
should be on at all times when editing software in any programming
language that I know.

> Each scenario is pretty common when programming, and having extra
whitespace inserted randomly at the end of line by the editor is Bad
Thing(tm) in each case (how does a program know when whitespace at the end
of line matters and when it doesn't).

Space is not inserted randomly. Why would it be inserted
randomly ?? I believe I addressed the other points too.

>Like having whitespace appearing magically at the end of line?

You keep repeating that, but it is simply not true. The _only_ way for
more spaces to appear is if you press a _non-space_ character somewhere
after the physical end of the line. Spaces are inserted between the end of
the line and the character your pressed. Is that so hard to understand ?
How else could it be ?

You seem overly concerned with spaces - they are ignored by all
programming languages (including Python), for god's sake. Also, they are
invisible. You should not have to think about them at all.

> Yes, indeed. So terrible that Guido van Rossum copied the mistake to
Python. The "shape of the line" is very important when programming in any
language. That's why we indent our code and group related functionality by
adding empty lines.

I feel silly when saying this, since it is obvious, but Python cares about
spaces _at the beginning of the line_. The spaces at the end of a line,
even if they are not automatically removed (which they are!), are
completely and totally irrelevant in all programing languages. This has
absolutely nothing to do with indentation.

Empty lines have nothing to do with it either - an empty line is equally
as empty if it has spaces.

Editors should not violate the principle of least surprise

Posted Oct 31, 2006 23:54 UTC (Tue) by xoddam (subscriber, #2322) [Link]

> The spaces at the end of a line ... are completely and totally
> irrelevant in all programing languages.

> Empty lines have nothing to do with it either - an empty line
> is equally as empty if it has spaces.

True for most programming languages, yes. But whitespace
differences are significant in revision control systems,
with good reason.

Editors should never, ever make a change to a file without
being explicitly instructed to do so and making the change
visible to the user (so users can correct their own mistakes).

If your editor enforces a hard-and-fast rule that spaces at the
end of the line should always be removed, then as long as you
only ever use that editor, it sticks to this principle. But if
you edit a file which, for whatever random unreasonable reason,
contains spaces at the end of a line, that editor will change
something you can't see. And if, as is sometimes the case for
the most esoteric reasons (hey, I never *chose* to use autotools,
I just inherited the build system!) trailing whitespace is
actually required -- why then your editor breaks not only the
principle of least surprise, but also your program.

But why ?

Posted Nov 1, 2006 2:15 UTC (Wed) by ibukanov (subscriber, #3942) [Link]

> There are many programmers coming from the DOS & Windows world that prefer the behavior I am describing.

That is very true. When after 5 years of Turbo/Borland Pascal/C for Dos/Windows I started to use Unix/Linux, I spent some time trying to configure editors for that virtual space behaviour with no success. I even tried to create an Emacs mode for that. But then I gave up after realizing how non-trivial it would be and just started to ignore those cursor jumps during vertical movements. But sometimes they still annoy me after almost 10 years of using Emacs.

I guess this is really some cultural difference.