PickingAnEditorDiscussion

HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences

Also, it is important to have a clear idea of what purpose your text editor will be used for, on what platforms, and on what kind of data.

For example, the VEDIT editor is acknowledged to be a powerful TextEditor for very large files (over 200 megabyte). It may not be the best choice for XML.

--RonPerrella

Around 1980 one of my lecturers explained that although there were many good new editors in existence, he was at an age where he just did not have the patience to learn a new editor every time he moved to a new system, and so he took the source code of the editor he had designed in the 60's with him and ported it (with very little effort) to every new system he had to use. I found this rather amusing at the time, thinking that "The Old Man's memory must be starting to slip..." but by the time I had had to learn my fourth or fifth text editor because none of the previous ones were available as I hopped from platform to platform in parallel with hopping from job to job (going from VAX/VMS to OS4000 to BBC Micro to Macintosh to DOS, for example) I came to see the wisdom in his remarks, and now 25 years later I too am carrying around the source code to that very same editor, which I compile everywhere I go. 45 years and only one change of implementation language (moving from an Algol-like language to C) and almost no changes to the editor design, and I can still run rings round the kiddies in editing anything from programs to novels :-)

--

It would be nice if we had a category, or a site, that listed and reviewed text editors that are designed for handling large files. In fact I have tried many that claim to be designed for large files only to find that when I try and open an 800MB data file it sits choking trying to process the whole thing, eating up my RAM along the way. That is not support for large files by my definition.

I would think an editor that supports really large files would be implemented so that it only reads the first part of the large file, immediatley shows you that and returns interactivity to the user. Basically it should intelligently manage the file in chunks, wether that be for searching or navigating or editing.

Good Point! -- I put a CategoryLargeFileHandling out there on a couple of TextEditors that I know handle very large files.

--

In the book, "The Pragmatic Programmer" by Andrew Hunt and David Thomas, they devote Chapter 3 to "The Basic Tools".

They promote the idea of "Use one editor well".

The four features they insist on are:

1) Make sure your editor is available on all platforms you use, often in GUI and Text modes

2) Make sure it is configurable

3) Make sure it is extensible - you should be able to teach it new languages

4) Make sure it is programmable

One quotable from the book is:

A surprising number of people we've met use the Windows notepad utility to edit their source code. This is like using a teaspoon as a shovel --simply typing and using basic mouse-based cut and paste is not enough.

Basically, they are saying that you're working too hard. Get a better text editor!

--RonPerrella


A similar analogy:

Agreed. In fact, I suspect you'd get the same argument from PaulGraham?. He certainly believes that the BestAvailableStrategy makes the most sense when picking programming languages, so he picks Lisp. I wonder if he uses GnuEmacs? -- RonPerrella

He edits in vi and pastes into a REPL window: http://lemonodor.com/archives/000689.html


HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences
Edit text of this page | View other revisions
Last edited April 2, 2009 12:19 pm (diff)
Search: