An Editor that Skips to the End of a Def

2 views
Skip to first unread message

W. Watson

unread,
Sep 20, 2007, 12:31:07 PM9/20/07
to
Is there an editor that allows one to position to put the cursor and then by
pushing some button goes to the end of the def?
--
Wayne Watson (Nevada City, CA)

Web Page: <speckledwithStars.net>

Bruno Desthuilliers

unread,
Sep 20, 2007, 12:49:52 PM9/20/07
to
W. Watson a écrit :

> Is there an editor that allows one to position to put the cursor and
> then by pushing some button goes to the end of the def?

Emacs. And you don't even have to "push some button" (just remember the
correct key sequence !-)

Paul Rudin

unread,
Sep 20, 2007, 12:53:57 PM9/20/07
to
"W. Watson" <wolf_...@invalid.com> writes:

> Is there an editor that allows one to position to put the cursor and
> then by pushing some button goes to the end of the def?

C-M-e in emacs/python-mode.

W. Watson

unread,
Sep 20, 2007, 1:04:20 PM9/20/07
to
Thanks, but no thanks. The learning curve is way too steep.

--

Paul Rudin

unread,
Sep 20, 2007, 1:14:17 PM9/20/07
to
"W. Watson" <wolf_...@invalid.com> writes:

> Thanks, but no thanks. The learning curve is way too steep.

Up to you but, these days emacs comes with all sorts of
pointing-clicky-menu-y type things - you don't really have to learn
anything to get started.

(It even gives useful advice on top-posting if you use it as a news
client :/)

alex

unread,
Sep 20, 2007, 2:44:47 PM9/20/07
to
> Paul Rudin wrote:
>> "W. Watson" <wolf_...@invalid.com> writes:
>>
>>> Is there an editor that allows one to position to put the cursor and
>>> then by pushing some button goes to the end of the def?
>>
>> C-M-e in emacs/python-mode.
>
W. Watson wrote:
> Thanks, but no thanks. The learning curve is way too steep.

There are two good editors for writing code -- vim and emacs.
If you write more than a few lines of code a year you should learn
one of them. Time spent doing it will pay for itself *very* quickly.

--
Alex

John J. Lee

unread,
Sep 20, 2007, 3:13:54 PM9/20/07
to
"W. Watson" <wolf_...@invalid.com> writes:

> Thanks, but no thanks. The learning curve is way too steep.

[...]

Eclipse must be able to do this.

Eclipse is emacs for stupid people ;-)

Seriously for a moment, I read something recently (maybe here?) about
an Apple study that claimed to show that people who perceived keyboard
bindings as being much faster than mouseing did not, on average, take
less time to complete the actions that were studied (they took more
time, in fact). The plausible explanation for this was that people's
subjective perception of time is affected by the greater mental work
involved in typing (as opposed to mousing) for a given action.

