Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #110069 > unrolled thread

best text editor for programming Python on a Mac

Started byChris <cspears2002@yahoo.com>
First post2016-06-17 16:52 -0700
Last post2016-07-06 03:27 -0700
Articles 20 on this page of 88 — 29 participants

Back to article view | Back to comp.lang.python


Contents

  best text editor for programming Python on a Mac Chris <cspears2002@yahoo.com> - 2016-06-17 16:52 -0700
    Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-17 17:19 -0700
      Re: best text editor for programming Python on a Mac Ned Batchelder <ned@nedbatchelder.com> - 2016-06-17 17:36 -0700
        Re: best text editor for programming Python on a Mac wxjmfauth@gmail.com - 2016-06-20 01:39 -0700
    Re: best text editor for programming Python on a Mac MRAB <python@mrabarnett.plus.com> - 2016-06-18 01:58 +0100
      Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-17 18:50 -0700
        Re: best text editor for programming Python on a Mac Steven D'Aprano <steve@pearwood.info> - 2016-06-18 12:05 +1000
    Re: best text editor for programming Python on a Mac Steven D'Aprano <steve@pearwood.info> - 2016-06-18 11:55 +1000
    Re: best text editor for programming Python on a Mac Zachary Ware <zachary.ware+pylist@gmail.com> - 2016-06-17 20:59 -0500
    Re: best text editor for programming Python on a Mac support@ecourierz.com - 2016-06-17 22:18 -0700
      Re: best text editor for programming Python on a Mac Michael Vilain <mev94303y@yahoo.com> - 2016-06-18 00:04 -0700
        Re: best text editor for programming Python on a Mac Terry Reedy <tjreedy@udel.edu> - 2016-06-18 05:09 -0400
        Re: best text editor for programming Python on a Mac Marko Rauhamaa <marko@pacujo.net> - 2016-06-18 12:40 +0300
          Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-18 03:08 -0700
            Re: best text editor for programming Python on a Mac Michael Vilain <mev94303y@yahoo.com> - 2016-06-18 07:12 -0700
          Re: best text editor for programming Python on a Mac alister <alister.ware@ntlworld.com> - 2016-06-18 13:22 +0000
          Re: best text editor for programming Python on a Mac Michael Vilain <mev94303y@yahoo.com> - 2016-06-18 07:08 -0700
            Re: best text editor for programming Python on a Mac Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-18 16:08 -0400
          Re: best text editor for programming Python on a Mac Rustom Mody <rustompmody@gmail.com> - 2016-06-18 09:02 -0700
        Re: best text editor for programming Python on a Mac Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-20 10:38 +1200
    best text editor for programming Python on a Mac MrJean1 <MrJean1@gmail.com> - 2016-06-18 08:52 -0700
    Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-18 17:07 -0600
      Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-18 17:12 -0700
        Re: best text editor for programming Python on a Mac Joel Goldstick <joel.goldstick@gmail.com> - 2016-06-18 20:26 -0400
          Re: best text editor for programming Python on a Mac Pete Forman <petef4+usenet@gmail.com> - 2016-06-19 11:41 +0100
            Re: best text editor for programming Python on a Mac Marko Rauhamaa <marko@pacujo.net> - 2016-06-19 15:57 +0300
            Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-19 07:19 -0600
              Re: best text editor for programming Python on a Mac Rustom Mody <rustompmody@gmail.com> - 2016-06-19 09:20 -0700
                Re: best text editor for programming Python on a Mac Christian Gollwitzer <auriocus@gmx.de> - 2016-06-19 20:06 +0200
                  Re: best text editor for programming Python on a Mac Rustom Mody <rustompmody@gmail.com> - 2016-06-19 11:13 -0700
                  Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-19 13:04 -0600
                Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-19 12:58 -0600
                  Re: best text editor for programming Python on a Mac Steven D'Aprano <steve@pearwood.info> - 2016-06-20 11:32 +1000
                    ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-19 19:07 -0700
                      Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Steven D'Aprano <steve@pearwood.info> - 2016-06-20 13:29 +1000
                        Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Phil Boutros <philb@philb.ca> - 2016-06-20 04:30 +0000
                          Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-19 22:03 -0700
                            Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Random832 <random832@fastmail.com> - 2016-06-20 02:04 -0400
                              Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-20 07:00 -0700
                          Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-20 00:57 -0700
                            Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-20 20:24 +1000
                          Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-20 14:23 +0000
                            Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Steven D'Aprano <steve@pearwood.info> - 2016-06-21 01:00 +1000
                              Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-20 08:12 -0700
                        Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-19 21:36 -0700
                          Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-19 21:41 -0700
                        Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Larry Hudson <orgnut@yahoo.com> - 2016-06-21 00:40 -0700
                          Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Marko Rauhamaa <marko@pacujo.net> - 2016-06-21 11:35 +0300
                            Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-21 03:46 -0700
                              Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Marko Rauhamaa <marko@pacujo.net> - 2016-06-21 16:08 +0300
                                Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-21 06:56 -0700
                                  Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-21 07:11 -0700
                                  Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-22 19:01 -0700
                                    Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-22 19:07 -0700
                                Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Rustom Mody <rustompmody@gmail.com> - 2016-06-21 07:29 -0700
                                  Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Marko Rauhamaa <marko@pacujo.net> - 2016-06-21 21:56 +0300
                                    Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Tim Chase <python.list@tim.thechases.com> - 2016-06-21 14:42 -0500
                                      Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Marko Rauhamaa <marko@pacujo.net> - 2016-06-21 23:08 +0300
                                      Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-22 00:55 -0700
                                        Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Tim Chase <python.list@tim.thechases.com> - 2016-06-22 06:09 -0500
                            Re: ASCII or Unicode? (was best text editor for programming Python on a Mac) Tim Chase <python.list@tim.thechases.com> - 2016-06-21 10:08 -0500
                    Re: best text editor for programming Python on a Mac Tim Chase <python.list@tim.thechases.com> - 2016-06-19 21:41 -0500
          Re: best text editor for programming Python on a Mac Quivis <quivis@domain.invalid> - 2016-06-19 21:21 +0000
            Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-19 16:15 -0600
              Re: best text editor for programming Python on a Mac Christian Gollwitzer <auriocus@gmx.de> - 2016-06-20 09:37 +0200
        Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-18 18:50 -0600
        Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-18 19:01 -0600
        Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-18 20:09 -0600
          Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-18 19:51 -0700
            Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-18 22:54 -0600
              Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-18 22:57 -0700
            Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-18 22:56 -0600
            Re: best text editor for programming Python on a Mac Tim Chase <python.list@tim.thechases.com> - 2016-06-19 06:36 -0500
        Re: best text editor for programming Python on a Mac Christian Gollwitzer <auriocus@gmx.de> - 2016-06-19 09:13 +0200
          Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-19 00:34 -0700
            Re: best text editor for programming Python on a Mac Rustom Mody <rustompmody@gmail.com> - 2016-06-19 00:47 -0700
            Re: best text editor for programming Python on a Mac Christian Gollwitzer <auriocus@gmx.de> - 2016-06-19 09:57 +0200
            Re: best text editor for programming Python on a Mac Michael Torrie <torriem@gmail.com> - 2016-06-19 07:23 -0600
              Re: best text editor for programming Python on a Mac alister <alister.ware@ntlworld.com> - 2016-06-20 08:30 +0000
        Re: best text editor for programming Python on a Mac Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-20 10:44 +1200
          Re: best text editor for programming Python on a Mac Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-20 00:59 -0700
          Re: best text editor for programming Python on a Mac Random832 <random832@fastmail.com> - 2016-06-20 09:26 -0400
            Re: best text editor for programming Python on a Mac Christian Gollwitzer <auriocus@gmx.de> - 2016-06-20 15:36 +0200
              Re: best text editor for programming Python on a Mac Rustom Mody <rustompmody@gmail.com> - 2016-06-20 06:48 -0700
                Re: best text editor for programming Python on a Mac Christian Gollwitzer <auriocus@gmx.de> - 2016-06-20 16:03 +0200
    best text editor for programming Python on a Mac drednot57 <dpresley@midiowa.net> - 2016-06-18 19:48 -0700
    Re: best text editor for programming Python on a Mac jennifer.greeen@gmail.com - 2016-07-06 03:25 -0700
    Re: best text editor for programming Python on a Mac jennifer.greeen@gmail.com - 2016-07-06 03:27 -0700

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →


