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


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

Important features for editors

Started bycutems93 <ms2597@cornell.edu>
First post2013-07-04 00:32 -0700
Last post2013-07-08 13:03 -0500
Articles 20 on this page of 47 — 28 participants

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


Contents

  Important features for editors cutems93 <ms2597@cornell.edu> - 2013-07-04 00:32 -0700
    Re: Important features for editors Νίκος <nikos@superhost.gr> - 2013-07-04 10:59 +0300
      Re: Important features for editors Dave Angel <davea@davea.name> - 2013-07-04 04:34 -0400
        Re: Important features for editors Νίκος <nikos@superhost.gr> - 2013-07-04 12:14 +0300
          Re: Important features for editors Chris Angelico <rosuav@gmail.com> - 2013-07-04 20:03 +1000
          Re: Important features for editors Robert Kern <robert.kern@gmail.com> - 2013-07-04 12:01 +0100
            Re: Important features for editors Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-04 15:48 +0000
          Re: Important features for editors Steve Simmons <square.steve@gmail.com> - 2013-07-04 14:33 +0100
            Re: Important features for editors Νίκος Γκρ33κ <nikos@superhost.gr> - 2013-07-04 16:36 +0300
              Re: Important features for editors feedthetroll@gmx.de - 2013-07-04 07:03 -0700
            Re: Important features for editors rusi <rustompmody@gmail.com> - 2013-07-04 07:02 -0700
              Re: Important features for editors Steve Simmons <square.steve@gmail.com> - 2013-07-04 16:35 +0100
              Re: Important features for editors Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-04 15:46 +0000
          Re: Important features for editors Grant Edwards <invalid@invalid.invalid> - 2013-07-04 18:40 +0000
            Re: Important features for editors Ferrous Cranus <nikos@superhost.gr> - 2013-07-04 21:52 +0300
              Re: Important features for editors Chris Angelico <rosuav@gmail.com> - 2013-07-05 07:59 +1000
              Re: Important features for editors Jason Swails <jason.swails@gmail.com> - 2013-07-04 17:59 -0400
              Re: Important features for editors Terry Reedy <tjreedy@udel.edu> - 2013-07-05 03:25 -0400
              Re: Important features for editors Grant Edwards <invalid@invalid.invalid> - 2013-07-05 14:11 +0000
      Re: Important features for editors Νίκος Gr33k <nikos@superhost.gr> - 2013-07-05 10:41 +0300
        Re: Important features for editors feedthetroll@gmx.de - 2013-07-05 01:28 -0700
    Re: Important features for editors Dave Angel <davea@davea.name> - 2013-07-04 05:02 -0400
    Re: Important features for editors Tim Chase <python.list@tim.thechases.com> - 2013-07-04 08:22 -0500
    Re: Important features for editors MRAB <python@mrabarnett.plus.com> - 2013-07-04 15:24 +0100
      Re: Important features for editors rurpy@yahoo.com - 2013-07-04 08:56 -0700
        Re: Important features for editors Steve Simmons <square.steve@gmail.com> - 2013-07-04 17:14 +0100
    Re: Important features for editors William Ray Wing <wrw@mac.com> - 2013-07-04 09:42 -0400
    Re: Important features for editors Tim Chase <python.list@tim.thechases.com> - 2013-07-04 16:03 -0500
    Re: Important features for editors Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-05 01:38 +0100
      Re: Important features for editors Roy Smith <roy@panix.com> - 2013-07-04 21:50 -0400
        Re: Important features for editors Cameron Simpson <cs@zip.com.au> - 2013-07-05 12:59 +1000
    Re: Important features for editors Dave Angel <davea@davea.name> - 2013-07-04 21:15 -0400
    Fwd: Important features for editors Göktuğ Kayaalp <goktug.kayaalp@gmail.com> - 2013-07-04 11:07 +0300
      Re: Important features for editors rusi <rustompmody@gmail.com> - 2013-07-05 05:12 -0700
        Re: Important features for editors Cameron Simpson <cs@zip.com.au> - 2013-07-06 09:06 +1000
        Re: Important features for editors Rustom Mody <rustompmody@gmail.com> - 2013-07-06 08:43 +0530
          Re: Important features for editors Roy Smith <roy@panix.com> - 2013-07-05 23:25 -0400
            Re: Important features for editors Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-06 05:35 +0100
              Re: Important features for editors rusi <rustompmody@gmail.com> - 2013-07-05 22:19 -0700
                Re: Important features for editors Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-06 07:19 +0100
        Re: Important features for editors Rustom Mody <rustompmody@gmail.com> - 2013-07-06 13:39 +0530
        Re: Important features for editors "Eric S. Johansson" <esj@harvee.org> - 2013-07-06 02:52 -0400
    Re: Important features for editors jussij@zeusedit.com - 2013-07-07 23:16 -0700
      Re: Important features for editors Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-08 06:37 +0000
        Re: Important features for editors Skip Montanaro <skip@pobox.com> - 2013-07-08 05:21 -0500
        Re: Important features for editors Sivaram Neelakantan <nsivaram.net@gmail.com> - 2013-07-08 19:54 +0530
        Re: Important features for editors Skip Montanaro <skip@pobox.com> - 2013-07-08 13:03 -0500

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