I suspect the reality is at neither extreme (nor "somewhere in the
middle").


John

Michael v. Fondern

unread,
Sep 20, 2007, 3:28:36 PM9/20/07
to
W. Watson:

> Is there an editor that allows one to position to put the cursor and
> then by pushing some button goes to the end of the def?

Eclipse, together with the pydev plugin.

(Ctrl-Shift-Down)

Greetings

- Michael -

Paul Rubin

unread,
Sep 20, 2007, 3:32:52 PM9/20/07
to
j...@pobox.com (John J. Lee) writes:
> Seriously for a moment, I read something recently (maybe here?) about
> an Apple study that claimed to show that people who perceived keyboard
> bindings as being much faster than mouseing did not, on average, take
> less time to complete the actions that were studied (they took more
> time, in fact). The plausible explanation for this was that people's
> subjective perception of time is affected by the greater mental work
> involved in typing (as opposed to mousing) for a given action.

I think mousing takes more mental work than typing, and that's why it
subjectively seems slower even if a stopwatch shows it to be faster.

I have IM text chats with my officemate all the time even though he's
sitting about 4 feet away from me and I could easily talk to him and
that would probably be faster. But text chat needs less mental effort
since it doesn't take my attention away from symbols on the screen,
i.e. when the chat topic is something simple, I don't lose mental
context of the program I'm working on and then have to spend time
getting the context back. In that sense, text chats save time
compared with regular conversations even though they're slower.

Of course if the chat subject gets complicated and starts needing
careful thought, then it's better to switch to conversation, and
sometimes we both simultaneously realize that and start talking to
each other or using the whiteboard.

W. Watson

unread,
Sep 20, 2007, 3:56:09 PM9/20/07
to
Maybe I'll take a look. When I left the world of Unix/Linux 10 years ago,
emacs went with it, as did vi.

--

Gary Coulbourne

unread,
Sep 20, 2007, 4:48:16 PM9/20/07
to
John J. Lee wrote:
> Eclipse must be able to do this.

Not by default... but I am certain there are plugins that provide python
integration. (And jython integration)

Peace,
Gary

W. Watson

unread,
Sep 20, 2007, 11:24:40 PM9/20/07
to
Is vim just an editor or is it capable of running and debugging a program,
as well?

Ben Finney

unread,
Sep 20, 2007, 11:39:13 PM9/20/07
to
"W. Watson" <wolf_...@invalid.com> writes:

> Is vim just an editor or is it capable of running and debugging a
> program, as well?

(Please don't top-post. Instead, reply below each point to which
you're responding, removing quoted text irrelevant to your response.)

Both Emacs and Vim are highly customisable text editors. They are
configurable with complete programming languages specific to the
program, and both have a huge community of programmers writing useful
extensions.

So, neither of them is "just an editor"; they are editors at their
core, that can become complete programming environments by taking
already-written components for them. Your operating system
distribution of either Vim or Emacs will already include many of these
components when you install the package, and many more are available.

--
\ "The restriction of knowledge to an elite group destroys the |
`\ spirit of society and leads to its intellectual |
_o__) impoverishment." —Albert Einstein |
Ben Finney

W. Watson

unread,
Sep 20, 2007, 11:47:41 PM9/20/07
to
How about in the case of MS Win?

Ben Finney wrote:
> "W. Watson" <wolf_...@invalid.com> writes:
>
>> Is vim just an editor or is it capable of running and debugging a
>> program, as well?
>
> (Please don't top-post. Instead, reply below each point to which
> you're responding, removing quoted text irrelevant to your response.)
>
> Both Emacs and Vim are highly customisable text editors. They are
> configurable with complete programming languages specific to the
> program, and both have a huge community of programmers writing useful
> extensions.
>
> So, neither of them is "just an editor"; they are editors at their
> core, that can become complete programming environments by taking
> already-written components for them. Your operating system
> distribution of either Vim or Emacs will already include many of these
> components when you install the package, and many more are available.
>

--

Bruno Desthuilliers

unread,
Sep 21, 2007, 3:19:40 AM9/21/07
to
W. Watson a écrit :

> How about in the case of MS Win?
>
> Ben Finney wrote:
>>
>> (Please don't top-post. Instead, reply below each point to which
>> you're responding, removing quoted text irrelevant to your response.)
>>

Wayne, may I second Ben on his suggestion to stop top-posting ?

Bruno Desthuilliers

unread,
Sep 21, 2007, 3:23:41 AM9/21/07
to
Ben Finney a écrit :

> "W. Watson" <wolf_...@invalid.com> writes:
>
>> Is vim just an editor or is it capable of running and debugging a
>> program, as well?
>
> (Please don't top-post. Instead, reply below each point to which
> you're responding, removing quoted text irrelevant to your response.)
>
> Both Emacs and Vim are highly customisable text editors. They are
> configurable with complete programming languages specific to the
> program, and both have a huge community of programmers writing useful
> extensions.
>
> So, neither of them is "just an editor"; they are editors at their
> core, that can become complete programming environments by taking
> already-written components for them.

FWIW, emacs has

- a python-mode that let you run either your whole script or parts of it
into a python shell - that of course stays open, so you can examine the
state after execution etc... and it works just fine with pdb.
- ECB (emacs-code-browser), that adds a file explorer and
functions/classes inspector

The combination gives you a full-blown IDE.

Lawrence D'Oliveiro

unread,
Sep 21, 2007, 5:32:46 AM9/21/07
to
In message <87odfxj...@pobox.com>, John J. Lee wrote:

> Seriously for a moment, I read something recently (maybe here?) about
> an Apple study that claimed to show that people who perceived keyboard
> bindings as being much faster than mouseing did not, on average, take
> less time to complete the actions that were studied (they took more
> time, in fact). The plausible explanation for this was that people's
> subjective perception of time is affected by the greater mental work
> involved in typing (as opposed to mousing) for a given action.

<http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html>

Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Matthew Woodcraft

unread,
Sep 21, 2007, 4:03:43 PM9/21/07
to

> <http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html>

An interesting story. They say they picked a test for the express
purpose of proving that in some circumstances cursor keys can be faster
than the mouse, but came up with an exercise in which, unusually, the
keyboard part can be performed with one hand, so eliminating the bit
where the other hand moves from the keyboard to the mouse and back.

-M-

W. Watson

unread,
Sep 21, 2007, 4:44:19 PM9/21/07
to
Well, you may. Unfortunately, there are many NGs that do the opposite.

--

Steven W. Orr

unread,
Sep 21, 2007, 11:07:23 AM9/21/07
to python list
On Thursday, Sep 20th 2007 at 18:14 +0100, quoth Paul Rudin:

=>"W. Watson" <wolf_...@invalid.com> writes:
=>
=>> Thanks, but no thanks. The learning curve is way too steep.
=>
=>Up to you but, these days emacs comes with all sorts of
=>pointing-clicky-menu-y type things - you don't really have to learn
=>anything to get started.
=>
=>(It even gives useful advice on top-posting if you use it as a news
=>client :/)

Vuts det? Iz no longer Editor Mit Aggravating Control Sequencez? ;-)

--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

John J. Lee

unread,
Sep 22, 2007, 3:20:25 AM9/22/07
to
Paul Rubin <http://phr...@NOSPAM.invalid> writes:

> j...@pobox.com (John J. Lee) writes:
>> Seriously for a moment, I read something recently (maybe here?) about
>> an Apple study that claimed to show that people who perceived keyboard
>> bindings as being much faster than mouseing did not, on average, take
>> less time to complete the actions that were studied (they took more
>> time, in fact). The plausible explanation for this was that people's
>> subjective perception of time is affected by the greater mental work
>> involved in typing (as opposed to mousing) for a given action.
>
> I think mousing takes more mental work than typing, and that's why it
> subjectively seems slower even if a stopwatch shows it to be faster.

[...]

I'm not sure this is a matter for debate, as much as physical
measurement.


John

John J. Lee

unread,
Sep 22, 2007, 3:21:31 AM9/22/07
to
Gary Coulbourne <be...@bears.org> writes:

Well yes, obviously (?) I meant Eclipse with pydev installed.


John

Paul Rubin

unread,
Sep 22, 2007, 5:28:54 AM9/22/07
to
j...@pobox.com (John J. Lee) writes:
> > I think mousing takes more mental work than typing,
> I'm not sure this is a matter for debate, as much as physical
> measurement.

I don't know of any way to physically measure mental work.

Stefan Behnel

unread,
Sep 22, 2007, 4:28:07 PM9/22/07
to W. Watson
W. Watson wrote:
> Bruno Desthuilliers wrote:
>> W. Watson a écrit :
>>> How about in the case of MS Win?
>>>
>>> Ben Finney wrote:
>>>>
>>>> (Please don't top-post. Instead, reply below each point to which
>>>> you're responding, removing quoted text irrelevant to your response.)
>>>>
>>
>> Wayne, may I second Ben on his suggestion to stop top-posting ?
>
> Well, you may. Unfortunately, there are many NGs that do the opposite.

Well, not this one.

Stefan

Lawrence D'Oliveiro

unread,
Sep 22, 2007, 5:24:24 PM9/22/07
to
In message <5lhs4pF...@mid.individual.net>, Bjoern Schliessmann wrote:

> Lawrence D'Oliveiro wrote:
>
>> After two decades of putting up with vi just to ensure
>> compatibility with every proprietary *nix system I might come
>> across, let me just say ...
>>
>> USE EMACS!
>
> Nah. Use vim.

Every other text editor I have ever used understands that the current
position in a file is _between_ two characters (or before the first
character, or after the last character), not _on_ a character. But not vi
and its ilk.

Try the following in vi/vim: Move to some point in the middle of a line.
Press "i" to get into insert mode. Press escape to get out again. You'll
end up one position to the left of where you were before. Press "i", and
then escape again--you've moved another position left. Why is it incapable
of keeping track of such a simple thing as your current position in the
file?

Why does it need two different insert commands, "i" versus "a"? Because one
of them can't insert at the end of a line, and the other can't insert at
the beginning.

And why have command-versus-insert mode at all? No other text editor still
surviving uses such an antiquated concept.

TheFlyingDutchman

unread,
Sep 22, 2007, 11:24:48 PM9/22/07
to
On Sep 20, 8:47 pm, "W. Watson" <wolf_tra...@invalid.com> wrote:
> How about in the case of MS Win?
>
Try Wing IDE at http://www.wingware.com. It can run and debug programs
and has a free version.

John J. Lee

unread,
Sep 23, 2007, 8:18:17 AM9/23/07
to
Paul Rubin <http://phr...@NOSPAM.invalid> writes:

fMRI is one. That won't "directly" answer the question of course --
but then physical measurement and scientific progress are never
"direct", theory is always involved.


John

Manuel Graune

unread,
Sep 23, 2007, 12:38:22 PM9/23/07
to
Matthew Woodcraft <matt...@chiark.greenend.org.uk> writes:

It's quite funny, that what the author proposes as "to make it even
harder" actually speeds up the test for the mouse-users quite a bit.
And "cursor keys"? Please, every self respecting editor has ways for
moving around quite a bit more efficiently.

And on top of that a use case, which no one in his right mind would
do this way. Accomplishing this task with search-and-replace would
have taken about 10 seconds. With Mouse or Keyboard.

Regards,

Manuel


--
A hundred men did the rational thing. The sum of those rational choices was
called panic. Neal Stephenson -- System of the world
http://www.graune.org/GnuPG_pubkey.asc
Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A 5828 5476 7E92 2DB4 3C99

Lawrence D'Oliveiro

unread,
Sep 23, 2007, 10:43:56 PM9/23/07
to
In message <m3hcll7...@uriel.graune.org>, Manuel Graune wrote:

> Matthew Woodcraft <matt...@chiark.greenend.org.uk> writes:
>
>> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:>
>>
>>> <http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html>
>>

> And "cursor keys"? Please, every self respecting editor has ways for
> moving around quite a bit more efficiently.
>
> And on top of that a use case, which no one in his right mind would
> do this way. Accomplishing this task with search-and-replace would
> have taken about 10 seconds. With Mouse or Keyboard.

Just to reinforce the point that the above was in no way an artificial or
isolated case:

<http://www.asktog.com/TOI/toi06KeyboardVMouse1.html>
<http://www.asktog.com/TOI/toi22KeyboardVMouse2.html>

Neil Cerutti

unread,
Sep 24, 2007, 8:22:08 AM9/24/07
to
On 2007-09-22, Lawrence D'Oliveiro

<l...@geek-central.gen.new_zealand> wrote:
> In message <5lhs4pF...@mid.individual.net>, Bjoern
> Schliessmann wrote:
>> Nah. Use vim.
>
> Every other text editor I have ever used understands that the
> current position in a file is _between_ two characters (or
> before the first character, or after the last character), not
> _on_ a character. But not vi and its ilk.
>
> Try the following in vi/vim: Move to some point in the middle
> of a line. Press "i" to get into insert mode. Press escape to
> get out again. You'll end up one position to the left of where
> you were before. Press "i", and then escape again--you've moved
> another position left. Why is it incapable of keeping track of
> such a simple thing as your current position in the file?

That's a silly question. Of course it knows your current
position--it just chooses to modify your position when you exit
insert mode.

> Why does it need two different insert commands, "i" versus "a"?
> Because one of them can't insert at the end of a line, and the
> other can't insert at the beginning.

i and a are two of *many* ways to enter insert mode. I'm not sure
all of them are completely justified (I've never uses s or S, for
example). I typically use o, O, i, I and A the most. I don't have
much use for a.

> And why have command-versus-insert mode at all? No other text
> editor still surviving uses such an antiquated concept.

The existence of command mode allows plain old keystrokes to be
commands--it potentially makes commands easier to type. Emacs
users don't find it to be a compelling advantage. ;)

--
Neil Cerutti

Bruno Desthuilliers

unread,
Sep 24, 2007, 8:46:13 AM9/24/07
to
W. Watson a écrit :
(top-post corrected)

> Bruno Desthuilliers wrote:
>> W. Watson a écrit :
>>> How about in the case of MS Win?
>>>
>>> Ben Finney wrote:
>>>>
>>>> (Please don't top-post. Instead, reply below each point to which
>>>> you're responding, removing quoted text irrelevant to your response.)
>>>>
>>
>> Wayne, may I second Ben on his suggestion to stop top-posting ?
>
> Well, you may. Unfortunately, there are many NGs that do the opposite.
>
Unfortunately (for you at least), c.l.p is not one of those.

Manuel Graune

unread,
Sep 24, 2007, 12:55:45 PM9/24/07
to

Without knowing more about the design of those studies, further
discussion is kind of pointless. I would really like to see a comparison
of "mouse-centered IDEs" (e. g. Eclipse) vs. "keyboard-centered IDEs"
(e. g. Emacs). used for some small progamming task (and not isolated
editing problems). For one thing, most programmers more or less
<quote>
are not normal people. We tend to have superior memories, we actually
grasp boolean logic, we have formed priesthoods around the most
egregious interfaces, and we have a firm belief that the average citizen
is in search of an editor for his daily C and Pascal coding tasks.

We are not firmly rooted in the real world.
</quote>

So I'm not really concerned about the first-time user, for which without
a doubt a mouse-based user-interface is easier (and probably faster). I
need an editor/IDE I feel comfortable with after using it for a
month or longer. And for the record: Being subjectively faster is good
enough for me. I don't really care if I could have saved 15 minutes at
the end of the day with the objectively faster interface, if I don't
feel slowed down.

But since this is not a usability-NG and I originally just wanted to
point out that the specific example is far from ideal, I won't
continue this discussion in this NG. If you want to, you can contact me
by mail.

alex

unread,
Sep 24, 2007, 3:30:54 PM9/24/07
to
W. Watson wrote:
> Well, you may. Unfortunately, there are many NGs that do the opposite.
>
> Bruno Desthuilliers wrote:
>> W. Watson a écrit :
>>> How about in the case of MS Win?
>>>
>>> Ben Finney wrote:
>>>>
>>>> (Please don't top-post. Instead, reply below each point to which
>>>> you're responding, removing quoted text irrelevant to your response.)
>>>>
>>
>> Wayne, may I second Ben on his suggestion to stop top-posting ?
>

*plonk*

Lawrence D'Oliveiro

unread,
Sep 24, 2007, 9:13:47 PM9/24/07
to
In message <slrnfff9op....@FIAD06.norwich.edu>, Neil Cerutti wrote:

> On 2007-09-22, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> wrote:
>
>> In message <5lhs4pF...@mid.individual.net>, Bjoern
>> Schliessmann wrote:
>
>>> Nah. Use vim.
>>
>> Every other text editor I have ever used understands that the
>> current position in a file is _between_ two characters (or
>> before the first character, or after the last character), not
>> _on_ a character. But not vi and its ilk.
>>
>> Try the following in vi/vim: Move to some point in the middle
>> of a line. Press "i" to get into insert mode. Press escape to
>> get out again. You'll end up one position to the left of where
>> you were before. Press "i", and then escape again--you've moved
>> another position left. Why is it incapable of keeping track of
>> such a simple thing as your current position in the file?
>
> That's a silly question. Of course it knows your current
> position--it just chooses to modify your position when you exit
> insert mode.

That's like saying, about a program that, when given "2 + 2", outputs "5",
that _of course_ it knows the correct answer is "4", it just chooses
to "modify" the answer before outputting it.

Why does it "choose" to modify your position when you exit insert mode? Does
the phrase "broken as designed" mean anything to you?

>> Why does it need two different insert commands, "i" versus "a"?
>> Because one of them can't insert at the end of a line, and the
>> other can't insert at the beginning.
>
> i and a are two of *many* ways to enter insert mode.

Why do you need so many ways to enter insert mode?

>> And why have command-versus-insert mode at all? No other text
>> editor still surviving uses such an antiquated concept.
>
> The existence of command mode allows plain old keystrokes to be
> commands--it potentially makes commands easier to type.

And the downside is that the largest single proportion of those commands end
up being variations on "enter insert mode". Because most of the keystrokes
you enter during an editing session are in fact text to be input into the
file, not commands to manipulate that text. So in a modal editor, having to
jump in and out of insert mode all the time just adds to the number of
keystrokes you have to type.

A.T.Hofkamp

unread,
Sep 25, 2007, 3:30:56 AM9/25/07
to
On 2007-09-25, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
> In message <slrnfff9op....@FIAD06.norwich.edu>, Neil Cerutti wrote:

> That's like saying, about a program that, when given "2 + 2", outputs "5",
> that _of course_ it knows the correct answer is "4", it just chooses
> to "modify" the answer before outputting it.
>
> Why does it "choose" to modify your position when you exit insert mode? Does
> the phrase "broken as designed" mean anything to you?

Try to insert 1 character in the middle of a line. You'll end up at the same
position. Now press 'j' (one line down), then '.' (do it again).
I believe that's why.

Great when you have nicely formatted columns of code underneath each other.


(try doing that with your GUI editor with 2 strokes per line of code).

Of course, the same works for a find/edit cycle ('n', check whether edit is
appropiate, and if so: '.')
This combining of commands is what makes the editor powerful.

The cost of that power is a command/insert mode and a steep learning curve.


You may not like the keyboard interface, but that doesn't mean the editor is
not well-designed for its task. In the same way, having the ability to use
multiple input devices doesn't automatically make the editor better.

For example, ever wondered why you on earth you need CTL-C and CTL-V to
copy/paste? Why not simply select with the mouse, then right-click to paste?

All editors have their good and their bad sides. Assuming that anything you
don't like is badly designed is a bit too simple in my opinion.

> And the downside is that the largest single proportion of those commands end
> up being variations on "enter insert mode". Because most of the keystrokes
> you enter during an editing session are in fact text to be input into the
> file, not commands to manipulate that text. So in a modal editor, having to

Depends on what you are doing. When entering new code, yes. When maintaining
code, no (lots of small changes).

In one way or another, you'll have to tell the editor what you want. The cost
of that is either a command/insert mode (vi/vim), a CTL/SHIFT/META-key
combination (emacs), or mouse/menu/submenu/subsubmenu (GUI editors).

I don't know what is best. Probably a matter of taste.


Albert

Bjoern Schliessmann

unread,
Sep 25, 2007, 5:34:26 AM9/25/07
to
Lawrence D'Oliveiro wrote:
> That's like saying, about a program that, when given "2 + 2",
> outputs "5", that _of course_ it knows the correct answer is "4",
> it just chooses to "modify" the answer before outputting it.

No. Which laws say how transitions between modes have to be? Thus, I
know laws saying 2 and 2 is 4.



> Why does it "choose" to modify your position when you exit insert
> mode? Does the phrase "broken as designed" mean anything to you?

Does the phrase "everything I don't like is stupid" mean anything to
you? Honestly, if you don't like it, either propose improvement or
stop using it (and complaining about it). Your preference with user
interfaces is obviously different. (Personally, I prefer single
strokes to breaking my fingers with Esc-Meta-Alt-Control-Shift.
:) )



> Why do you need so many ways to enter insert mode?

It can be convenient. For you apprently not, though.



> And the downside is that the largest single proportion of those
> commands end up being variations on "enter insert mode". Because
> most of the keystrokes you enter during an editing session are in
> fact text to be input into the file, not commands to manipulate
> that text.

Strange -- mostly, this is not the case for me. When refactoring
code for example, I jump around, copy, paste and modify many times.

> So in a modal editor, having to jump in and out of insert mode all
> the time just adds to the number of keystrokes you have to type.

Much better than accessing special functions with finger breaking
key combinations. IMHO.

Regards,


Björn

--
BOFH excuse #226:

A star wars satellite accidently blew up the WAN.

Steve Holden

unread,
Sep 25, 2007, 8:17:01 AM9/25/07
to pytho...@python.org
Bjoern Schliessmann wrote:
> Lawrence D'Oliveiro wrote:
>> That's like saying, about a program that, when given "2 + 2",
>> outputs "5", that _of course_ it knows the correct answer is "4",
>> it just chooses to "modify" the answer before outputting it.
>
> No. Which laws say how transitions between modes have to be? Thus, I
> know laws saying 2 and 2 is 4.
>
>> Why does it "choose" to modify your position when you exit insert
>> mode? Does the phrase "broken as designed" mean anything to you?
>
> Does the phrase "everything I don't like is stupid" mean anything to
> you? Honestly, if you don't like it, either propose improvement or
> stop using it (and complaining about it). Your preference with user
> interfaces is obviously different. (Personally, I prefer single
> strokes to breaking my fingers with Esc-Meta-Alt-Control-Shift.
> :) )
>
Does "this non-Python related twaddle is boring the shit out of me" mean
anything to you both?

[...]

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

Peter Decker

unread,
Sep 25, 2007, 12:19:11 PM9/25/07
to pytho...@python.org
On 9/25/07, Steve Holden <st...@holdenweb.com> wrote:

> >> Why does it "choose" to modify your position when you exit insert
> >> mode? Does the phrase "broken as designed" mean anything to you?
> >
> > Does the phrase "everything I don't like is stupid" mean anything to
> > you? Honestly, if you don't like it, either propose improvement or
> > stop using it (and complaining about it). Your preference with user
> > interfaces is obviously different. (Personally, I prefer single
> > strokes to breaking my fingers with Esc-Meta-Alt-Control-Shift.
> > :) )
> >

> Does "this non-Python related twaddle is boring the shit out of me" mean
> anything to you both?

+1 QOTW!!

--

# p.d.

Lawrence D'Oliveiro

unread,
Sep 25, 2007, 10:15:46 PM9/25/07
to
In message <slrnffhe9...@se-162.se.wtb.tue.nl>, A.T.Hofkamp wrote:

> On 2007-09-25, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> Why does it "choose" to modify your position when you exit insert mode?
>

> Try to insert 1 character in the middle of a line. You'll end up at the
> same position. Now press 'j' (one line down), then '.' (do it again).
> I believe that's why.
>
> Great when you have nicely formatted columns of code underneath each
> other.

It's strange, but in nearly 30 years of writing code in dozens of different
languages, I've never felt the urge to line up my code in columns. Never.
(Apart from assembly language, which I suspect you don't want to hear
about.)

> The cost of that power is a command/insert mode and a steep learning
> curve.

That's another issue, that of ROI. Having learnt the vi/vim keystrokes, what
does that enable you to do? Use vi/vim, and that's it. Whereas I've found
other situations where subsets of Emacs keystrokes are recognized, such as
anything that uses GNU readline (including the Python console--see, this IS
relevant to Python after all), and pico/nano. These are all extra goodies
that are to be found on the way up the Emacs learning curve.

> For example, ever wondered why you on earth you need CTL-C and CTL-V to
> copy/paste? Why not simply select with the mouse, then right-click to
> paste?

Or better still, why not allow both?

>> And the downside is that the largest single proportion of those commands
>> end up being variations on "enter insert mode". Because most of the
>> keystrokes you enter during an editing session are in fact text to be
>> input into the file, not commands to manipulate that text. So in a modal
>> editor, having to
>
> Depends on what you are doing. When entering new code, yes. When
> maintaining code, no (lots of small changes).

Making lots of small changes is even worse--it means you're jumping into
insert mode for shorter times, more frequently.

And that's when you discover something else: that how you delete text in
vi/vim differs, depending on whether it's something you just inserted while
currently in insert mode, or whether it was there from before you last
entered insert mode: in the former case, you use backspace to delete, in
the latter case, you can't use backspace, you have to use "X". What does
backspace do when not in insert mode? It just moves you through the text.
What does the forward-delete key do? In both modes, it actually deletes
text!

At least with Emacs, text is text--it doesn't matter when it was inserted,
it still behaves the same way.

Ben Finney

unread,
Sep 25, 2007, 11:12:47 PM9/25/07
to
Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> writes:

> That's another issue, that of ROI. Having learnt the vi/vim
> keystrokes, what does that enable you to do? Use vi/vim, and that's
> it.

There are a great many programs whose interactive keybindings come
from vi. Perhaps you've heard of 'less', 'screen', 'mutt', or dozens
of other frequently-used programs, all of which use 'vi key bindings
by default.

> Whereas I've found other situations where subsets of Emacs
> keystrokes are recognized, such as anything that uses GNU readline

Which can also be configured one-time by the user to use 'vi'
keybindings everywhere, so the 'vi' fanatic is able to keep using the
key bindings they know.

I think this argument is silly — both Emacs and vi(m) have enormous
following, are both extremely capable editors, and both are clearly
the inspiration for many other programs' key bindings. It's ludicrous
to say of either program that "once you learn its key bindings you
only know how to use that program".

--
\ "Welchen Teil von 'Gestalt' verstehen Sie nicht? [What part of |
`\ 'gestalt' don't you understand?]" -- Karsten M. Self |
_o__) |
Ben Finney

Jason M Barnes

unread,
Sep 25, 2007, 11:25:46 PM9/25/07
to Lawrence D'Oliveiro, pytho...@python.org
Warning: Religion follows:

On 9/25/07, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
> In message <slrnffhe9...@se-162.se.wtb.tue.nl>, A.T.Hofkamp wrote:
>
> > On 2007-09-25, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> > wrote:
> >
> >> Why does it "choose" to modify your position when you exit insert mode?
> >
> > Try to insert 1 character in the middle of a line. You'll end up at the
> > same position. Now press 'j' (one line down), then '.' (do it again).
> > I believe that's why.
> >
> > Great when you have nicely formatted columns of code underneath each
> > other.
>
> It's strange, but in nearly 30 years of writing code in dozens of different
> languages, I've never felt the urge to line up my code in columns. Never.
> (Apart from assembly language, which I suspect you don't want to hear
> about.)
>
> > The cost of that power is a command/insert mode and a steep learning
> > curve.
>
> That's another issue, that of ROI. Having learnt the vi/vim keystrokes, what
> does that enable you to do? Use vi/vim, and that's it. Whereas I've found
> other situations where subsets of Emacs keystrokes are recognized, such as
> anything that uses GNU readline (including the Python console--see, this IS
> relevant to Python after all), and pico/nano. These are all extra goodies
> that are to be found on the way up the Emacs learning curve.

Off the top of my head, I can think of a few vim commands that have
come in handy. I can search through a webpage in Firefox by using the
same '/' search command that vim has. The movement keys (h,j,k,l) are
the same as in any paging program I've ever used. Not to mention that
I learned regexes by learning 's/regex/replacement' first :-)