#110242 — Re: ASCII or Unicode? (was best text editor for programming Python on a Mac)

FromTim Chase <python.list@tim.thechases.com>
Date2016-06-21 10:08 -0500
SubjectRe: ASCII or Unicode? (was best text editor for programming Python on a Mac)
Message-ID<mailman.7.1466526449.11516.python-list@python.org>
In reply to#110222
On 2016-06-21 11:35, Marko Rauhamaa wrote:
> > These are all pretty easy to remember.
> > German umlauts a" o" u" give ä ö ü  (or use uppercase)
> > Spanish eña (spelling?) and punctuations:  n~ ?? !!  -->  ñ ¿ ¡
> > French accents:  e' e` e^ c,  -->  é è ê ç
> > Money:  c= l- y- c/  -->  € £ ¥ ¢
> > Math:  =/ -: +- xx <= >=  -->  ≠ ÷ ± × ≤ ≥
> > Superscripts:  ^0 ^1 ^2 ^3  -->  ⁰ ¹ ² ³
> > Simple fractions:  12 13 ... 78  -->  ½ ⅓ ... ⅞
> > Here's a cute one:  CCCP  -->  ☭  (hammer & sickle)
> > And like your first examples:  oo mu ss  -->  ° µ ß  
> 
> Trouble is, nobody's going to guess or memorize any of that stuff.