#49947

Fromfeedthetroll@gmx.de
Date2013-07-05 01:28 -0700
Message-ID<41c74174-3337-4793-819a-05368de4e363@googlegroups.com>
In reply to#49941
Am Donnerstag, 4. Juli 2013 11:14:38 UTC+2 schrieb Νίκος Gr33k:
> ...
>> On 07/04/2013 03:59 AM, Νίκος wrote:
>>> ... 
>>> Download Sublime Text v3
>>> Is a great editor
>>> ... 
>
> If you guys want to use it i can send you a patch for it.
> I know its illegal thing to say but it will help you use it without 
> buying it.

Am Freitag, 5. Juli 2013 09:41:39 UTC+2 schrieb Νίκος Gr33k:
> [talkin about Sublime Text editor]
> The only thing missing from this great editor is the ability to upload 
> your python scripts to a remote web server.
> They should embed a plugin  for that like Notepad's NPPFtp plugin.

Oh, I'm sure they would have time/money to do so, if more people payed the license fees.

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


#49829

FromDave Angel <davea@davea.name>
Date2013-07-04 05:02 -0400
Message-ID<mailman.4213.1372928582.3114.python-list@python.org>
In reply to#49821
On 07/04/2013 03:32 AM, cutems93 wrote:
> I am researching on editors for my own reference. I found that each of them has some features that other don't, but I am not sure which features are significant/necessary for a GOOD editor. What features do you a good editor should have? Keyboard shortcuts? Extensions?
>

Not sure what you mean by keyboard shortcuts.  If you mean there should 
be a keyboard version of anything that can be done with the mouse, 
absolutely.

There are hundreds of features that could be listed, and only you can 
decide which ones are important.  I'll try to list a few that are 
important to me, and some more that would sure be nice.

Very important:
--------------

It runs on every platform I'm using.  It's extremely fast, when run 
locally, and reasonable over a slow internet connection.

Licensing is free, or very inexpensive

It opens and edits files of fairly arbitrary size (at least 10 MB)

It has a large number of potential buffers, for editing multiple files 
at the same time.

It can readily be customized, on a per-language basis, so that it can 
easily handle the quirks of each language.  And it switches between them 
based on file name, without explicitly setting some mode.  However, if 
the filename is unconventional, it allows the buffer to be explicitly 
set to a particular language, not affecting other files that are 
simultaneously open.

It comes pre-customized for the languages I'm likely to use now.  That 
includes pseudo languages like html, xml, css, not just "programming 
languages."

It supports my own strange preferences for tab-handling, or at least can 
be customized to do so.

It recognizes immediately when a file has been changed on disk, and 
gives me reasonable ways to merge my current edits into what's now in 
the disk file.

It doesn't force me to accept .bak or other funny files;  that's what 
dvcs systems are for.  It CAN create such files while a file is being 
edited, they just shouldn't persist after the editor is normally closed.

If it has project files, they should be out of band, not mixed in with 
source files I'm editing.

Nice to have:
------------

It has visible spaces (and tabs, and other funny white-space characters)

It can be run in an ssh session, remotely, over a satellite internet 
connection and vpn.

Customization language is one I'm comfortable with.  Not VBA or javascript.

Mandatory for Python use:
------------------------

It understands indenting, and lets you easily get to the various columns 
that are legal at any point.  This means it recognizes if statements and 
suchlike, and indents (4) spaces for the following line.  And when you 
want to unindent, you don't have to use 4 backspaces, but just press the 
tab again.

Nice for Python use:
-------------------

Syntax coloring.

Re-indenting a group of lines by plus-or-minus 4 columns.



Now, you may be asking about an IDE.  And that's a whole other kettle of 
fish.  Context-sensitive auto-completion, jump to definition, 
refactoring support, data breakpoints, ...


Candidates?
    emacs  - standard on most OS's, available for Windows from various 
websites
    Komodo Edit    free
           http://www.activestate.com/komodo-edit
    Komodo IDE   not free
       http://www.activestate.com/komodo-ide


