An Editor that Skips to the End of a Def

[alex]

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

*plonk*

 

[Lawrence D'Oliveiro]

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?

i and a are two of *many* ways to enter insert mode.

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

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]

In message <[email protected]>, 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]

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

 

[Steve Holden]

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


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]

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

+1 QOTW!!

 

[Lawrence D'Oliveiro]

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?

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]

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

 

[Jason M Barnes]

Warning: Religion follows:

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


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

Or better still, why not allow both?


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

 

[Bjoern Schliessmann]

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

 

[Neil Cerutti]

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.

 

[Jason M Barnes]

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

 

[Simon Brunning]

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?

 

[Bruno Desthuilliers]

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]

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?