I've been pleasantly surprised by how guessable most of them are.
Occasionally I have to dig a bit deeper, but for diacritics,
superscripts (using the "^", as well as subscripts using "_"),
fractions, and arrows (either a "-" or a "|" followed by a
character that looks like the arrow-head "<>v^") are all pretty easy
to guess when you understand the patterns.

-tkc


[toc] | [prev] | [next] | [standalone]


#110173

FromTim Chase <python.list@tim.thechases.com>
Date2016-06-19 21:41 -0500
Message-ID<mailman.146.1466399038.2288.python-list@python.org>
In reply to#110163
On 2016-06-20 11:32, Steven D'Aprano wrote:
> On Mon, 20 Jun 2016 04:58 am, Michael Torrie wrote:
> 
> > When the cursor is over character, do command "ga" and it will
> > show you the hex code for that character.
> > 
> > http://vim.wikia.com/wiki/Showing_the_ASCII_value_of_the_current_character
> 
> /me cries
> 
> Every time somebody refers to "the ASCII value" of non-ASCII
> characters, God kills a puppy.

Though to be fair, vim and Unicode both have their origins around
1987, so for one to know of the other would have taken a bit of
miraculous prognostication.  Despite existing since then, I don't
recall hearing much about Unicode as a *common* standard until the
early 2000s, so that's defensibly ~13 years of (semi-)obscurity
during parallel development.

The "ga" mnemonic of "[g]a=ascii value" made much more sense in the
historical context.  Now that Vim supports Unicode, "ga" shows the
ordinal value depending on the internal encoding.  If that internal
encoding is UTF or UCS encoded Unicode (whether 8-bit, 16-bit, or
32-bit, big-or-little endian), then it shows the code-point. If it's
a one- or two-byte encoding, vim returns that index.  So the
mnemonic should become "ga=ascii value or unicode code point along
with possible combing/composing-character code-points".  Not as
helpful a mnemonic.  As an aside, Vim also provides a "g8" command to
show the decomposed hex bytes of a UTF-8 byte sequence if you want
those values instead. Both should handle combining/composing
characters as well.

-tkc

For more details within vim:

:help ga
:help g8
:help encoding-values

[toc] | [prev] | [next] | [standalone]


#110156

FromQuivis <quivis@domain.invalid>
Date2016-06-19 21:21 +0000
Message-ID<F1E9z.126391$z63.93714@fx42.am4>
In reply to#110121
On Sat, 18 Jun 2016 20:26:36 -0400, Joel Goldstick wrote:

> that it is on every linux system

No, it isn't! I can be *installed* on every Linux system, but that a 
whole other can of worms.

