471,321 Members | 1,810 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,321 software developers and data experts.

An Editor that Skips to the End of a Def

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>
Sep 20 '07 #1
49 1444
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 !-)
Sep 20 '07 #2
"W. Watson" <wo*********@invalid.comwrites:
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.
Sep 20 '07 #3
Thanks, but no thanks. The learning curve is way too steep.

Paul Rudin wrote:
"W. Watson" <wo*********@invalid.comwrites:
>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.
--
Wayne Watson (Nevada City, CA)

Web Page: <speckledwithStars.net>
Sep 20 '07 #4
"W. Watson" <wo*********@invalid.comwrites:
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 :/)
Sep 20 '07 #5
Paul Rudin wrote:
>"W. Watson" <wo*********@invalid.comwrites:
>>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
Sep 20 '07 #6
"W. Watson" <wo*********@invalid.comwrites:
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
Sep 20 '07 #7
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 -
Sep 20 '07 #8
jj*@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.
Sep 20 '07 #9
Maybe I'll take a look. When I left the world of Unix/Linux 10 years ago,
emacs went with it, as did vi.

Paul Rudin wrote:
"W. Watson" <wo*********@invalid.comwrites:
>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 :/)
--
Wayne Watson (Nevada City, CA)

Web Page: <speckledwithStars.net>
Sep 20 '07 #10
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
Sep 20 '07 #11
Is vim just an editor or is it capable of running and debugging a program,
as well?

W. Watson wrote:
Maybe I'll take a look. When I left the world of Unix/Linux 10 years
ago, emacs went with it, as did vi.

Paul Rudin wrote:
>"W. Watson" <wo*********@invalid.comwrites:
>>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 :/)
--
Wayne Watson (Nevada City, CA)

Web Page: <speckledwithStars.net>
Sep 21 '07 #12
"W. Watson" <wo*********@invalid.comwrites:
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
Sep 21 '07 #13
How about in the case of MS Win?

Ben Finney wrote:
"W. Watson" <wo*********@invalid.comwrites:
>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.
--
Wayne Watson (Nevada City, CA)

Web Page: <speckledwithStars.net>
Sep 21 '07 #14
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 ?
Sep 21 '07 #15
Ben Finney a écrit :
"W. Watson" <wo*********@invalid.comwrites:
>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.
Sep 21 '07 #16
In message <87************@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>
Sep 21 '07 #17
In message <87************@rudin.co.uk>, Paul Rudin wrote:
... 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.
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!

Oh, and <http://ars.userfriendly.org/cartoons/?id=20070910&mode=classic>.
Sep 21 '07 #18
Ant
On Sep 21, 4:47 am, "W. Watson" <wolf_tra...@invalid.comwrote:
How about in the case of MS Win?
Both emacs and vim have GUI versions that run on Windows.

--
Ant...

Sep 21 '07 #19
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.
Oh, and
<http://ars.userfriendly.org/cartoons/?id=20070910&mode=classic>.
Esc-Meta-Alt-Ctrl-Shift? :)

Regards,
Bjrn

--
BOFH excuse #418:

Sysadmins busy fighting SPAM.

Sep 21 '07 #20
W. Watson wrote:
Is vim just an editor or is it capable of running and debugging a
program, as well?
Depends on how you define an editor. If you take Emacs as example for an
editor, then, no, it's not an editor.

BTW:
>>(It even gives useful advice on top-posting if you use it as a news
client :/)
Stefan
Sep 21 '07 #21
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.
>Oh, and
<http://ars.userfriendly.org/cartoons/?id=20070910&mode=classic>.

Esc-Meta-Alt-Ctrl-Shift? :)
Yep, that's five of them.

Stefan
Sep 21 '07 #22
Michael v. Fondern wrote:
(Ctrl-Shift-Down)
Is this the opposite of thumbs up, or is it just to suggest that Eclipse can
come close to Emacs's usability if you try hard?