>
> > For example, ever wondered why you on earth you need CTL-C and CTL-V to
> > copy/paste? Why not simply select with the mouse, then right-click to
> > paste?
>
> Or better still, why not allow both?
>
> >> And the downside is that the largest single proportion of those commands
> >> end up being variations on "enter insert mode". Because most of the
> >> keystrokes you enter during an editing session are in fact text to be
> >> input into the file, not commands to manipulate that text. So in a modal
> >> editor, having to
> >
> > Depends on what you are doing. When entering new code, yes. When
> > maintaining code, no (lots of small changes).
>
> Making lots of small changes is even worse--it means you're jumping into
> insert mode for shorter times, more frequently.

If you're making lots of small changes, then you shouldn't be jumping
into insert mode at all, IMO.


>
> And that's when you discover something else: that how you delete text in
> vi/vim differs, depending on whether it's something you just inserted while
> currently in insert mode, or whether it was there from before you last
> entered insert mode: in the former case, you use backspace to delete, in
> the latter case, you can't use backspace, you have to use "X". What does
> backspace do when not in insert mode? It just moves you through the text.
> What does the forward-delete key do? In both modes, it actually deletes
> text!

Actually, vim always deletes the same way regardless of when it was
inserted -- one of the many *improvements* over vi.

That's my religion anyway ;-), but I thought this was a python mailing list ;-)