-- 
  _____  __ __ __ __ __ __   __
 ((   )) || || || \\ // ||  ((
  \\_/X| \\_// ||  \V/  || \_))
   Omnia paratus  *~*~*~*~*~*~*

[toc] | [prev] | [next] | [standalone]


#110158

FromMichael Torrie <torriem@gmail.com>
Date2016-06-19 16:15 -0600
Message-ID<mailman.144.1466374552.2288.python-list@python.org>
In reply to#110156
On 06/19/2016 03:21 PM, Quivis wrote:
> On Sat, 18 Jun 2016 20:26:36 -0400, Joel Goldstick wrote:
> 
>> that it is on every linux system
> 
> No, it isn't! I can be *installed* on every Linux system, but that a 
> whole other can of worms.

True vim is not. But vi should be.  I'm not aware of any Linux distro
which does not install it.  Do you know of a distro that does not?  Even
Ubuntu with it's nano default editor installs vi, if I'm not mistaken.
Some distros use a stripped-down version of vim (perhaps vim-tiny)
instead of vi, but the command "vi" is always going to be there.  Even
on my embedded OpenWRT devices!

[toc] | [prev] | [next] | [standalone]


#110182

FromChristian Gollwitzer <auriocus@gmx.de>
Date2016-06-20 09:37 +0200
Message-ID<nk86fi$ljt$1@dont-email.me>
In reply to#110158
Am 20.06.16 um 00:15 schrieb Michael Torrie:
> On 06/19/2016 03:21 PM, Quivis wrote:
>> On Sat, 18 Jun 2016 20:26:36 -0400, Joel Goldstick wrote:
>>
>>> that it is on every linux system
>>
>> No, it isn't! I can be *installed* on every Linux system, but that a
>> whole other can of worms.
>
> True vim is not. But vi should be.  I'm not aware of any Linux distro
> which does not install it.  Do you know of a distro that does not?

That would be very strange, since vi is mandated by POSIX

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html

Of course there are other options, like elvis or busybox, but unless you 
are building a minimalist POSIX system the most viable option would be 
to install vim. So practically every desktop Linux distro ships with vim.

	Christian

[toc] | [prev] | [next] | [standalone]


#110122

FromMichael Torrie <torriem@gmail.com>
Date2016-06-18 18:50 -0600
Message-ID<mailman.128.1466297416.2288.python-list@python.org>
In reply to#110120
On 06/18/2016 06:12 PM, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 11:07:23 AM UTC+12, Michael Torrie
> wrote:
>> 
>> On 06/17/2016 05:52 PM, Chris via Python-list wrote:
>>> 
>>> Any suggestions for a good open source text editor for the Mac
>>> out there?  For now, I am going to stick with vim.
>> 
>> Good choice.
> 
> The trouble with vim/vi/whatever, is that it doesn’t work like any
> other editor on Earth.

The fact that the OP is using vim would suggest this doesn't really
matter to him all that much.

> Pull up any old GUI-based editor you like, for example Windows
> (shudder) Notepad. If there are N characters in your file, then the
> insertion point can be placed at N + 1 positions: in-between two
> adjacent characters, or before the first character, or after the last
> character. And this makes sense: anything you type is inserted at the
> insertion point. All rational text editors (and word processors) work
> this way.

Indeed, so does vi/vim.  Why do you think otherwise?

> But not vi/vim. It only lets you place your cursor *on* a character,
> not *in-between* characters. That’s why you need two separate
> insertion commands, insert-before and insert-after. And one of those
> has the interesting side effect where, if you exit insertion mode
> without inserting anything, it doesn’t put you back in the same
> position as before. Why?
> 
> As to why you need insertion commands at all, that’s another
> thing...

Having used vim for years and also normal editors including word
processors, I have no idea what you're talking about by how insert
works.  It works the exactly the same.  I put my cursor under a letter,
hit insert, and I am inserting text before that letter, just like any
other text editor.

[toc] | [prev] | [next] | [standalone]


#110123

