An Editor that Skips to the End of a Def
W. Watson
pushing some button goes to the end of the def?
--
Wayne Watson (Nevada City, CA)
Web Page: <speckledwithStars.net>
Bruno Desthuilliers
> Is there an editor that allows one to position to put the cursor and
> then by pushing some button goes to the end of the def?
Emacs. And you don't even have to "push some button" (just remember the
correct key sequence !-)
Paul Rudin
> 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
--
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 :/)
alex
>> "W. Watson" <wolf_...@invalid.com> writes:
>>
>>> Is there an editor that allows one to position to put the cursor and
>>> then by pushing some button goes to the end of the def?
>>
>> C-M-e in emacs/python-mode.
>
> Thanks, but no thanks. The learning curve is way too steep.
There are two good editors for writing code -- vim and emacs.
If you write more than a few lines of code a year you should learn
one of them. Time spent doing it will pay for itself *very* quickly.
--
Alex
John J. Lee
> Thanks, but no thanks. The learning curve is way too steep.
[...]
Eclipse must be able to do this.
Eclipse is emacs for stupid people ;-)
Seriously for a moment, I read something recently (maybe here?) about
an Apple study that claimed to show that people who perceived keyboard
bindings as being much faster than mouseing did not, on average, take
less time to complete the actions that were studied (they took more
time, in fact). The plausible explanation for this was that people's
subjective perception of time is affected by the greater mental work
involved in typing (as opposed to mousing) for a given action.
I suspect the reality is at neither extreme (nor "somewhere in the
middle").
John
Michael v. Fondern
> Is there an editor that allows one to position to put the cursor and
> then by pushing some button goes to the end of the def?
Eclipse, together with the pydev plugin.
(Ctrl-Shift-Down)
Greetings
- Michael -
Paul Rubin
> Seriously for a moment, I read something recently (maybe here?) about
> an Apple study that claimed to show that people who perceived keyboard
> bindings as being much faster than mouseing did not, on average, take
> less time to complete the actions that were studied (they took more
> time, in fact). The plausible explanation for this was that people's
> subjective perception of time is affected by the greater mental work
> involved in typing (as opposed to mousing) for a given action.
I think mousing takes more mental work than typing, and that's why it
subjectively seems slower even if a stopwatch shows it to be faster.
I have IM text chats with my officemate all the time even though he's
sitting about 4 feet away from me and I could easily talk to him and
that would probably be faster. But text chat needs less mental effort
since it doesn't take my attention away from symbols on the screen,
i.e. when the chat topic is something simple, I don't lose mental
context of the program I'm working on and then have to spend time
getting the context back. In that sense, text chats save time
compared with regular conversations even though they're slower.
Of course if the chat subject gets complicated and starts needing
careful thought, then it's better to switch to conversation, and
sometimes we both simultaneously realize that and start talking to
each other or using the whiteboard.
W. Watson
emacs went with it, as did vi.
--
Gary Coulbourne
> Eclipse must be able to do this.
Not by default... but I am certain there are plugins that provide python
integration. (And jython integration)
Peace,
Gary
W. Watson
as well?
Ben Finney
> Is vim just an editor or is it capable of running and debugging a
> program, as well?
(Please don't top-post. Instead, reply below each point to which
you're responding, removing quoted text irrelevant to your response.)
Both Emacs and Vim are highly customisable text editors. They are
configurable with complete programming languages specific to the
program, and both have a huge community of programmers writing useful
extensions.
So, neither of them is "just an editor"; they are editors at their
core, that can become complete programming environments by taking
already-written components for them. Your operating system
distribution of either Vim or Emacs will already include many of these
components when you install the package, and many more are available.
--
\ "The restriction of knowledge to an elite group destroys the |
`\ spirit of society and leads to its intellectual |
_o__) impoverishment." —Albert Einstein |
Ben Finney
W. Watson
Ben Finney wrote:
> "W. Watson" <wolf_...@invalid.com> writes:
>
>> Is vim just an editor or is it capable of running and debugging a
>> program, as well?
>
> (Please don't top-post. Instead, reply below each point to which
> you're responding, removing quoted text irrelevant to your response.)
>
> Both Emacs and Vim are highly customisable text editors. They are
> configurable with complete programming languages specific to the
> program, and both have a huge community of programmers writing useful
> extensions.
>
> So, neither of them is "just an editor"; they are editors at their
> core, that can become complete programming environments by taking
> already-written components for them. Your operating system
> distribution of either Vim or Emacs will already include many of these
> components when you install the package, and many more are available.
>
--
Bruno Desthuilliers
> How about in the case of MS Win?
>
> Ben Finney wrote:
>>
>> (Please don't top-post. Instead, reply below each point to which
>> you're responding, removing quoted text irrelevant to your response.)
>>
Wayne, may I second Ben on his suggestion to stop top-posting ?
Bruno Desthuilliers
> "W. Watson" <wolf_...@invalid.com> writes:
>
>> Is vim just an editor or is it capable of running and debugging a
>> program, as well?
>
> (Please don't top-post. Instead, reply below each point to which
> you're responding, removing quoted text irrelevant to your response.)
>
> Both Emacs and Vim are highly customisable text editors. They are
> configurable with complete programming languages specific to the
> program, and both have a huge community of programmers writing useful
> extensions.
>
> So, neither of them is "just an editor"; they are editors at their
> core, that can become complete programming environments by taking
> already-written components for them.
FWIW, emacs has
- a python-mode that let you run either your whole script or parts of it
into a python shell - that of course stays open, so you can examine the
state after execution etc... and it works just fine with pdb.
- ECB (emacs-code-browser), that adds a file explorer and
functions/classes inspector
The combination gives you a full-blown IDE.
Lawrence D'Oliveiro
> 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>
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
--
Steven W. Orr
=>"W. Watson" <wolf_...@invalid.com> writes:
=>
=>> Thanks, but no thanks. The learning curve is way too steep.
=>
=>Up to you but, these days emacs comes with all sorts of
=>pointing-clicky-menu-y type things - you don't really have to learn
=>anything to get started.
=>
=>(It even gives useful advice on top-posting if you use it as a news
=>client :/)
Vuts det? Iz no longer Editor Mit Aggravating Control Sequencez? ;-)
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
John J. Lee
> j...@pobox.com (John J. Lee) writes:
>> Seriously for a moment, I read something recently (maybe here?) about
>> an Apple study that claimed to show that people who perceived keyboard
>> bindings as being much faster than mouseing did not, on average, take
>> less time to complete the actions that were studied (they took more
>> time, in fact). The plausible explanation for this was that people's
>> subjective perception of time is affected by the greater mental work
>> involved in typing (as opposed to mousing) for a given action.
>
> I think mousing takes more mental work than typing, and that's why it
> subjectively seems slower even if a stopwatch shows it to be faster.
[...]
I'm not sure this is a matter for debate, as much as physical
measurement.
John
John J. Lee
Well yes, obviously (?) I meant Eclipse with pydev installed.
John
Paul Rubin
> measurement.
I don't know of any way to physically measure mental work.
Stefan Behnel
> Bruno Desthuilliers wrote:
>> W. Watson a écrit :
>>> How about in the case of MS Win?
>>>
>>> Ben Finney wrote:
>>>>
>>>> (Please don't top-post. Instead, reply below each point to which
>>>> you're responding, removing quoted text irrelevant to your response.)
>>>>
>>
>> Wayne, may I second Ben on his suggestion to stop top-posting ?
>
> Well, you may. Unfortunately, there are many NGs that do the opposite.
Well, not this one.
Stefan
Lawrence D'Oliveiro
> Lawrence D'Oliveiro wrote:
>
>> After two decades of putting up with vi just to ensure
>> compatibility with every proprietary *nix system I might come
>> across, let me just say ...
>>
>> USE EMACS!
>
> Nah. Use vim.
Every other text editor I have ever used understands that the current
position in a file is _between_ two characters (or before the first
character, or after the last character), not _on_ a character. But not vi
and its ilk.
Try the following in vi/vim: Move to some point in the middle of a line.
Press "i" to get into insert mode. Press escape to get out again. You'll
end up one position to the left of where you were before. Press "i", and
then escape again--you've moved another position left. Why is it incapable
of keeping track of such a simple thing as your current position in the
file?
Why does it need two different insert commands, "i" versus "a"? Because one
of them can't insert at the end of a line, and the other can't insert at
the beginning.
And why have command-versus-insert mode at all? No other text editor still
surviving uses such an antiquated concept.
TheFlyingDutchman
and has a free version.
John J. Lee
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
It's quite funny, that what the author proposes as "to make it even
harder" actually speeds up the test for the mouse-users quite a bit.
And "cursor keys"? Please, every self respecting editor has ways for
moving around quite a bit more efficiently.
And on top of that a use case, which no one in his right mind would
do this way. Accomplishing this task with search-and-replace would
have taken about 10 seconds. With Mouse or Keyboard.
Regards,
Manuel
--
A hundred men did the rational thing. The sum of those rational choices was
called panic. Neal Stephenson -- System of the world
http://www.graune.org/GnuPG_pubkey.asc
Key fingerprint = 1E44 9CBD DEE4 9E07 5E0A 5828 5476 7E92 2DB4 3C99
Lawrence D'Oliveiro
> Matthew Woodcraft <matt...@chiark.greenend.org.uk> writes:
>
>> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:>
>>
>>> <http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html>
>>
> And "cursor keys"? Please, every self respecting editor has ways for
> moving around quite a bit more efficiently.
>
> And on top of that a use case, which no one in his right mind would
> do this way. Accomplishing this task with search-and-replace would
> have taken about 10 seconds. With Mouse or Keyboard.
Just to reinforce the point that the above was in no way an artificial or
isolated case:
<http://www.asktog.com/TOI/toi06KeyboardVMouse1.html>
<http://www.asktog.com/TOI/toi22KeyboardVMouse2.html>
Neil Cerutti
<l...@geek-central.gen.new_zealand> wrote:
> In message <5lhs4pF...@mid.individual.net>, Bjoern
> Schliessmann wrote:
>> Nah. Use vim.
>
> Every other text editor I have ever used understands that the
> current position in a file is _between_ two characters (or
> before the first character, or after the last character), not
> _on_ a character. But not vi and its ilk.
>
> Try the following in vi/vim: Move to some point in the middle
> of a line. Press "i" to get into insert mode. Press escape to
> get out again. You'll end up one position to the left of where
> you were before. Press "i", and then escape again--you've moved
> another position left. Why is it incapable of keeping track of
> such a simple thing as your current position in the file?
That's a silly question. Of course it knows your current
position--it just chooses to modify your position when you exit
insert mode.
> Why does it need two different insert commands, "i" versus "a"?
> Because one of them can't insert at the end of a line, and the
> other can't insert at the beginning.
i and a are two of *many* ways to enter insert mode. I'm not sure
all of them are completely justified (I've never uses s or S, for
example). I typically use o, O, i, I and A the most. I don't have
much use for a.
> And why have command-versus-insert mode at all? No other text
> editor still surviving uses such an antiquated concept.
The existence of command mode allows plain old keystrokes to be
commands--it potentially makes commands easier to type. Emacs
users don't find it to be a compelling advantage. ;)
--
Neil Cerutti
Bruno Desthuilliers
(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.
>
Manuel Graune
Without knowing more about the design of those studies, further
discussion is kind of pointless. I would really like to see a comparison
of "mouse-centered IDEs" (e. g. Eclipse) vs. "keyboard-centered IDEs"
(e. g. Emacs). used for some small progamming task (and not isolated
editing problems). For one thing, most programmers more or less
<quote>
are not normal people. We tend to have superior memories, we actually
grasp boolean logic, we have formed priesthoods around the most
egregious interfaces, and we have a firm belief that the average citizen
is in search of an editor for his daily C and Pascal coding tasks.
We are not firmly rooted in the real world.
</quote>
So I'm not really concerned about the first-time user, for which without
a doubt a mouse-based user-interface is easier (and probably faster). I
need an editor/IDE I feel comfortable with after using it for a
month or longer. And for the record: Being subjectively faster is good
enough for me. I don't really care if I could have saved 15 minutes at
the end of the day with the objectively faster interface, if I don't
feel slowed down.
But since this is not a usability-NG and I originally just wanted to
point out that the specific example is far from ideal, I won't
continue this discussion in this NG. If you want to, you can contact me
by mail.
alex
> Well, you may. Unfortunately, there are many NGs that do the opposite.
>
> Bruno Desthuilliers wrote:
>> W. Watson a écrit :
>>> How about in the case of MS Win?
>>>
>>> Ben Finney wrote:
>>>>
>>>> (Please don't top-post. Instead, reply below each point to which
>>>> you're responding, removing quoted text irrelevant to your response.)
>>>>
>>
>> Wayne, may I second Ben on his suggestion to stop top-posting ?
>
*plonk*
Lawrence D'Oliveiro
> On 2007-09-22, Lawrence D'Oliveiro
> <l...@geek-central.gen.new_zealand> wrote:
>
>> In message <5lhs4pF...@mid.individual.net>, Bjoern
>> Schliessmann wrote:
>
>>> Nah. Use vim.
>>
>> Every other text editor I have ever used understands that the
>> current position in a file is _between_ two characters (or
>> before the first character, or after the last character), not
>> _on_ a character. But not vi and its ilk.
>>
>> Try the following in vi/vim: Move to some point in the middle
>> of a line. Press "i" to get into insert mode. Press escape to
>> get out again. You'll end up one position to the left of where
>> you were before. Press "i", and then escape again--you've moved
>> another position left. Why is it incapable of keeping track of
>> such a simple thing as your current position in the file?
>
> That's a silly question. Of course it knows your current
> position--it just chooses to modify your position when you exit
> insert mode.
That's like saying, about a program that, when given "2 + 2", outputs "5",
that _of course_ it knows the correct answer is "4", it just chooses
to "modify" the answer before outputting it.
Why does it "choose" to modify your position when you exit insert mode? Does
the phrase "broken as designed" mean anything to you?
>> Why does it need two different insert commands, "i" versus "a"?
>> Because one of them can't insert at the end of a line, and the
>> other can't insert at the beginning.
>
> i and a are two of *many* ways to enter insert mode.
Why do you need so many ways to enter insert mode?
>> And why have command-versus-insert mode at all? No other text
>> editor still surviving uses such an antiquated concept.
>
> The existence of command mode allows plain old keystrokes to be
> commands--it potentially makes commands easier to type.
And the downside is that the largest single proportion of those commands end
up being variations on "enter insert mode". Because most of the keystrokes
you enter during an editing session are in fact text to be input into the
file, not commands to manipulate that text. So in a modal editor, having to
jump in and out of insert mode all the time just adds to the number of
keystrokes you have to type.
A.T.Hofkamp
> In message <slrnfff9op....@FIAD06.norwich.edu>, Neil Cerutti wrote:
> That's like saying, about a program that, when given "2 + 2", outputs "5",
> that _of course_ it knows the correct answer is "4", it just chooses
> to "modify" the answer before outputting it.
>
> Why does it "choose" to modify your position when you exit insert mode? Does
> the phrase "broken as designed" mean anything to you?
Try to insert 1 character in the middle of a line. You'll end up at the same
position. Now press 'j' (one line down), then '.' (do it again).
I believe that's why.
Great when you have nicely formatted columns of code underneath each other.
(try doing that with your GUI editor with 2 strokes per line of code).
Of course, the same works for a find/edit cycle ('n', check whether edit is
appropiate, and if so: '.')
This combining of commands is what makes the editor powerful.
The cost of that power is a command/insert mode and a steep learning curve.
You may not like the keyboard interface, but that doesn't mean the editor is
not well-designed for its task. In the same way, having the ability to use
multiple input devices doesn't automatically make the editor better.
For example, ever wondered why you on earth you need CTL-C and CTL-V to
copy/paste? Why not simply select with the mouse, then right-click to paste?
All editors have their good and their bad sides. Assuming that anything you
don't like is badly designed is a bit too simple in my opinion.
> And the downside is that the largest single proportion of those commands end
> up being variations on "enter insert mode". Because most of the keystrokes
> you enter during an editing session are in fact text to be input into the
> file, not commands to manipulate that text. So in a modal editor, having to
Depends on what you are doing. When entering new code, yes. When maintaining
code, no (lots of small changes).
In one way or another, you'll have to tell the editor what you want. The cost
of that is either a command/insert mode (vi/vim), a CTL/SHIFT/META-key
combination (emacs), or mouse/menu/submenu/subsubmenu (GUI editors).
I don't know what is best. Probably a matter of taste.
Albert
Bjoern Schliessmann
> That's like saying, about a program that, when given "2 + 2",
> outputs "5", that _of course_ it knows the correct answer is "4",
> it just chooses to "modify" the answer before outputting it.
No. Which laws say how transitions between modes have to be? Thus, I
know laws saying 2 and 2 is 4.
> Why does it "choose" to modify your position when you exit insert
> mode? Does the phrase "broken as designed" mean anything to you?
Does the phrase "everything I don't like is stupid" mean anything to
you? Honestly, if you don't like it, either propose improvement or
stop using it (and complaining about it). Your preference with user
interfaces is obviously different. (Personally, I prefer single
strokes to breaking my fingers with Esc-Meta-Alt-Control-Shift.
:) )
> Why do you need so many ways to enter insert mode?
It can be convenient. For you apprently not, though.
> And the downside is that the largest single proportion of those
> commands end up being variations on "enter insert mode". Because
> most of the keystrokes you enter during an editing session are in
> fact text to be input into the file, not commands to manipulate
> that text.
Strange -- mostly, this is not the case for me. When refactoring
code for example, I jump around, copy, paste and modify many times.
> So in a modal editor, having to jump in and out of insert mode all
> the time just adds to the number of keystrokes you have to type.
Much better than accessing special functions with finger breaking
key combinations. IMHO.
Regards,
Björn
--
BOFH excuse #226:
A star wars satellite accidently blew up the WAN.
Steve Holden
> 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.
> :) )
>
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
> >> Why does it "choose" to modify your position when you exit insert
> >> mode? Does the phrase "broken as designed" mean anything to you?
> >
> > Does the phrase "everything I don't like is stupid" mean anything to
> > you? Honestly, if you don't like it, either propose improvement or
> > stop using it (and complaining about it). Your preference with user
> > interfaces is obviously different. (Personally, I prefer single
> > strokes to breaking my fingers with Esc-Meta-Alt-Control-Shift.
> > :) )
> >
> Does "this non-Python related twaddle is boring the shit out of me" mean
> anything to you both?
+1 QOTW!!
--
# p.d.
Lawrence D'Oliveiro
> On 2007-09-25, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> Why does it "choose" to modify your position when you exit insert mode?
>
> Try to insert 1 character in the middle of a line. You'll end up at the
> same position. Now press 'j' (one line down), then '.' (do it again).
> I believe that's why.
>
> Great when you have nicely formatted columns of code underneath each
> other.
It's strange, but in nearly 30 years of writing code in dozens of different
languages, I've never felt the urge to line up my code in columns. Never.
(Apart from assembly language, which I suspect you don't want to hear
about.)
> The cost of that power is a command/insert mode and a steep learning
> curve.
That's another issue, that of ROI. Having learnt the vi/vim keystrokes, what
does that enable you to do? Use vi/vim, and that's it. Whereas I've found
other situations where subsets of Emacs keystrokes are recognized, such as
anything that uses GNU readline (including the Python console--see, this IS
relevant to Python after all), and pico/nano. These are all extra goodies
that are to be found on the way up the Emacs learning curve.
> For example, ever wondered why you on earth you need CTL-C and CTL-V to
> copy/paste? Why not simply select with the mouse, then right-click to
> paste?
Or better still, why not allow both?
>> And the downside is that the largest single proportion of those commands
>> end up being variations on "enter insert mode". Because most of the
>> keystrokes you enter during an editing session are in fact text to be
>> input into the file, not commands to manipulate that text. So in a modal
>> editor, having to
>
> Depends on what you are doing. When entering new code, yes. When
> maintaining code, no (lots of small changes).
Making lots of small changes is even worse--it means you're jumping into
insert mode for shorter times, more frequently.
And that's when you discover something else: that how you delete text in
vi/vim differs, depending on whether it's something you just inserted while
currently in insert mode, or whether it was there from before you last
entered insert mode: in the former case, you use backspace to delete, in
the latter case, you can't use backspace, you have to use "X". What does
backspace do when not in insert mode? It just moves you through the text.
What does the forward-delete key do? In both modes, it actually deletes
text!
At least with Emacs, text is text--it doesn't matter when it was inserted,
it still behaves the same way.
Ben Finney
> That's another issue, that of ROI. Having learnt the vi/vim
> keystrokes, what does that enable you to do? Use vi/vim, and that's
> it.
There are a great many programs whose interactive keybindings come
from vi. Perhaps you've heard of 'less', 'screen', 'mutt', or dozens
of other frequently-used programs, all of which use 'vi key bindings
by default.
> Whereas I've found other situations where subsets of Emacs
> keystrokes are recognized, such as anything that uses GNU readline
Which can also be configured one-time by the user to use 'vi'
keybindings everywhere, so the 'vi' fanatic is able to keep using the
key bindings they know.
I think this argument is silly — both Emacs and vi(m) have enormous
following, are both extremely capable editors, and both are clearly
the inspiration for many other programs' key bindings. It's ludicrous
to say of either program that "once you learn its key bindings you
only know how to use that program".
--
\ "Welchen Teil von 'Gestalt' verstehen Sie nicht? [What part of |
`\ 'gestalt' don't you understand?]" -- Karsten M. Self |
_o__) |
Ben Finney
Jason M Barnes
On 9/25/07, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
> In message <slrnffhe9...@se-162.se.wtb.tue.nl>, A.T.Hofkamp wrote:
>
> > On 2007-09-25, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> > wrote:
> >
> >> Why does it "choose" to modify your position when you exit insert mode?
> >
> > Try to insert 1 character in the middle of a line. You'll end up at the
> > same position. Now press 'j' (one line down), then '.' (do it again).
> > I believe that's why.
> >
> > Great when you have nicely formatted columns of code underneath each
> > other.
>
> It's strange, but in nearly 30 years of writing code in dozens of different
> languages, I've never felt the urge to line up my code in columns. Never.
> (Apart from assembly language, which I suspect you don't want to hear
> about.)
>
> > The cost of that power is a command/insert mode and a steep learning
> > curve.
>
> That's another issue, that of ROI. Having learnt the vi/vim keystrokes, what
> does that enable you to do? Use vi/vim, and that's it. Whereas I've found
> other situations where subsets of Emacs keystrokes are recognized, such as
> anything that uses GNU readline (including the Python console--see, this IS
> relevant to Python after all), and pico/nano. These are all extra goodies
> that are to be found on the way up the Emacs learning curve.
Off the top of my head, I can think of a few vim commands that have
come in handy. I can search through a webpage in Firefox by using the
same '/' search command that vim has. The movement keys (h,j,k,l) are
the same as in any paging program I've ever used. Not to mention that
I learned regexes by learning 's/regex/replacement' first :-)
>
> > For example, ever wondered why you on earth you need CTL-C and CTL-V to
> > copy/paste? Why not simply select with the mouse, then right-click to
> > paste?
>
> Or better still, why not allow both?
>
> >> And the downside is that the largest single proportion of those commands
> >> end up being variations on "enter insert mode". Because most of the
> >> keystrokes you enter during an editing session are in fact text to be
> >> input into the file, not commands to manipulate that text. So in a modal
> >> editor, having to
> >
> > Depends on what you are doing. When entering new code, yes. When
> > maintaining code, no (lots of small changes).
>
> Making lots of small changes is even worse--it means you're jumping into
> insert mode for shorter times, more frequently.
If you're making lots of small changes, then you shouldn't be jumping
into insert mode at all, IMO.
>
> And that's when you discover something else: that how you delete text in
> vi/vim differs, depending on whether it's something you just inserted while
> currently in insert mode, or whether it was there from before you last
> entered insert mode: in the former case, you use backspace to delete, in
> the latter case, you can't use backspace, you have to use "X". What does
> backspace do when not in insert mode? It just moves you through the text.
> What does the forward-delete key do? In both modes, it actually deletes
> text!
Actually, vim always deletes the same way regardless of when it was
inserted -- one of the many *improvements* over vi.
That's my religion anyway ;-), but I thought this was a python mailing list ;-)
Jason
>
> At least with Emacs, text is text--it doesn't matter when it was inserted,
> it still behaves the same way.
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
--
BOFH excuse #185:
system consumed all the paper for paging
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.
--
Neil Cerutti
Jason M Barnes
> On 2007-09-26, Jason M Barnes <json....@gmail.com> wrote:
> > Off the top of my head, I can think of a few vim commands that
> > have come in handy. I can search through a webpage in Firefox
> > by using the same '/' search command that vim has. The
> > movement keys (h,j,k,l) are the same as in any paging program
> > I've ever used. Not to mention that I learned regexes by
> > learning 's/regex/replacement' first :-)
>
> Yup. A huge advantge of learning vi is how much it helps improve
> your nethack experience. ;) Ignorance was Emacs was an obstacle I
> had to overcome in order to get into the Lisp world, though.
Ha! I'm trying to learn Lisp now, too, and I'm having to learn Emacs
to be more efficient. I feel like I'm taking my first CS class again.
(Now was that C-x C-c or M-c M-x?... Nope, that didn't work... ;-)
>
> > That's my religion anyway ;-), but I thought this was a python
> > mailing list ;-)
>
> Vim has Python integration if you want to control it with Python
> scripts. Cool! Of course, Vim needs such a capability more than
> Emacs, which has the very cool elisp scripting language. I'm not
> so keen on Vim's built-in scripting language.
>
> --
> Neil Cerutti
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?
--
Cheers,
Simon B.
si...@brunningonline.net
[1] http://tinyurl.com/yvra7l
Bruno Desthuilliers
(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?
--
\ "He who laughs last, thinks slowest." -- Anonymous |
`\ |
_o__) |
Ben Finney