Jason


>
> At least with Emacs, text is text--it doesn't matter when it was inserted,
> it still behaves the same way.

> --
> http://mail.python.org/mailman/listinfo/python-list
>

Bjoern Schliessmann

unread,
Sep 26, 2007, 9:04:54 AM9/26/07
to
Lawrence D'Oliveiro wrote:

> It's strange, but in nearly 30 years of writing code in dozens of
> different languages, I've never felt the urge to line up my code
> in columns. Never.

You definitely used the wrong languages :)

http://worsethanfailure.com/Articles/The-Other-Kind-of-RPG.aspx

| Well into the .COM-boom, RPG [Report Program Generator] coders
| were still stuck coding in ?fixed format? style. Prior to that,
| RPG programmers had no choice but to use standard 80-character
| punch-card-length columns with fixed fields. In this format, the
| operator (?opcode? in RPG-speak) goes in columns 26-35, the first
| operand (?Factor 1?) goes in columns 12-25, the second operand
| (?Factor 2?) goes in columns 36-49, and the ?result field? goes in
| columns 50-63. If you do the math, that means that the fields
| (?variables? in modern-speak) were restricted to six characters.
| And of course, all had to be uppercase.
|
| RPG IV, the latest incarnation, introduced the concept
| of ?extended? columns with a more relaxed format. Instead of
| having one operation (ADD, SUB, DIV, etc) per line, programmers
| could use the EVAL opcode to do all sorts of crazy things like ?A
| = (B+C) * D?, all with a single line of code. It even afforded
| programmers the luxury of using lowercase letters in variables.