FromMichael Torrie <torriem@gmail.com>
Date2016-06-18 19:01 -0600
Message-ID<mailman.129.1466298068.2288.python-list@python.org>
In reply to#110120
On 06/18/2016 06:50 PM, Michael Torrie wrote:
> On 06/18/2016 06:12 PM, Lawrence D’Oliveiro wrote:
>> But not vi/vim. It only lets you place your cursor *on* a character,
>> not *in-between* characters. That’s why you need two separate
>> insertion commands, insert-before and insert-after. And one of those
>> has the interesting side effect where, if you exit insertion mode
>> without inserting anything, it doesn’t put you back in the same
>> position as before. Why?

Nevermind I see what you are talking about.  Doesn't bother me though.

>> As to why you need insertion commands at all, that’s another
>> thing...

In it's day, the scriptability of ed depended on this feature.

[toc] | [prev] | [next] | [standalone]


#110124

FromMichael Torrie <torriem@gmail.com>
Date2016-06-18 20:09 -0600
Message-ID<mailman.130.1466302157.2288.python-list@python.org>
In reply to#110120
On 06/18/2016 06:12 PM, Lawrence D’Oliveiro wrote:
> Pull up any old GUI-based editor you like, for example Windows
> (shudder) Notepad. If there are N characters in your file, then the
> insertion point can be placed at N + 1 positions: in-between two
> adjacent characters, or before the first character, or after the last
> character. And this makes sense: anything you type is inserted at the
> insertion point. All rational text editors (and word processors) work
> this way.
> 
> But not vi/vim. It only lets you place your cursor *on* a character,
> not *in-between* characters. That’s why you need two separate
> insertion commands, insert-before and insert-after. And one of those
> has the interesting side effect where, if you exit insertion mode
> without inserting anything, it doesn’t put you back in the same
> position as before. Why?

In thinking about this, I think the answer is that in olden days no one
had though of using the imaginary spaces between characters as a
position.  So we had:

0 1 2 3 4 5 6 7 8 9
H E L L O W O R L D

10 character cells, 10 cursor positions.  Hence you had 10 places you
could insert before (which works well for everything but appending to
the string) or 10 places to insert after.  So that distinction between
insert and append was logical, and still is today, depending on your
background and experience.

It was later on that they figured out the N+1 thing you mentioned by
ignoring the character cells:

0 1 2 3 4 5 6 7 8 9 10
 H E L L O W O R L D

That works well for interactive editing, but it doesn't lend itself as
well to scripting and working with the contents of the text cells.
Indeed the text cells aren't actually addressable directly in this
scheme though conventionally the number immediately before the cell is
used to index the cell.  This can lead to confusion.  For example, if
the cursor is in position 10, that's not really part of the text, but it
kind of appears like it is.

I like that with vim I can see immediately whether there is trailing
space on a line just by jumping to the end of the line ($) which will
drop the cursor on the last actual character.

So I guess it's just a matter of history.  Perhaps it's a bit like big
endian vs little endian. Neither system is inherently better; it's just
what you get used to.  And arguments can be made either way.

[toc] | [prev] | [next] | [standalone]


#110126

FromLawrence D’Oliveiro <lawrencedo99@gmail.com>
Date2016-06-18 19:51 -0700
Message-ID<7fdf0a4d-64ef-495e-82ff-18707e3ca429@googlegroups.com>
In reply to#110124
On Sunday, June 19, 2016 at 2:09:31 PM UTC+12, Michael Torrie wrote:
> It was later on that they figured out the N+1 thing you mentioned by
> ignoring the character cells:
> 
> 0 1 2 3 4 5 6 7 8 9 10
>  H E L L O W O R L D
> 
> That works well for interactive editing, but it doesn't lend itself as
> well to scripting and working with the contents of the text cells.

Emacs scripting works perfectly well with this convention.

> I like that with vim I can see immediately whether there is trailing
> space on a line just by jumping to the end of the line ($) which will
> drop the cursor on the last actual character.

Emacs has an option (which I have enabled) which shows trailing white space throughout your entire file in bright red. And I have also defined a single keystroke that will get rid of it all.

[toc] | [prev] | [next] | [standalone]


#110127