-- 
DaveA

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


#49856

FromTim Chase <python.list@tim.thechases.com>
Date2013-07-04 08:22 -0500
Message-ID<mailman.4226.1372944053.3114.python-list@python.org>
In reply to#49821
On 2013-07-04 05:02, Dave Angel wrote:
[snip an excellent list of things to look for in an editor]

Also, 

- the ability to perform changes in bulk, especially across files.
  Often, this is done with the ability to record/playback macros,
  though some editors have multiple insertion/edit cursors; others
  allow for performing a bulk-change command across the entire file
  or list of files.

- folding (the ability to collapse multiple lines of text down to one
  line).  Especially if there are various ways to do it (manual
  folding, language-block folding, folding by indentation)

- multiple clipboard buffers/registers

- multiple bookmarks

- the ability to interact with external programs (piping a portion of
  a file through an external utility)

- a good community around it in case you have questions

- easy navigation to "important" things in your file (where
  "important" may vary based on file-type, but may include function
  definitions, paragraph boundaries, matching
  paren/bracket/brace/tag, etc)

Other nice-to-haves include

- split window editing
- tabbed windows
- Unicode support (including various encodings)
- vimgolf.com ;-)

> Candidates?
>     emacs  - standard on most OS's, available for Windows from

And I'll put in a plug for Vim.

-tkc






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


#49868

FromMRAB <python@mrabarnett.plus.com>
Date2013-07-04 15:24 +0100
Message-ID<mailman.4233.1372947855.3114.python-list@python.org>
In reply to#49821
On 04/07/2013 14:22, Tim Chase wrote:
> On 2013-07-04 05:02, Dave Angel wrote:
> [snip an excellent list of things to look for in an editor]
>
> Also,
>
> - the ability to perform changes in bulk, especially across files.
>    Often, this is done with the ability to record/playback macros,
>    though some editors have multiple insertion/edit cursors; others
>    allow for performing a bulk-change command across the entire file
>    or list of files.
>
> - folding (the ability to collapse multiple lines of text down to one
>    line).  Especially if there are various ways to do it (manual
>    folding, language-block folding, folding by indentation)
>
> - multiple clipboard buffers/registers
>
> - multiple bookmarks
>
> - the ability to interact with external programs (piping a portion of
>    a file through an external utility)
>
> - a good community around it in case you have questions
>
> - easy navigation to "important" things in your file (where
>    "important" may vary based on file-type, but may include function
>    definitions, paragraph boundaries, matching
>    paren/bracket/brace/tag, etc)
>
> Other nice-to-haves include
>
> - split window editing
> - tabbed windows
> - Unicode support (including various encodings)

It's 2013, yet Unicode support is merely a "nice-to-have"?

> - vimgolf.com ;-)
>
>> Candidates?
>>     emacs  - standard on most OS's, available for Windows from
>
> And I'll put in a plug for Vim.
>

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


#49882

Fromrurpy@yahoo.com
Date2013-07-04 08:56 -0700
Message-ID<fdfedeb8-805f-40ab-bfb1-eb7f0869616b@googlegroups.com>
In reply to#49868
On 07/04/2013 08:24 AM, MRAB wrote:
> On 04/07/2013 14:22, Tim Chase wrote:
>> On 2013-07-04 05:02, Dave Angel wrote:
>> [snip an excellent list of things to look for in an editor]

> It's 2013, yet Unicode support is merely a "nice-to-have"?
 
I agree that this is pretty important.  Even if you don't
have to deal with Unicode today, the chances are good that 
you will need to, if only in an occasional way, in the 
future.

One thing not mentioned (sorry if I missed it) that I
use more than many of the features that have been mentioned
is some form of advanced search/replace.  I.e. something
that can do regular expression searches and replaces 
including multiline ones.

Another feature I find necessary is very fast start up time
since I open an editor hundreds of times a day.

Because advanced features and fast startup seem to be mutually
exclusive, I often use two editors, a simple but quick starting
one like Gedit on Linux or Notepad on Windows for 90% of 
routine editing and Emacs for the the other 10% when I need 
to do something more powerful.  But as a disclaimer I should 
add that I do not spend 8+ hours a day doing nothing but 
programming so YMMV.

BTW, the group is currently having a problem both with
trolls and with regulars here that bite at every baited 
hook that drifts past their screen.  There seems to nothing
to be done other than ignore the obnoxious posts but I am
sorry they have infiltrated your discussion.  Hopefully
this comment won't add to the problem.

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


#49884

FromSteve Simmons <square.steve@gmail.com>
Date2013-07-04 17:14 +0100
Message-ID<mailman.4242.1372954477.3114.python-list@python.org>
In reply to#49882