I demand a Python module implementing this, because I don't like
this bad, liberal Python code today. 8)



> That's another issue, that of ROI. Having learnt the vi/vim
> keystrokes, what does that enable you to do? Use vi/vim, and
> that's it. Whereas I've found other situations where subsets of
> Emacs keystrokes are recognized, such as anything that uses GNU
> readline (including the Python console--see, this IS relevant to
> Python after all)

readline's editing-mode can be emacs or vi (see "man readline").



> Making lots of small changes is even worse--it means you're
> jumping into insert mode for shorter times, more frequently.

That's convenient, IMHO. For example, for changing an identifier you
can delete it, activate editing mode and place the cursor where the
name was using just two keystrokes (cw<theword><ESC>). Almost the
same with multiple words, lines, or the line until EOL. For special
needs there is visual mode (like "mouse selection").

This flexibility is admittedly in most cases not suited for
occasional users because it needs much practice. Also, for prompts
a separate insert mode can be strange.



> And that's when you discover something else: that how you delete
> text in vi/vim differs, depending on whether it's something you
> just inserted while currently in insert mode, or whether it was

> there from before you last entered insert mode [...]


>
> At least with Emacs, text is text--it doesn't matter when it was
> inserted, it still behaves the same way.

Would you accept that the style of editing is a matter of taste?