FromMichael Torrie <torriem@gmail.com>
Date2016-06-18 22:54 -0600
Message-ID<mailman.131.1466312062.2288.python-list@python.org>
In reply to#110126
On 06/18/2016 08:51 PM, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 2:09:31 PM UTC+12, Michael Torrie wrote:
>> It was later on that they figured out the N+1 thing you mentioned by
>> ignoring the character cells:
>>
>> 0 1 2 3 4 5 6 7 8 9 10
>>  H E L L O W O R L D
>>
>> That works well for interactive editing, but it doesn't lend itself as
>> well to scripting and working with the contents of the text cells.
> 
> Emacs scripting works perfectly well with this convention.

Yes that's true.

Just saying though, it wasn't always obvious which is why ed chose to do
it the way they did.  vi, being somewhat compatible with ed's command
structure, follows the same pattern.  Two different ways of doing
things. Let's not make the mistake of thinking one way is necessarily
better.

[toc] | [prev] | [next] | [standalone]


#110129

FromLawrence D’Oliveiro <lawrencedo99@gmail.com>
Date2016-06-18 22:57 -0700
Message-ID<9030e089-5087-4e0a-9b71-cda427c1ebc4@googlegroups.com>
In reply to#110127
On Sunday, June 19, 2016 at 4:54:36 PM UTC+12, Michael Torrie wrote:

> Two different ways of doing things. Let's not make the mistake of thinking one
> way is necessarily better.

When one leads to more complications, the answer is pretty clear...

[toc] | [prev] | [next] | [standalone]


#110128

FromMichael Torrie <torriem@gmail.com>
Date2016-06-18 22:56 -0600
Message-ID<mailman.132.1466312175.2288.python-list@python.org>
In reply to#110126
On 06/18/2016 08:51 PM, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 2:09:31 PM UTC+12, Michael Torrie wrote:
>> It was later on that they figured out the N+1 thing you mentioned
>> by ignoring the character cells:
>> 
>> 0 1 2 3 4 5 6 7 8 9 10 H E L L O W O R L D
>> 
>> That works well for interactive editing, but it doesn't lend itself
>> as well to scripting and working with the contents of the text
>> cells.
> 
> Emacs scripting works perfectly well with this convention.
> 
>> I like that with vim I can see immediately whether there is
>> trailing space on a line just by jumping to the end of the line ($)
>> which will drop the cursor on the last actual character.
> 
> Emacs has an option (which I have enabled) which shows trailing white
> space throughout your entire file in bright red. And I have also
> defined a single keystroke that will get rid of it all.

And I got it wrong anyway. Both ed and vim either put the cursor between
characters (insert mode), or on the character (command mode).  Probably
made sense at the time.

[toc] | [prev] | [next] | [standalone]


#110147

FromTim Chase <python.list@tim.thechases.com>
Date2016-06-19 06:36 -0500
Message-ID<mailman.140.1466352636.2288.python-list@python.org>
In reply to#110126
On 2016-06-18 22:56, Michael Torrie wrote:
> And I got it wrong anyway. Both ed and vim either put the cursor
> between characters (insert mode), or on the character (command
> mode).  Probably made sense at the time.

Correct for vi/vim, but not ed which has no real concept of a
characterwise "insert mode". Rather, "insert mode" is where you enter
one line at a time (using whatever your system's line-input function
does for cursor display; with behavior possibly modified if you use
`rlwrap`) until you finish entering your text by putting a lone
period on a line.

-tkc


[toc] | [prev] | [next] | [standalone]


#110130

FromChristian Gollwitzer <auriocus@gmx.de>
Date2016-06-19 09:13 +0200
Message-ID<nk5gm9$ltq$1@dont-email.me>
In reply to#110120
Am 19.06.16 um 02:12 schrieb Lawrence D’Oliveiro:
> The trouble with vim/vi/whatever, is that it doesn’t work like any
> other editor on Earth.
>
> Pull up any old GUI-based editor you like, for example Windows
> (shudder) Notepad. If there are N characters in your file, then the
> insertion point can be placed at N + 1 positions: in-between two
> adjacent characters, or before the first character, or after the last
> character.
> But not vi/vim. It only lets you place your cursor *on* a character,
> not *in-between* characters.

