best text editor for programming Python on a Mac
torriem at gmail.com
Sat Jun 18 22:09:11 EDT 2016
On 06/18/2016 06:12 PM, Lawrence D’Oliveiro wrote:
> Pull up any old GUI-based editor you like, for example Windows
> (shudder) Notepad. If there are N characters in your file, then the
> insertion point can be placed at N + 1 positions: in-between two
> adjacent characters, or before the first character, or after the last
> character. And this makes sense: anything you type is inserted at the
> insertion point. All rational text editors (and word processors) work
> this way.
> But not vi/vim. It only lets you place your cursor *on* a character,
> not *in-between* characters. That’s why you need two separate
> insertion commands, insert-before and insert-after. And one of those
> has the interesting side effect where, if you exit insertion mode
> without inserting anything, it doesn’t put you back in the same
> position as before. Why?
In thinking about this, I think the answer is that in olden days no one
had though of using the imaginary spaces between characters as a
position. So we had:
0 1 2 3 4 5 6 7 8 9
H E L L O W O R L D
10 character cells, 10 cursor positions. Hence you had 10 places you
could insert before (which works well for everything but appending to
the string) or 10 places to insert after. So that distinction between
insert and append was logical, and still is today, depending on your
background and experience.
It was later on that they figured out the N+1 thing you mentioned by
ignoring the character cells:
0 1 2 3 4 5 6 7 8 9 10
H E L L O W O R L D
That works well for interactive editing, but it doesn't lend itself as
well to scripting and working with the contents of the text cells.
Indeed the text cells aren't actually addressable directly in this
scheme though conventionally the number immediately before the cell is
used to index the cell. This can lead to confusion. For example, if
the cursor is in position 10, that's not really part of the text, but it
kind of appears like it is.
I like that with vim I can see immediately whether there is trailing
space on a line just by jumping to the end of the line ($) which will
drop the cursor on the last actual character.
So I guess it's just a matter of history. Perhaps it's a bit like big
endian vs little endian. Neither system is inherently better; it's just
what you get used to. And arguments can be made either way.
More information about the Python-list