[Multipart message — attachments visible in raw view] — view raw

To Rurpy and cutems93,

My apologies too.  I reacted before I thought about creating a new thread.

To your question:  One thing that I don't use daily but find very useful to
have in an editor is  'Hex View' (or better yet a 'Hex Editor').

Whilst it has been 'dissed' recently on this list, I like Notepad++ for
everyday editing but if I'm head-down in a particular language, I prefer to
be in an IDE.

Steve


On Thu, Jul 4, 2013 at 4:56 PM, <rurpy@yahoo.com> wrote:

> On 07/04/2013 08:24 AM, MRAB wrote:
> > On 04/07/2013 14:22, Tim Chase wrote:
> >> On 2013-07-04 05:02, Dave Angel wrote:
> >> [snip an excellent list of things to look for in an editor]
>
> > It's 2013, yet Unicode support is merely a "nice-to-have"?
>
> I agree that this is pretty important.  Even if you don't
> have to deal with Unicode today, the chances are good that
> you will need to, if only in an occasional way, in the
> future.
>
> One thing not mentioned (sorry if I missed it) that I
> use more than many of the features that have been mentioned
> is some form of advanced search/replace.  I.e. something
> that can do regular expression searches and replaces
> including multiline ones.
>
> Another feature I find necessary is very fast start up time
> since I open an editor hundreds of times a day.
>
> Because advanced features and fast startup seem to be mutually
> exclusive, I often use two editors, a simple but quick starting
> one like Gedit on Linux or Notepad on Windows for 90% of
> routine editing and Emacs for the the other 10% when I need
> to do something more powerful.  But as a disclaimer I should
> add that I do not spend 8+ hours a day doing nothing but
> programming so YMMV.
>
> BTW, the group is currently having a problem both with
> trolls and with regulars here that bite at every baited
> hook that drifts past their screen.  There seems to nothing
> to be done other than ignore the obnoxious posts but I am
> sorry they have infiltrated your discussion.  Hopefully
> this comment won't add to the problem.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

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


#49869

FromWilliam Ray Wing <wrw@mac.com>
Date2013-07-04 09:42 -0400
Message-ID<mailman.4234.1372948956.3114.python-list@python.org>
In reply to#49821
On Jul 4, 2013, at 9:22 AM, Tim Chase <python.list@tim.thechases.com> wrote:

> On 2013-07-04 05:02, Dave Angel wrote:
> [snip an excellent list of things to look for in an editor]
> 
> Also, 
> 
> - the ability to perform changes in bulk, especially across files.
>  Often, this is done with the ability to record/playback macros,
>  though some editors have multiple insertion/edit cursors; others
>  allow for performing a bulk-change command across the entire file
>  or list of files.
> 

To Tim's and Dave's excellent lists let me add one more feature that I find useful:
  the ability to bulk-search through all files in a folder/directory/project for a word
  or phrase, display the hits and then selectively or optionally do a replace on each
  hit in the displayed list.  In effect, this is an interactive extension of the bulk
  search and replace Tim lists above. 


> - folding (the ability to collapse multiple lines of text down to one
>  line).  Especially if there are various ways to do it (manual
>  folding, language-block folding, folding by indentation)

Yes, yes, yes.  It may simply be a reflection of my poor programming style (grow
  by accretion, wait way too long to refactor), but this is a big help in following
  program logic.

> 
> - multiple clipboard buffers/registers
> 
> - multiple bookmarks
> 
> - the ability to interact with external programs (piping a portion of
>  a file through an external utility)
> 

And in particular, the ability to preview a chunk of html in a browser.

> - a good community around it in case you have questions
> 
> - easy navigation to "important" things in your file (where
>  "important" may vary based on file-type, but may include function
>  definitions, paragraph boundaries, matching
>  paren/bracket/brace/tag, etc)
> 
> Other nice-to-haves include
> 
> - split window editing
> - tabbed windows
> - Unicode support (including various encodings)
> - vimgolf.com ;-)
> 
>> Candidates?
>>    emacs  - standard on most OS's, available for Windows from
> 
> And I'll put in a plug for Vim.
> 
> -tkc
> 
> 
> 
> 
> 
> 
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list

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


#49902

FromTim Chase <python.list@tim.thechases.com>
Date2013-07-04 16:03 -0500
Message-ID<mailman.4250.1372971701.3114.python-list@python.org>
In reply to#49821
On 2013-07-04 15:24, MRAB wrote:
> On 04/07/2013 14:22, Tim Chase wrote:
> > Other nice-to-haves include
> >
> > - Unicode support (including various encodings)
> 
> It's 2013, yet Unicode support is merely a "nice-to-have"?