Stefan
Sep 21 '07 #23
Stefan Behnel wrote:
Bjoern Schliessmann wrote:
>Lawrence D'Oliveiro wrote:
>><http://ars.userfriendly.org/cartoons/
?id=20070910&mode=classic>.

Esc-Meta-Alt-Ctrl-Shift? :)

Yep, that's five of them.
I'd also have mentioned Caps Lock, Alt Gr, Compose and Sysrq if
there was no deeper meaning in what I wrote.

Regards,
Bjrn

--
BOFH excuse #25:

Decreasing electron flux

Sep 21 '07 #24
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 ?
--
Wayne Watson (Nevada City, CA)

Web Page: <speckledwithStars.net>
Sep 21 '07 #25
On Thursday, Sep 20th 2007 at 18:14 +0100, quoth Paul Rudin:

=>"W. Watson" <wo*********@invalid.comwrites:
=>
=>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
Sep 21 '07 #26
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
jj*@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
Sep 22 '07 #27
Gary Coulbourne <be**@bears.orgwrites:
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)
Well yes, obviously (?) I meant Eclipse with pydev installed.
John
Sep 22 '07 #28
jj*@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.
Sep 22 '07 #29
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
Sep 22 '07 #30
In message <5l************@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.
Sep 22 '07 #31
On Sep 20, 8:47 pm, "W. Watson" <wolf_tra...@invalid.comwrote:
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.

Sep 23 '07 #32
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
jj*@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.
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
Sep 23 '07 #33
In message <m3************@uriel.graune.org>, Manuel Graune wrote:
Matthew Woodcraft <ma******@chiark.greenend.org.ukwrites:
>Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrote:>
>><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>
Sep 24 '07 #34
On 2007-09-22, Lawrence D'Oliveiro
<ld*@geek-central.gen.new_zealandwrote:
In message <5l************@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
Sep 24 '07 #35
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.
Sep 24 '07 #36
Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrites:
In message <m3************@uriel.graune.org>, Manuel Graune wrote:
>Matthew Woodcraft <ma******@chiark.greenend.org.ukwrites:
>>Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrote:>

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

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
Sep 24 '07 #37
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*
Sep 24 '07 #38
In message <sl********************@FIAD06.norwich.edu>, Neil Cerutti wrote:
On 2007-09-22, Lawrence D'Oliveiro
<ld*@geek-central.gen.new_zealandwrote:
>In message <5l************@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.

Sep 25 '07 #39
On 2007-09-25, Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrote:
In message <sl********************@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

Sep 25 '07 #40
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,
Bjrn

--
BOFH excuse #226:

A star wars satellite accidently blew up the WAN.

Sep 25 '07 #41
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

Sep 25 '07 #42
On 9/25/07, Steve Holden <st***@holdenweb.comwrote:
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.
Sep 25 '07 #43
In message <sl****************@se-162.se.wtb.tue.nl>, A.T.Hofkamp wrote:
On 2007-09-25, Lawrence D'Oliveiro <ld*@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.
Sep 26 '07 #44
Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrites:
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
Sep 26 '07 #45
Warning: Religion follows:

On 9/25/07, Lawrence D'Oliveiro <ld*@geek-central.gen.new_zealandwrote:
In message <sl****************@se-162.se.wtb.tue.nl>, A.T.Hofkamp wrote:
On 2007-09-25, Lawrence D'Oliveiro <ld*@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
Sep 26 '07 #46
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...nd-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,
Bjrn

--
BOFH excuse #185:

system consumed all the paper for paging

Sep 26 '07 #47
On 9/26/07, Bjoern Schliessmann <us**************************@spamgourmet.com>
You definitely used the wrong languages :)

http://worsethanfailure.com/Articles...nd-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
Sep 26 '07 #48
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.
Sep 27 '07 #49
Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ites:
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
Oct 1 '07 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by pwinward | last post: by
reply views Thread by Johan | last post: by
reply views Thread by EC | last post: by
3 posts views Thread by David Garamond | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.