An Editor that Skips to the End of a Def

[Stefan Behnel]

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:

Stefan

 

[Stefan Behnel]

Nah. Use vim.


Esc-Meta-Alt-Ctrl-Shift?

Yep, that's five of them.

Stefan

 

[Stefan Behnel]

(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

 

[Steven W. Orr]

On Thursday, Sep 20th 2007 at 18:14 +0100, quoth Paul Rudin:

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

 

[Bjoern Schliessmann]

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,


Björn

 

[Dennis Lee Bieber]

Esc-Meta-Alt-Ctrl-Shift?

One of the old Amiga A-1000 easter eggs required holding down, as I
recall, Esc, left-Shift, left-Amiga, right-Shift, right-Amiga WHILE
ejecting and reinserting a floppy.

Memory fails -- it was F1, not Esc...

http://www.amigahistory.co.uk/messages.html

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Matthew Woodcraft]

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

Well, you may. Unfortunately, there are many NGs that do the opposite.

 

[John J. Lee]

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]

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

 

[Paul Rubin]

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]

Well, you may. Unfortunately, there are many NGs that do the opposite.

Well, not this one.

Stefan

 

[Lawrence D'Oliveiro]

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]

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]

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

 

[Manuel Graune]

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-

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

 

[Lawrence D'Oliveiro]

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]

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.

 

[Bruno Desthuilliers]

W. Watson a écrit :
(top-post corrected)

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

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