Yeah, while I use Vim and it's got support, most of what I do
interacts with unicode stuff as escaped rather than in-line.  In
python, it's things like u"\u20AC" or in HTML/XML using one of the
escaping variants:  &#8364; or &#x20ac; or even &euro;

So I don't feel particularly hampered even if/when I get stuck with
an editor that only speaks lower-ASCII.

That's why I considered it merely "nice to have" rather than
"essential".

-tkc



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


#49911

FromJoshua Landau <joshua.landau.ws@gmail.com>
Date2013-07-05 01:38 +0100
Message-ID<mailman.4258.1372984732.3114.python-list@python.org>
In reply to#49821
On 4 July 2013 08:32, cutems93 <ms2597@cornell.edu> wrote:
> I am researching on editors for my own reference. I found that each of them has some features that other don't, but I am not sure which features are significant/necessary for a GOOD editor. What features do you a good editor should have? Keyboard shortcuts? Extensions?

Let me give you some reasons I really, really like Sublime Text.

* Fast. Like, really fast. I've used Vim -- Sublime Text is faster.
Considering I'm on a middle-end 5-year-old computer (not for long...)
this matters.

* The rendering is gorgeous. There are subtle shadows, there's
perfectly crisp text (the main reason I no longer use terminal
editors, actually), and once you choose the right theme (Nexus and
Phoenix, Tomorrow Night for me) it's just lovely. There's this feature
where it shows you tabs -- but only for the part of the file you're
on. There's, instead of a scrollbar, a little "bird's-eye-view" of the
whole code on the RHS. This goes on. Visually it is stunning, in a
helpful way. If it had proper terminal-emulation support, I'd replace
my terminal with it. It's just that usable an interface.

* Multiple cursors. This is something that no-one else really
advertises, but it's one of the most used features for me. It's
something you just have to try for a while -- I think it's a bit like
Vim's power-of-Regex but easy for a, you know, human. (I just found
https://github.com/terryma/vim-multiple-cursors).

* Good navigation between and inside of files. A lot of things have
this, so I won't say much more.

* The "Command Palette" is a dropdown that you do commands from, and
because of the way you search it, it's like a hybrid between vim's
command-based power and something that's actually discoverable and
easy.

* Usable on *really big* files, and has one of the best binary-file
support I know of. I open binary file a little more than I should, not
that I can do much with them.

* Useful extensions, installable at a button-press --
<C-P>in<CR>[search for package]<CR>. Like SublimeREPL. I know
Emacs/Vim will do better at REPLs, but few others will.

* Etc. This goes on.

Looking at Dave Angel's list, Sublime Text pretty-much aces it.

What I don't understand is where he says:

> The main negatives I can see are:
...
>     It's available for OS/X, Linux and Windows, with a single purchase
>     The eval/demo is not time-limited (currently)

How on earth are those negatives?

He basically only dislikes it because you have to use PayPal, which is
his choice. I can't say I agree with it though.

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


#49919

FromRoy Smith <roy@panix.com>
Date2013-07-04 21:50 -0400
Message-ID<roy-F869F1.21503804072013@70-1-84-166.pools.spcsdns.net>
In reply to#49911
In article <mailman.4258.1372984732.3114.python-list@python.org>,
 Joshua Landau <joshua.landau.ws@gmail.com> wrote:

[talking about Sublime Text]
> There's, instead of a scrollbar, a little "bird's-eye-view" of the
> whole code on the RHS.

I've never used it myself, but there's a couple of guys in the office 
who do.  I have to admit, this feature looks pretty neat.

Does Sublime have some sort of remote mode?  We've got one guy who loves 
it, but needs to work on a remote machine (i.e. in AWS).  I got X11 
working for him (he has a Mac desktop), so he can run Sublime on the AWS 
Linux box and have it display on his Mac desktop, but that's less than 
ideal.

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


#49924

FromCameron Simpson <cs@zip.com.au>
Date2013-07-05 12:59 +1000
Message-ID<mailman.4267.1372998938.3114.python-list@python.org>
In reply to#49919
[ Digressing to tuning remote access. Sorry. - Cameron ]

On 04Jul2013 21:50, Roy Smith <roy@panix.com> wrote:
| Does Sublime have some sort of remote mode?  We've got one guy who loves 
| it, but needs to work on a remote machine (i.e. in AWS).  I got X11 
| working for him (he has a Mac desktop), so he can run Sublime on the AWS 
| Linux box and have it display on his Mac desktop, but that's less than 
| ideal.