Regards,


Björn

--
BOFH excuse #185:

system consumed all the paper for paging

Neil Cerutti

unread,
Sep 26, 2007, 11:28:53 AM9/26/07
to
On 2007-09-26, Jason M Barnes <json....@gmail.com> wrote:
> Off the top of my head, I can think of a few vim commands that
> have come in handy. I can search through a webpage in Firefox
> by using the same '/' search command that vim has. The
> movement keys (h,j,k,l) are the same as in any paging program
> I've ever used. Not to mention that I learned regexes by
> learning 's/regex/replacement' first :-)

Yup. A huge advantge of learning vi is how much it helps improve
your nethack experience. ;) Ignorance was Emacs was an obstacle I
had to overcome in order to get into the Lisp world, though.

> That's my religion anyway ;-), but I thought this was a python
> mailing list ;-)

Vim has Python integration if you want to control it with Python
scripts. Cool! Of course, Vim needs such a capability more than
Emacs, which has the very cool elisp scripting language. I'm not
so keen on Vim's built-in scripting language.

--
Neil Cerutti

Jason M Barnes

unread,
Sep 26, 2007, 12:38:35 PM9/26/07
to Neil Cerutti, pytho...@python.org
On 9/26/07, Neil Cerutti <hor...@yahoo.com> wrote:
> On 2007-09-26, Jason M Barnes <json....@gmail.com> wrote:
> > Off the top of my head, I can think of a few vim commands that
> > have come in handy. I can search through a webpage in Firefox
> > by using the same '/' search command that vim has. The
> > movement keys (h,j,k,l) are the same as in any paging program
> > I've ever used. Not to mention that I learned regexes by
> > learning 's/regex/replacement' first :-)
>
> Yup. A huge advantge of learning vi is how much it helps improve
> your nethack experience. ;) Ignorance was Emacs was an obstacle I
> had to overcome in order to get into the Lisp world, though.

