Re: An Editor that Skips to the End of a Def

2007-09-25 Thread Jason M Barnes
Warning: Religion follows:

On 9/25/07, Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, A.T.Hofkamp wrote:
>
> > On 2007-09-25, Lawrence D'Oliveiro <[EMAIL PROTECTED]>
> > 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


Re: An Editor that Skips to the End of a Def

2007-09-26 Thread Jason M Barnes
On 9/26/07, Neil Cerutti <[EMAIL PROTECTED]> wrote:
> On 2007-09-26, Jason M Barnes <[EMAIL PROTECTED]> 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


Re: Bug with lists of pairs of lists and append()

2007-09-28 Thread Jason M Barnes
On 9/28/07, Gabriel Zachmann <[EMAIL PROTECTED]> wrote:
> Well,
>
> could some kind soul please explain to me why the following trivial code is
> misbehaving?
>
> #!/usr/bin/python
>
> lst = [ 0, 1, 2 ]
>
> s = []
>
> l = [ lst[0] ]
> r = lst[1:]
> while r:
> x = (l,r)
> print x
> s.append( x )
>
> l.append( r.pop(0) )
>
> print s
>
>
>
> The output I get is:
>
> ([0], [1, 2])
> ([0, 1], [2])
> [([0, 1, 2], []), ([0, 1, 2], [])]
>
> and the error is in the last line: the two pairs in the outer list are
> identical and they should be as the pairs on the first and the 2nd line,
> respectively!
>
> I think I'm going nuts -- for the life of me I don't see what's going on ...
> (I've been tracking down a bug in my larger python script, and the cause
> seems to boil down to the above snippet.)
>
> Thanks a lot in advance for any insights, etc.
>
> Best regards,
> Gabriel.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

If you're familiar with C or C++, think of s as holding a pointer to x
which in turn holds a pointer to l and r, so when you change l or r, x
(and s indirectly) is still pointing to the same lists which by the
end of your loop have changed to r=[] and l=[0,1,2].

BTW:  It's not really "misbehaving."  It's doing exactly what you're
telling it to do ;-)

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