It's worth pointing out that, depending on the app, X11 can do a
fair bit of traffic. Particularly with more recent things on "rich"
widget libraries with animation or drag'n'drop, it can be quite
painful because the app's developed on someones local desktop where
latency is negligible.

Sometimes it is worth running a desktop local to the remote machine
(eg using vncserver) and operating it remotely via a viewer (eg a
vnc viewer). Although you're now throwign screen updates around as
bitmaps of some flavour, this can decouple you from vile spinning
progress icons and modal drag'n'drop stuff. (This also insulates
you against network drops; just reconnect the viewer, just like
screen or tmux do for terminals.)

Seamonkey, for example, is like molasses done directly with X11 from
a remote host. It used to be snappy, but widget library bling creep
has made it an exercise in pain.

Another alternative, better still if easy, is to mount the remote
system's files on your local machine and run the editor locally.
Snappy response, your native widget-set/look'n'feel, and saving a
file is normally pretty cheap even remotely; that would normally
be your main remote transaction under this model.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

Ninety percent of everything is crud.   - Theodore Sturgeon

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


#49914

FromDave Angel <davea@davea.name>
Date2013-07-04 21:15 -0400
Message-ID<mailman.4260.1372986963.3114.python-list@python.org>
In reply to#49821
On 07/04/2013 08:38 PM, Joshua Landau wrote:
> On 4 July 2013 08:32, cutems93 <ms2597@cornell.edu> wrote:
>> I am researching on editors for my own reference. I found that each of them has some features that other don't, but I am not sure which features are significant/necessary for a GOOD editor. What features do you a good editor should have? Keyboard shortcuts? Extensions?
>
> Let me give you some reasons I really, really like Sublime Text.
>
> * Fast. Like, really fast. I've used Vim -- Sublime Text is faster.
> Considering I'm on a middle-end 5-year-old computer (not for long...)
> this matters.
>
> * The rendering is gorgeous. There are subtle shadows, there's
> perfectly crisp text (the main reason I no longer use terminal
> editors, actually), and once you choose the right theme (Nexus and
> Phoenix, Tomorrow Night for me) it's just lovely. There's this feature
> where it shows you tabs -- but only for the part of the file you're
> on. There's, instead of a scrollbar, a little "bird's-eye-view" of the
> whole code on the RHS. This goes on. Visually it is stunning, in a
> helpful way. If it had proper terminal-emulation support, I'd replace
> my terminal with it. It's just that usable an interface.
>
> * Multiple cursors. This is something that no-one else really
> advertises, but it's one of the most used features for me. It's
> something you just have to try for a while -- I think it's a bit like
> Vim's power-of-Regex but easy for a, you know, human. (I just found
> https://github.com/terryma/vim-multiple-cursors).
>
> * Good navigation between and inside of files. A lot of things have
> this, so I won't say much more.
>
> * The "Command Palette" is a dropdown that you do commands from, and
> because of the way you search it, it's like a hybrid between vim's
> command-based power and something that's actually discoverable and
> easy.
>
> * Usable on *really big* files, and has one of the best binary-file
> support I know of. I open binary file a little more than I should, not
> that I can do much with them.
>
> * Useful extensions, installable at a button-press --
> <C-P>in<CR>[search for package]<CR>. Like SublimeREPL. I know
> Emacs/Vim will do better at REPLs, but few others will.
>
> * Etc. This goes on.
>
> Looking at Dave Angel's list, Sublime Text pretty-much aces it.
>
> What I don't understand is where he says:
>
>> The main negatives I can see are:
> ...
>>      It's available for OS/X, Linux and Windows, with a single purchase
>>      The eval/demo is not time-limited (currently)
>
> How on earth are those negatives?
>

A typo.  I was collecting points and trying to put them in categories, 
but somehow that didn't end up in the right place.

> He basically only dislikes it because you have to use PayPal, which is
> his choice. I can't say I agree with it though.
>


-- 
DaveA

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


#49939

FromGöktuğ Kayaalp <goktug.kayaalp@gmail.com>
Date2013-07-04 11:07 +0300
Message-ID<mailman.4274.1373009673.3114.python-list@python.org>
In reply to#49821
Programmability comes to my mind, before anything else.  I'd suggest
to find out about designs of Emacs and Vi(m).

On Thu, Jul 4, 2013 at 10:32 AM, cutems93 <ms2597@cornell.edu> wrote:
> I am researching on editors for my own reference. I found that each of them has some features that other don't, but I am not sure which features are significant/necessary for a GOOD editor. What features do you a good editor should have? Keyboard shortcuts? Extensions?
>
> Thanks!
> Min
> --
> http://mail.python.org/mailman/listinfo/python-list

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