Ha! I'm trying to learn Lisp now, too, and I'm having to learn Emacs
to be more efficient. I feel like I'm taking my first CS class again.
(Now was that C-x C-c or M-c M-x?... Nope, that didn't work... ;-)


>
> > That's my religion anyway ;-), but I thought this was a python
> > mailing list ;-)
>
> Vim has Python integration if you want to control it with Python
> scripts. Cool! Of course, Vim needs such a capability more than
> Emacs, which has the very cool elisp scripting language. I'm not
> so keen on Vim's built-in scripting language.
>
> --
> Neil Cerutti

> --
> http://mail.python.org/mailman/listinfo/python-list
>

Simon Brunning

unread,
Sep 26, 2007, 3:40:40 PM9/26/07
to pytho...@python.org
On 9/26/07, Bjoern Schliessmann <usenet-mail-03...@spamgourmet.com>

> You definitely used the wrong languages :)
>
> http://worsethanfailure.com/Articles/The-Other-Kind-of-RPG.aspx

Ah, but one edits RPG with SEU[1], Undo - who needs it?

--
Cheers,
Simon B.
si...@brunningonline.net
[1] http://tinyurl.com/yvra7l

Bruno Desthuilliers

unread,
Sep 27, 2007, 2:49:40 PM9/27/07
to
Neil Cerutti a écrit :
(snip)

