An Editor that Skips to the End of a Def

[Lawrence D'Oliveiro]

In message <slrnfff9op.1is.horpner@...>, Neil Cerutti wrote:

> On 2007-09-22, Lawrence D'Oliveiro
> <ldo@...> wrote:
>
>> In message <5lhs4pF8bkunU1@...>, 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.

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

[A.T.Hofkamp-3]

On 2007-09-25, Lawrence D'Oliveiro <ldo@...> wrote:
> In message <slrnfff9op.1is.horpner@...>, 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

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

[Bjoern Schliessmann]

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.

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

[Steve Holden-5]

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        [phone]   [phone]
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

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

[Peter Decker]

On 9/25/07, Steve Holden <steve@...> 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.
--
http://mail.python.org/mailman/listinfo/python-list

[Lawrence D'Oliveiro]

In message <slrnffhe9g.2db.hat@...>, A.T.Hofkamp wrote:

> On 2007-09-25, Lawrence D'Oliveiro <ldo@...>
> 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.
--
http://mail.python.org/mailman/listinfo/python-list

[Ben Finney-2]

Lawrence D'Oliveiro <ldo@...> 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
--
http://mail.python.org/mailman/listinfo/python-list

[Jason M Barnes]

Warning: Religion follows:

On 9/25/07, Lawrence D'Oliveiro <ldo@...> wrote:

> In message <slrnffhe9g.2db.hat@...>, A.T.Hofkamp wrote:
>
> > On 2007-09-25, Lawrence D'Oliveiro <ldo@...>
> > 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
>
--
http://mail.python.org/mailman/listinfo/python-list

[Bjoern Schliessmann]

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

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

[Neil Cerutti-2]

On 2007-09-26, Jason M Barnes <json.barnes@...> 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
--
http://mail.python.org/mailman/listinfo/python-list

[Jason M Barnes]

On 9/26/07, Neil Cerutti <horpner@...> wrote:

> On 2007-09-26, Jason M Barnes <json.barnes@...> 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
>

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

[Simon Brunning-2]

On 9/26/07, Bjoern Schliessmann <usenet-mail-0306.20.chr0n0ss@...>
> 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.
simon@...
[1] http://tinyurl.com/yvra7l
--
http://mail.python.org/mailman/listinfo/python-list

[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.
--
http://mail.python.org/mailman/listinfo/python-list

[Ben Finney-2]

Bruno Desthuilliers <bruno.42.desthuilliers@...> 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
--
http://mail.python.org/mailman/listinfo/python-list