#49977

Fromrusi <rustompmody@gmail.com>
Date2013-07-05 05:12 -0700
Message-ID<081319f4-4d68-409e-81cb-1f500d5d87f0@googlegroups.com>
In reply to#49939
On Thursday, July 4, 2013 1:37:10 PM UTC+5:30, Göktuğ Kayaalp wrote:
> Programmability comes to my mind, before anything else.  I'd suggest
> to find out about designs of Emacs and Vi(m).

There's one reason I prefer emacs -- and I guess some people prefer Idle -- the interpreter and editor are tightly integrated.

This is not strictly in the class of editor-as-editor but editor as programming-in-the-tiny support.

That said it needs to be also remembered:
- needs some setup efforts for python
- key-bindings and terminology will seem weird to the younger generation

One expansion for EMACS is Editor for Middle Aged Computer Scientists -- so I am guessing if you're asking the question you dont qualify :-)

If you get past these initial hurdles and also the initial programming hurdles to get to the point where you have the AHA moment -- programming is like art/poetry, you may want to look at emacs -> org-mode -> babel
which is the state-of-art system for what is called 'literate programming'
http://orgmode.org/worg/org-contrib/babel/intro.html

[I am a medium-grade user of org-mode and completely noob at babel! ]

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


#50027

FromCameron Simpson <cs@zip.com.au>
Date2013-07-06 09:06 +1000
Message-ID<mailman.4316.1373065610.3114.python-list@python.org>
In reply to#49977
On 05Jul2013 05:12, rusi <rustompmody@gmail.com> wrote:
| On Thursday, July 4, 2013 1:37:10 PM UTC+5:30, Göktuğ Kayaalp wrote:
| > Programmability comes to my mind, before anything else.  I'd suggest
| > to find out about designs of Emacs and Vi(m).
| 
| There's one reason I prefer emacs -- and I guess some people
| prefer Idle -- the interpreter and editor are tightly integrated.

That is indeed a strength of emacs over vi.

For myself, I generally don't want to program my editor beyond writing
keyboard macros, and vim's programming interface has yet to attract me.

When I want to manipulate text beyond a simple macro I tend to write
a sed script. Or awk, or python in increasing complexity of task.

[...]
| One expansion for EMACS is Editor for Middle Aged Computer
| Scientists -- so I am guessing if you're asking the question you
| dont qualify :-)

While I started with vi just slightly before encountering emacs
(mid-to-late 1980s, both), my main trouble with choosing emacs was
the heavy use of control keys. Vi's modal nature means that in
"edit" mode, all the keystrokes are available as edit controls.
Emacs' modeless nature means that all the edit controls must be
control-this and meta/escape-that.

For this reason, I often expand EMACS as Escape Meta Alt Control Shift.

I'm a vi user. Once I mastered "hit ESC by reflex when you pause
typing an insert" I was never confused above which mode I was in.

And now my fingers know vi.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

A novice of the temple once approached the Chief Priest with a question.

  "Master, does Emacs have the Buddha nature?" the novice asked.

  The Chief Priest had been in the temple for many years and could be relied
  upon to know these things.  He thought for several minutes before replying.

  "I don't see why not.  It's got bloody well everything else."

  With that, the Chief Priest went to lunch.  The novice suddenly achieved
enlightenment, several years later.

Commentary:

        His Master is kind,
        Answering his FAQ quickly,
        With thought and sarcasm.

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


#50041

FromRustom Mody <rustompmody@gmail.com>
Date2013-07-06 08:43 +0530
Message-ID<mailman.4323.1373080433.3114.python-list@python.org>
In reply to#49977

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jul 6, 2013 at 4:36 AM, Cameron Simpson <cs@zip.com.au> wrote:

> While I started with vi just slightly before encountering emacs
> (mid-to-late 1980s, both), my main trouble with choosing emacs was
> the heavy use of control keys. Vi's modal nature means that in
> "edit" mode, all the keystrokes are available as edit controls.
> Emacs' modeless nature means that all the edit controls must be
> control-this and meta/escape-that.
>
> For this reason, I often expand EMACS as Escape Meta Alt Control Shift.
>
>
Yes...
The fact that rms has crippling RSI should indicate that emacs' ergonomics
is not right.


> I'm a vi user. Once I mastered "hit ESC by reflex when you pause
> typing an insert" I was never confused above which mode I was in.
>
> And now my fingers know vi.
>
>
Yes...
vi: (n) A program that has two modes, one in which it beeps and the other
in which it corrupts your file :-)