>
> Vim has Python integration if you want to control it with Python
> scripts. Cool! Of course, Vim needs such a capability more than
> Emacs, which has the very cool elisp scripting language.

FWIW, emacs is programmable in Python too IIRC.

Ben Finney

unread,
Oct 1, 2007, 12:06:12 AM10/1/07
to
Bruno Desthuilliers <bruno.42.de...@wtf.websiteburo.oops.com> writes:

> Ben Finney a écrit :
> > Both Emacs and Vim are highly customisable text editors. They are
> > configurable with complete programming languages specific to the
> > program, and both have a huge community of programmers writing
> > useful extensions.
>
> FWIW, emacs has
> [...]
> - ECB (emacs-code-browser), that adds a file explorer and
> functions/classes inspector

Thank you very much for making me aware of this amazing tool. I've now
been using it for a couple of weeks, and not only does it work
smoothly with Python, it works smoothly with loads of other source
file formats, such as targets in a Makefile or changelog entries.

This is really important, because developing programs is much more
than just editing files in one language. A "python IDE" is all well
and good, but it's much better to have a solid generic text editor
that can be extended by the community.

When the editor supports hundreds of common (and less-common) file
syntaxes that are associated with programming, the job becomes that
much more streamlined. I had become accustomed to this with syntax
highlighting, but I'm very pleased to see that ECB has a similarly
broad support for organising and browsing the variety of file syntaxes
I'm likely to be editing when developing with Python.

It also goes without saying that it's great to have all this with
*optional* GUI support; it all works just the same when I'm connecting
to a text terminal remotely over a slow link.

Talk about "huge community of programmers writing useful
extensions". Wow.

What's the equivalent in the Vim world?

--
\ "He who laughs last, thinks slowest." -- Anonymous |
`\ |
_o__) |
Ben Finney

Reply all
Reply to author
Forward