This is true if you use the text-mode version. I prefer gvim (actually 
macvim on the mac) which feels much more like a modern editor. Once you 
go to insert mode, you won't notice that it is special unless you hit 
Escape. You can place the cursor in between characters, as you said, you 
can backspace to join two lines together, you can push some buttons and 
menu entries to save files, a standard dialog comes up to choose a file etc.
In the original vi, command mode was necessary to get this functionality 
- even to move the cursor or delete a character - but with gvim/macvim 
you get both a standard/modern interface in insert mode and the commands 
if you need them.

> That’s why you need two separate
> insertion commands, insert-before and insert-after.

I rarely do "a" because pushing "i" and then cursor-right does the same 
in vim, even in the text mode variant you can move the cursor after the 
last character.

	Christian

[toc] | [prev] | [next] | [standalone]


#110131

FromLawrence D’Oliveiro <lawrencedo99@gmail.com>
Date2016-06-19 00:34 -0700
Message-ID<52cb588a-4b6d-4097-884c-8b38db42136e@googlegroups.com>
In reply to#110130
On Sunday, June 19, 2016 at 7:13:26 PM UTC+12, Christian Gollwitzer wrote:

> Am 19.06.16 um 02:12 schrieb Lawrence D’Oliveiro:
>
>> But not vi/vim. It only lets you place your cursor *on* a character,
>> not *in-between* characters.
> 
> This is true if you use the text-mode version. I prefer gvim (actually 
> macvim on the mac) which feels much more like a modern editor.

Why not just use a modern editor, and be done with it?

[toc] | [prev] | [next] | [standalone]


#110132

FromRustom Mody <rustompmody@gmail.com>
Date2016-06-19 00:47 -0700
Message-ID<01ed9e07-c72e-4ec9-9fab-3e7d37abe082@googlegroups.com>
In reply to#110131
On Sunday, June 19, 2016 at 1:04:37 PM UTC+5:30, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 7:13:26 PM UTC+12, Christian Gollwitzer wrote:
> 
> > Am 19.06.16 um 02:12 schrieb Lawrence D’Oliveiro:
> >
> >> But not vi/vim. It only lets you place your cursor *on* a character,
> >> not *in-between* characters.
> > 
> > This is true if you use the text-mode version. I prefer gvim (actually 
> > macvim on the mac) which feels much more like a modern editor.
> 
> Why not just use a modern editor, and be done with it?

You say "Use a modern editor"
And you use emacs??
Heh!!

And its not just that emacs is one of the oldest pieces of software in use today
that I am talking of

Its decades of crud that really gets me
eg. What do Control-X/C mean on any App of your choice today?
And what do they mean in emacs?

JFTR I am an emacs user for some 20+ years
Its just that not only do my 20- year old students not tolerate emacs, of late they
stop tolerating me if I use emacs!!

What do they prefer as an editor?  Gawd knows!
Web browser maybe?? More likely a phone... 

[toc] | [prev] | [next] | [standalone]


#110133

FromChristian Gollwitzer <auriocus@gmx.de>
Date2016-06-19 09:57 +0200
Message-ID<nk5j8j$t75$1@dont-email.me>
In reply to#110131
Am 19.06.16 um 09:34 schrieb Lawrence D’Oliveiro:
> On Sunday, June 19, 2016 at 7:13:26 PM UTC+12, Christian Gollwitzer wrote:
>
>> Am 19.06.16 um 02:12 schrieb Lawrence D’Oliveiro:
>>
>>> But not vi/vim. It only lets you place your cursor *on* a character,
>>> not *in-between* characters.
>>
>> This is true if you use the text-mode version. I prefer gvim (actually
>> macvim on the mac) which feels much more like a modern editor.
>
> Why not just use a modern editor, and be done with it?

Because you still *can* use the features it offers? For example, I do 
not know many editors which can autocomplete file names, this is very 
nice when you write scripts which refer to external files. Or pass a 
part of a script through an external program.

Maybe I was unclear about the insert mode thing. gvim is a GUI program 
with toolbars and menus and mouse actions. It *is* a modern editor. It 
provides syntax highlighting, autocompletion, folding, tabbed windows, 
an error window to navigate compiler errors etc. There are not many 
editors out there that can compete, are free and not weird. But unlike 
"vim" in a console window, "gvim" (Linux) or "macvim" (OSX) behaves 
according to current interface design, it feels integrated to the 
platform. And yes, the insertion cursor is a vertical bar, not block, 
and sits between the characters.

	Christian