>  Cheers,
> --
> Cameron Simpson <cs@zip.com.au>
>
> A novice of the temple once approached the Chief Priest with a question.
>
>   "Master, does Emacs have the Buddha nature?" the novice asked.
>
>   The Chief Priest had been in the temple for many years and could be
> relied
>   upon to know these things.  He thought for several minutes before
> replying.
>
>   "I don't see why not.  It's got bloody well everything else."
>
>   With that, the Chief Priest went to lunch.  The novice suddenly achieved
> enlightenment, several years later.
>
> Commentary:
>
>         His Master is kind,
>         Answering his FAQ quickly,
>         With thought and sarcasm.
>
>
Heard somewhere: Emacs is my operating system and linux is its device
driver.

No I dont belong to that camp -- Actually I am quite dissatisfied with
emacs nowadays... Keep trying eclipse and getting repulsed by the gorilla.

Philosophy being this: What functional programming is to program-semantics,
fast-branching (as in git) is to program-source[1].  To complete the
trinity, one needs semi-automated refactoring.
The first I can do in my sleep; the second still noob-status, the third yet
to start!

[1] Not necessarily source-code See
http://blog.vctr.me/posts/why-you-should-learn-git.html

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


#50042

FromRoy Smith <roy@panix.com>
Date2013-07-05 23:25 -0400
Message-ID<roy-10D13B.23251005072013@70-1-84-166.pools.spcsdns.net>
In reply to#50041
In article <mailman.4323.1373080433.3114.python-list@python.org>,
 Rustom Mody <rustompmody@gmail.com> wrote:

> > I'm a vi user. Once I mastered "hit ESC by reflex when you pause
> > typing an insert" I was never confused above which mode I was in.
> >
> > And now my fingers know vi.

All the vi you need to know:

<esc> : q ! <return>

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


#50043

FromJoshua Landau <joshua.landau.ws@gmail.com>
Date2013-07-06 05:35 +0100
Message-ID<mailman.4324.1373085694.3114.python-list@python.org>
In reply to#50042
On 6 July 2013 04:25, Roy Smith <roy@panix.com> wrote:
> In article <mailman.4323.1373080433.3114.python-list@python.org>,
>  Rustom Mody <rustompmody@gmail.com> wrote:
>
>> > I'm a vi user. Once I mastered "hit ESC by reflex when you pause
>> > typing an insert" I was never confused above which mode I was in.
>> >
>> > And now my fingers know vi.
>
> All the vi you need to know:
>
> <esc> : q ! <return>

I never got why Vi doesn't support Ctrl-C by default -- it's not like
it's a used key-combination and it would have helped me so many times
when I was younger.

:^C
Interrupt
:^C
Interrupt
:^C
Interrupt
:^C
Interrupt
:
At end-of-file
:
At end-of-file
:
At end-of-file
:
At end-of-file
:^C
Interrupt
:
At end-of-file
:^C
Interrupt
:
At end-of-file
:^C
Interrupt
:^C
Interrupt
:

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


#50044

Fromrusi <rustompmody@gmail.com>
Date2013-07-05 22:19 -0700
Message-ID<b86b57b7-4739-43f0-8e0a-c41b14a16d67@googlegroups.com>
In reply to#50043
On Saturday, July 6, 2013 10:05:14 AM UTC+5:30, Joshua Landau wrote:
> I never got why Vi doesn't support Ctrl-C by default -- it's not like
> it's a used key-combination and it would have helped me so many times
> when I was younger.

Dunno what you are referring to.
Out here C-c gets vi out of insert mode
Second (onwards) and it prints
Type :quit<Enter> to exit Vim

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


#50046

FromJoshua Landau <joshua.landau.ws@gmail.com>
Date2013-07-06 07:19 +0100
Message-ID<mailman.4326.1373091594.3114.python-list@python.org>
In reply to#50044
On 6 July 2013 06:19, rusi <rustompmody@gmail.com> wrote:
> On Saturday, July 6, 2013 10:05:14 AM UTC+5:30, Joshua Landau wrote:
>> I never got why Vi doesn't support Ctrl-C by default -- it's not like
>> it's a used key-combination and it would have helped me so many times
>> when I was younger.
>
> Dunno what you are referring to.
> Out here C-c gets vi out of insert mode
> Second (onwards) and it prints
> Type :quit<Enter> to exit Vim

I know how to quit Vi *now*, but when I didn't it was a pain. It's
easy to get lost in a program that doesn't accept the *standard
quitting key*.

The rest of my post was a demonstration of what my Vi sessions used to
look like. Note that Vi != Vim; Vim at least tells you what to do.

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


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

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


csiph-web