Fanning the flames... [LWN.net]

Fanning the flames...

Posted Oct 30, 2006 20:29 UTC (Mon) by mikov (subscriber, #33179)
In reply to: Fanning the flames... by donbarry
Parent article: GNU emacs 22 goes into pretest

I am sorry, but picture-mode is completely unusable for editing source
code. Have you tried it ? :-) I don't want to edit ASCII art, I want to be
able to move my cursor in a logical fashion.

Look at these two lines:
line1
line2

On line1 I can position my cursor at column 20. On line2 I can't. Why ??
Because line1 has lots of spaces added. Since I can't see the spaces, why
should I be restricted from positioning my cursor anywhere I want ? I
should be able to press down arrow from column 20 on line1 and start
typing on column 20 on line2. The editor can insert the necessary spaces
automatically - it isn't rocket science :-)

This is not theoretical. Imagine this scenario:

long long long long long long long BUG1 more text.
foo
longer longer longer longer longer BUG2 more text.

After fixing BUG1 I intuitively press the down arrow to move towards BUG2
and fix it too. Surprise - the cursor disappears and moves far to the left
by 'foo' at column 4. Why ?? What dark magic is restricting the cursor
from some areas of the screen ??

No matter, I press the down arrow again. At this time different editors
choose to do different things:

- Some keep the cursor cursor at column 4, so I have to move it all the
way to BUG2 again. Total and utter cr*p.

- Others try to be smart and move the cursor to BUG2 because they remember
the old position. Of course that is completely illogical - why should
moving the cursor DOWN from column 4 on line 2 result in positioning it at
column 20 on line 3 ??

The only logical behavior is to allow free movement of the cursor in all
directions and automatically insert spaces when necessary. Many editors
under DOS used to do that - it is actually the simplest to implement.

(Log in to post comments)

But why ?

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

Why would you care if you have spaces at the end of the line ? They for
sure don't matter in most programming languages. A setting to
trim spaces at end of line automatically is the most reasonable solution.
Relying on something that you can't see is very bad design anyway.
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).

I think that whether most people like "virtual space" or not is not as
clear cut as you'd think (depending on your background). There are many
programmers coming from the DOS & Windows world that prefer the behavior I
am describing. Most of these people think that both 'vi' and 'Emacs' are
terrible text editors. I am not terribly fond of them either - I like
selecting text with shift+arrows, for example :-)

Of course I don't kid myself that I can convince anyone that it is better
(it is equally futile to participate in the TAB vs SPACE wars :-) -
ultimately for things like this habit trumps logic. That applies to me
too, of course.

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.