[toc] | [prev] | [next] | [standalone]


#110141

FromMichael Torrie <torriem@gmail.com>
Date2016-06-19 07:23 -0600
Message-ID<mailman.135.1466342599.2288.python-list@python.org>
In reply to#110131
On 06/19/2016 01:34 AM, Lawrence D’Oliveiro wrote:
> On Sunday, June 19, 2016 at 7:13:26 PM UTC+12, Christian Gollwitzer wrote:
> 
>> Am 19.06.16 um 02:12 schrieb Lawrence D’Oliveiro:
>>
>>> But not vi/vim. It only lets you place your cursor *on* a character,
>>> not *in-between* characters.
>>
>> This is true if you use the text-mode version. I prefer gvim (actually 
>> macvim on the mac) which feels much more like a modern editor.
> 
> Why not just use a modern editor, and be done with it?

Why would you even suggest this to a vim user?  What's your point?  If
you're not a vim user then you have no idea how vim benefits the person
who is proficient in it and enjoys using it. There are many reasons to
use vim.  Since you're not really interested in these reasons I won't
bother re-stating them here.  I'm sure there are reasons you prefer a
"modern editor" also.

I can argue all day long about how arcane emacs is, and argue how
wodnerful vim is, but I could never in seriousness suggest to an emacs
user that he'd be better off using vim or a "modern editor."  Nor should
you.

[toc] | [prev] | [next] | [standalone]


#110187

Fromalister <alister.ware@ntlworld.com>
Date2016-06-20 08:30 +0000
Message-ID<YQN9z.134176$5w3.95590@fx40.am4>
In reply to#110141
On Sun, 19 Jun 2016 07:23:15 -0600, Michael Torrie wrote:

> On 06/19/2016 01:34 AM, Lawrence D’Oliveiro wrote:
>> On Sunday, June 19, 2016 at 7:13:26 PM UTC+12, Christian Gollwitzer
>> wrote:
>> 
>>> Am 19.06.16 um 02:12 schrieb Lawrence D’Oliveiro:
>>>
>>>> But not vi/vim. It only lets you place your cursor *on* a character,
>>>> not *in-between* characters.
>>>
>>> This is true if you use the text-mode version. I prefer gvim (actually
>>> macvim on the mac) which feels much more like a modern editor.
>> 
>> Why not just use a modern editor, and be done with it?
> 
> Why would you even suggest this to a vim user?  What's your point?  If
> you're not a vim user then you have no idea how vim benefits the person
> who is proficient in it and enjoys using it. There are many reasons to
> use vim.  Since you're not really interested in these reasons I won't
> bother re-stating them here.  I'm sure there are reasons you prefer a
> "modern editor" also.
> 
> I can argue all day long about how arcane emacs is, and argue how
> wodnerful vim is, but I could never in seriousness suggest to an emacs
> user that he'd be better off using vim or a "modern editor."  Nor should
> you.

indeed

The only thing EMACS lacks is a good text editor.

Vi has two modes "beep repeatedly" and "break Everything"

Although both the editors are extremely powerful they both suffer from 
over design.
 




-- 
If at first you don't succeed, you are running about average.

[toc] | [prev] | [next] | [standalone]


#110161

FromGregory Ewing <greg.ewing@canterbury.ac.nz>
Date2016-06-20 10:44 +1200
Message-ID<dsolj7FevdrU1@mid.individual.net>
In reply to#110120
Lawrence D’Oliveiro wrote:
> But not vi/vim. It only lets you place your cursor *on* a character, not
> *in-between* characters.

That's because the terminals it was designed to work on
didn't have any way of displaying a cursor between two
characters. Emacs is the same (except it doesn't go as
far as having two different insertion modes -- you just
think of the insertion point as being to the left of
the character that the cursor is on).

I would say that's about the *least* weird thing about
vi[m] though... :-(

-- 
Greg

[toc] | [prev] | [next] | [standalone]


Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.python


csiph-web