Re: What text editor is everyone using for Python

Discussion in 'Python' started by Mel, May 26, 2009.

  1. Mel

    Mel Guest

    LittleGrasshopper wrote:

    > With so many choices, I was wondering what editor is the one you
    > prefer when coding Python, and why. I normally use vi, and just got
    > into Python, so I am looking for suitable syntax files for it, and
    > extra utilities. I dabbled with emacs at some point, but couldn't get
    > through the key bindings for commands. I've never tried emacs with vi
    > keybindings (I forgot the name of it) but I've been tempted.
    >
    > So what do you guys use, and why? Hopefully we can keep this civil.

    SciTE
    I like one big uncomplicated window, tabbed file panes, syntax coloring and
    help with indentation. There's nothing to it I hate. It would be nice if
    customization were easier.

    Mel.
    Mel, May 26, 2009
    #1
    1. Advertising

  2. Mel

    John Yeung Guest

    On May 26, 9:43 am, Mel <> wrote:

    >  SciTE
    > I like one big uncomplicated window, tabbed file panes,
    > syntax coloring and help with indentation.  There's
    > nothing to it I hate.  It would be nice if
    > customization were easier.


    This is a decent summary of SciTE, but I kind of marvel at how few
    people complain about its Python indentation. (I'd like to think it's
    because anyone who edits Python code in SciTE has downloaded my patch,
    but I am confident that is not the case.)

    John
    John Yeung, May 27, 2009
    #2
    1. Advertising

  3. Mel

    Stef Mientki Guest

    John Yeung wrote:
    > On May 26, 9:43 am, Mel <> wrote:
    >
    >
    >> SciTE
    >> I like one big uncomplicated window, tabbed file panes,
    >> syntax coloring and help with indentation. There's
    >> nothing to it I hate. It would be nice if
    >> customization were easier.
    >>

    >
    > This is a decent summary of SciTE, but I kind of marvel at how few
    > people complain about its Python indentation. (I'd like to think it's
    > because anyone who edits Python code in SciTE has downloaded my patch,
    > but I am confident that is not the case.)
    >

    What's not correct about the Python indentation ?
    Where can we find the patch ?

    cheers,
    Stef
    > John
    >
    Stef Mientki, May 27, 2009
    #3
  4. Mel

    John Yeung Guest

    On May 27, 2:09 pm, Stef Mientki <> wrote:

    > John Yeung wrote:
    >
    > > I kind of marvel at how few people complain about [SciTE's]
    > > Python indentation.  (I'd like to think it's because anyone
    > > who edits Python code in SciTE has downloaded my patch, but
    > > I am confident that is not the case.)

    >
    > What's not correct about the Python indentation ?
    > Where can we find the patch ?


    If you have used SciTE for Python and haven't been frustrated by the
    autoindentation, then I don't think there is much reason for you to
    bother with a patch. By autoindentation, I mean automatically adding
    a level when a new block starts, not merely maintaining indentation
    level (which virtually every editor does, and some even call this
    their "autoindentation" feature).

    The problem with SciTE's autoindentation for Python is that you can
    only choose from the following three behaviors:

    1. Add a level if you press Enter on a line containing a "live" colon
    (that is, one that's not in a string or comment). [Try not to use
    slices except on the same line as a block-initiating 'for', 'if',
    etc.]

    2. Add a level if you press Enter on a line containing selected
    keywords like 'if', 'for', 'while', 'def', etc. [Avoid list
    comprehensions and generator expressions. You can do everything with
    map, filter, and lambda, right?]

    3. Don't autoindent at all (maintain the current indentation only).

    It boggles the mind that there is no way to tell SciTE "only pay
    attention to the colon if it's at the end of the line" other than by
    modifying the source code, but there you have it. (It's not like
    choice 3 is actually that bad. I imagine that is what SciTE's author
    uses for Python.)

    My patch (which also fixes a couple of other indentation-related
    things that were driving me crazy) is here:

    http://groups.google.com/group/scite-interest/files

    in the file called Python_AutoIndent.cxx.

    John
    John Yeung, May 28, 2009
    #4
  5. Mel

    Chris Jones Guest

    I'm unsure about a python editor for everyone but since acquiring habits
    takes time, I'm in favor of sticking to one editor for everything.

    CJ
    Chris Jones, May 28, 2009
    #5
  6. On Wed, 27 May 2009 22:34:45 -0400, Chris Jones wrote:

    > I'm unsure about a python editor for everyone but since acquiring habits
    > takes time, I'm in favor of sticking to one editor for everything.


    Or use an editor which follows user interface standards, rather than
    invents its own conventions for everything. That way you can trivially
    swap from one compliant application to another compliant application.

    A good UI standard should mean that:

    * common tasks should use the same interface in any application that
    supports that task;

    * all functionality should be discoverable without reading the manual;

    * the most common functions should be _trivially_ discoverable;

    * don't penalise the user for mistakes: as few actions as possible should
    be irreversible, and those which are irreversible should _effectively_
    warn the user that they are irreversible;

    * simple interfaces are better than complicated interfaces (easy tasks
    should be easy to perform);

    * but dumbing-down is not the same as simplifying (complicated tasks
    should be possible);

    * if possible, all functionality should be capable of being performed by
    either the mouse or keyboard.


    --
    Steven
    Steven D'Aprano, May 28, 2009
    #6
  7. In message <0039e83c$0$9673$>, Steven D'Aprano
    wrote:

    > A good UI standard should mean that:
    >
    > * all functionality should be discoverable without reading the manual;


    Which means no scripting languages are allowed?
    Lawrence D'Oliveiro, May 28, 2009
    #7
  8. Mel

    Chris Jones Guest

    On Thu, May 28, 2009 at 12:06:25AM EDT, Steven D'Aprano wrote:
    > On Wed, 27 May 2009 22:34:45 -0400, Chris Jones wrote:


    > > I'm unsure about a python editor for everyone but since acquiring
    > > habits takes time, I'm in favor of sticking to one editor for
    > > everything.

    >
    > Or use an editor which follows user interface standards, rather than
    > invents its own conventions for everything. That way you can trivially
    > swap from one compliant application to another compliant application.
    >
    > A good UI standard should mean that:
    >
    > * common tasks should use the same interface in any application that
    > supports that task;
    >
    > * all functionality should be discoverable without reading the manual;
    >
    > * the most common functions should be _trivially_ discoverable;
    >
    > * don't penalise the user for mistakes: as few actions as possible
    > should be irreversible, and those which are irreversible should
    > _effectively_ warn the user that they are irreversible;
    >
    > * simple interfaces are better than complicated interfaces (easy tasks
    > should be easy to perform);
    >
    > * but dumbing-down is not the same as simplifying (complicated tasks
    > should be possible);
    >
    > * if possible, all functionality should be capable of being performed
    > by either the mouse or keyboard.


    All valid points on the face of it, but doesn't the above rule out both
    vim and emacs?

    CJ
    Chris Jones, May 28, 2009
    #8
  9. Mel

    Paul Rudin Guest

    Steven D'Aprano <> writes:


    > * if possible, all functionality should be capable of being performed by
    > either the mouse or keyboard.


    I'd imagine that the requirement that *all* functionality can be
    performed with the mouse rules out many text editors. Almost the
    defining feature of a text editor is the ability to type text... which
    mostly happens with a keyboard.
    Paul Rudin, May 28, 2009
    #9
  10. On Thu, 28 May 2009 05:44:07 -0400, Chris Jones wrote:

    >> * if possible, all functionality should be capable of being performed
    >> by either the mouse or keyboard.

    >
    > All valid points on the face of it, but doesn't the above rule out both
    > vim and emacs?



    Your point is?


    *ducks and runs*


    --
    Steven
    Steven D'Aprano, May 28, 2009
    #10
  11. On Thu, 28 May 2009 11:08:08 +0100, Paul Rudin wrote:

    > Steven D'Aprano <> writes:
    >
    >
    >> * if possible, all functionality should be capable of being performed
    >> by either the mouse or keyboard.

    >
    > I'd imagine that the requirement that *all* functionality can be
    > performed with the mouse rules out many text editors. Almost the
    > defining feature of a text editor is the ability to type text... which
    > mostly happens with a keyboard.


    Likewise graphics editors -- it's difficult if not impossible to edit an
    image pixel by pixel using the keyboard. Hence the "if possible".

    (Aside: It's really discouraging that, even on a technical newsgroup
    where most of the people are relatively intelligent, the provisos and
    qualifications I give seem to be ignored in favour of an unrealistically
    extreme interpretation.)

    I do recall once in the mid 1980s, using a Macintosh with a broken
    keyboard. I was actually able to get useful work done by clicking letters
    on a virtual keyboard (the "Keyboard" desk accessory for those who
    remember it) and copying and pasting the text into the editor.



    --
    Steven
    Steven D'Aprano, May 28, 2009
    #11
  12. On Thu, 28 May 2009 20:58:07 +1200, Lawrence D'Oliveiro wrote:

    > In message <0039e83c$0$9673$>, Steven D'Aprano
    > wrote:
    >
    >> A good UI standard should mean that:
    >>
    >> * all functionality should be discoverable without reading the manual;

    >
    > Which means no scripting languages are allowed?


    "Should", not "must".

    In any case, once you've scripted some particular piece of functionality,
    the application should allow you to discover the existence of that
    script. Does the application have a "Scripts" or "Plugins" menu (or
    equivalent)? Or do you have to rummage around in the file system, looking
    for secret scripts in undocumented locations?


    --
    Steven
    Steven D'Aprano, May 28, 2009
    #12
  13. Mel

    Chris Jones Guest

    On Thu, May 28, 2009 at 07:38:33AM EDT, Steven D'Aprano wrote:

    > Your point is?


    notepad, otoh..

    > *ducks and runs*


    ... likewise.
    Chris Jones, May 28, 2009
    #13
  14. In message <003a5518$0$9673$>, Steven D'Aprano
    wrote:

    > On Thu, 28 May 2009 20:58:07 +1200, Lawrence D'Oliveiro wrote:
    >
    >> In message <0039e83c$0$9673$>, Steven D'Aprano
    >> wrote:
    >>
    >>> A good UI standard should mean that:
    >>>
    >>> * all functionality should be discoverable without reading the manual;

    >>
    >> Which means no scripting languages are allowed?

    >
    > "Should", not "must".


    If you meant "may or may not", why don't you say "may or may not"?
    Lawrence D'Oliveiro, May 28, 2009
    #14
  15. On Fri, 29 May 2009 09:04:39 +1200, Lawrence D'Oliveiro wrote:

    > In message <003a5518$0$9673$>, Steven D'Aprano
    > wrote:
    >
    >> On Thu, 28 May 2009 20:58:07 +1200, Lawrence D'Oliveiro wrote:
    >>
    >>> In message <0039e83c$0$9673$>, Steven
    >>> D'Aprano wrote:
    >>>
    >>>> A good UI standard should mean that:
    >>>>
    >>>> * all functionality should be discoverable without reading the
    >>>> manual;
    >>>
    >>> Which means no scripting languages are allowed?

    >>
    >> "Should", not "must".

    >
    > If you meant "may or may not", why don't you say "may or may not"?



    Are you a native English speaker? "Should" does not mean "may or may
    not". There is an enormous difference in meaning between e.g. "I should
    feed the dog" and "I may or may not feed the dog". The first case means
    that you have a need to feed the dog, but you are not obliged to, while
    the second case means you are indifferent to whether or not you will feed
    the dog.

    (Strictly speaking, "may or may not" is redundant, although often used to
    emphasise the indifference. If you may do something, then by definition
    you also may not do it.)

    The distinction between "may", "should" and "must" is also very common in
    RFCs. As a tech, I would have expected you to have been aware of that.
    For example, picking one at random, RFC 1866 (literally the first one I
    looked up!):

    may
    A document or user interface is conforming whether this
    statement applies or not.

    must
    Documents or user agents in conflict with this statement
    are not conforming.

    should
    If a document or user agent conflicts with this
    statement, undesirable results may occur in practice
    even though it conforms to this specification.

    http://www.faqs.org/rfcs/rfc1866.html

    To put it another way: "may" is optional, "should" is recommended, and
    "must" is compulsory.



    --
    Steven
    Steven D'Aprano, May 29, 2009
    #15
  16. In message <003af57e$0$9673$>, Steven D'Aprano
    wrote:

    > On Fri, 29 May 2009 09:04:39 +1200, Lawrence D'Oliveiro wrote:
    >
    >> In message <003a5518$0$9673$>, Steven D'Aprano
    >> wrote:
    >>
    >>> On Thu, 28 May 2009 20:58:07 +1200, Lawrence D'Oliveiro wrote:
    >>>
    >>>> In message <0039e83c$0$9673$>, Steven
    >>>> D'Aprano wrote:
    >>>>
    >>>>> A good UI standard should mean that:
    >>>>>
    >>>>> * all functionality should be discoverable without reading the
    >>>>> manual;
    >>>>
    >>>> Which means no scripting languages are allowed?
    >>>
    >>> "Should", not "must".

    >>
    >> If you meant "may or may not", why don't you say "may or may not"?

    >
    > "Should" does not mean "may or may not".


    I'm not sure how there is supposed to be a difference in this context. "All
    people should fly by flapping their arms, except where this is physically
    impossible". You're asking for something that is infeasible with most
    current editors, if not all of them.
    Lawrence D'Oliveiro, May 29, 2009
    #16
  17. On Fri, 29 May 2009 14:00:19 +1200, Lawrence D'Oliveiro wrote:

    > In message <003af57e$0$9673$>, Steven D'Aprano
    > wrote:
    >
    >> On Fri, 29 May 2009 09:04:39 +1200, Lawrence D'Oliveiro wrote:
    >>
    >>> In message <003a5518$0$9673$>, Steven
    >>> D'Aprano wrote:
    >>>
    >>>> On Thu, 28 May 2009 20:58:07 +1200, Lawrence D'Oliveiro wrote:
    >>>>
    >>>>> In message <0039e83c$0$9673$>, Steven
    >>>>> D'Aprano wrote:
    >>>>>
    >>>>>> A good UI standard should mean that:
    >>>>>>
    >>>>>> * all functionality should be discoverable without reading the
    >>>>>> manual;
    >>>>>
    >>>>> Which means no scripting languages are allowed?
    >>>>
    >>>> "Should", not "must".
    >>>
    >>> If you meant "may or may not", why don't you say "may or may not"?

    >>
    >> "Should" does not mean "may or may not".

    >
    > I'm not sure how there is supposed to be a difference in this context.
    > "All people should fly by flapping their arms, except where this is
    > physically impossible". You're asking for something that is infeasible
    > with most current editors, if not all of them.



    On the remote chance that you're not trolling, I deny that
    discoverablity is "infeasible", for editors or other applications. Making
    a UI discoverable is not a hard problem that is difficult to solve.
    Discoverablity isn't radical new concept in UI design, it has been
    around since the 1970s, at least.

    The concept is simple: e.g. in the editor I'm using to compose this
    message, I have a toolbar which includes a button "Wrap Text". That's
    discoverable, because even if I didn't know the command existed, I could
    discover it by looking at the toolbar. There's a keyboard command to do
    the same thing: Alt-E-W. Without reading the manual, I'm unlikely to
    discover that command.

    Here's a couple of screenshots of Wordstar:

    http://www.kantl.be/ctb/vanhoutte/teach/slides/graphics/wstar.gif
    http://www.iee.et.tu-dresden.de/~kc-club/08/PCX/WORDSTAR.GIF

    Wordstar's commands are discoverable, because they are listed in a menu
    you can choose from. Wordstar dates back to 1978, so this isn't precisely
    the cutting edge of UI design.

    As a general rule, menus are discoverable, while keyboard commands
    aren't. There's nothing inherent to text editing functions which makes
    then inherently undiscoverable, and KDE apps like kate and kwrite do a
    reasonable job of making them so.



    --
    Steven
    Steven D'Aprano, May 29, 2009
    #17
  18. In message <003b3d8c$0$9673$>, Steven D'Aprano
    wrote:

    > On Fri, 29 May 2009 14:00:19 +1200, Lawrence D'Oliveiro wrote:
    >
    >> In message <003af57e$0$9673$>, Steven D'Aprano
    >> wrote:
    >>
    >>> On Fri, 29 May 2009 09:04:39 +1200, Lawrence D'Oliveiro wrote:
    >>>
    >>>> In message <003a5518$0$9673$>, Steven
    >>>> D'Aprano wrote:
    >>>>
    >>>>> On Thu, 28 May 2009 20:58:07 +1200, Lawrence D'Oliveiro wrote:
    >>>>>
    >>>>>> In message <0039e83c$0$9673$>, Steven
    >>>>>> D'Aprano wrote:
    >>>>>>
    >>>>>>> A good UI standard should mean that:
    >>>>>>>
    >>>>>>> * all functionality should be discoverable without reading the
    >>>>>>> manual;
    >>>>>>
    >>>>>> Which means no scripting languages are allowed?
    >>>>>
    >>>>> "Should", not "must".
    >>>>
    >>>> If you meant "may or may not", why don't you say "may or may not"?
    >>>
    >>> "Should" does not mean "may or may not".

    >>
    >> I'm not sure how there is supposed to be a difference in this context.
    >> "All people should fly by flapping their arms, except where this is
    >> physically impossible". You're asking for something that is infeasible
    >> with most current editors, if not all of them.

    >
    > On the remote chance that you're not trolling, I deny that
    > discoverablity is "infeasible" ...


    On the remote chance you're not trolling, let me point out politely that it
    is for scriptability.
    Lawrence D'Oliveiro, May 29, 2009
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stylus Studio
    Replies:
    0
    Views:
    633
    Stylus Studio
    Aug 3, 2004
  2. Matt McCredie
    Replies:
    6
    Views:
    378
    Fuzzyman
    Sep 20, 2007
  3. J Kenneth King
    Replies:
    41
    Views:
    867
    JussiJ
    Jun 18, 2009
  4. Steven D'Aprano
    Replies:
    4
    Views:
    881
  5. Lawrence D'Oliveiro

    Re: What text editor is everyone using for Python

    Lawrence D'Oliveiro, May 26, 2009, in forum: Python
    Replies:
    18
    Views:
    356
Loading...

Share This Page