(last updated: 5 July 2006)
Comments and corrections to Nicholas J. Cox, Durham University
Contributions by and acknowledgements to
Email addresses are given in the form joanna.smith at whereever.whatever and so should be translated to joanna.smith@whereever.whatever.
This FAQ is intended primarily for users of the statistical software Stata. Frequently there are questions on Statalist seeking advice on text editors to use with Stata. We believe that most if not all Stata users would find a good text editor very helpful for working with do or ado files, log files, text data files and any other text files they may be using. Indeed, many users already have some favorite editor(s) which they employ alongside Stata.
If this web page is of any interest to people who are not Stata users, that's fine. But please note that we have no desire to develop this page into a completely general guide to text editors. One fine source of information is Wikipedia. See for example the list of articles at http://en.wikipedia.org/wiki/Category:Text_editors.
Just a brief search of the internet or of available documentation will reveal many possible editors, even for one of the platforms, Macintosh, various flavors of Unix (including Linux) and Windows, on which Stata runs. All we do here is provide some general comments and some specific comments based on our experiences. We are not shy about recommending editors enthusiastically which we have found reliable, versatile and productive. Conversely, it would be futile to make comments on editors we know little or nothing about. If a particular text editor is not mentioned here, by far the most likely reason is that we don't use it, not that it has no value. Nor is the amount of coverage necessarily a measure of the value of an editor, and we welcome suggestions and corrections from those with expertise and experience in the use of particular editors together with Stata. Finally, it should be obvious, but let us underscore that what follows is often just personal opinion, and is not to be attributed to any institution, either those we work for or those we don't. ("I" within any section refers to the person named as its author.)
First, be clear about the difference between a word processor and a text editor. A word processor (for many Stata users, the example to spring to mind will be MS Word) formats and organises a document. Everything about how a word processor works is aimed at this: styling text, integrating tables and figures, creating footnotes and indexes, and so on. A text editor by contrast is predisposed to treat a pure text file quite literally. In a text file lines of text are the fundamental units and, very often, should be maintained as is in order that data and programs can be understood correctly by whatever software reads them – and, indeed, by the people who read them.
Word processors insert line breaks and page breaks to make the document follow a uniform style. They frequently have automatic features such as substituting curly quotes for those you actually typed. Word processors can save files as plain text, but they have an overwhelming bias to producing documents in some proprietary format (such as .doc). Even if you attempt to save a file as plain text, the results can be unpredictable, and, most crucially, when working with pure text files in a word processor it is easy to forget to do this, and the resulting file can thus be messed up.
Moreover, while a word processor may be heavily laden with features, many of those features are irrelevant to, or even a hindrance to, efficient text file editing, and the features most needed for text editing may be hard to find, or even absent. In addition, it is often true that word processors are not fast enough to handle even moderately large text files comfortably. For example, when opening text files you have to wait while the software translates between text format and its own native format.
Let us single out some of the specific advantages of text editors.
Ability to work with large text files One major advantage of a text editor for many statistical researchers is the ability to work with quite sizable text files such as the machine-readable ASCII codebooks provided with many survey data sets. An efficient text editor will usually be able to search such a document much more quickly than a word processor, and will display the material in a fixed-width font, preserving the alignment of original card-image records.
Support for multi-platform files Text files created on the three major platforms (Macintosh, Unix/Linux and Windows) differ in the way lines are terminated, with Mac OS using a carriage return, Unix/Linux using a linefeed, and Windows using both. Stata is smart enough to work with all three formats transparently: however, some word processors (most notably MS Word) are not. A good text editor will work with all three formats, and permit you to save files in all three.
Support for regular expressions Good text editors have sophisticated capabilities for the handling of so-called regular expressions. For example, your word processor will allow you to search a file for a specific word or phrase, and replace it with another specific word or phrase. However, suppose that you wanted to find and delete all of the lines in a file that did not begin with isolated periods, as would be required to turn a Stata log file into a do file. Or suppose you wanted to look for all occurrences of regress, reg, or anything in between. These tasks and others like them require the ability to search for (and replace) general patterns of characters, rather than just one particular instance of a pattern, and this capability is provided by many text editors (and also by utilities such as grep, sed, and awk). Such patterns are specified using a "regular expression": a simple web search for "regular expressions" yields several pages devoted to explaining them in detail, such as http://etext.lib.virginia.edu/helpsheets/regex.html. In addition, most books on scripting languages such as Perl, Tcl, and Python have sections devoted to regular expressions, as such languages make extensive use of them. It is difficult to convey in only a few sentences how powerful the ability to work with regular expressions can be, but suffice it to say that many problems that arise in manipulating raw data so that they may be read easily into Stata can be quickly solved with a text editor equipped with regular expression matching.
See also an excellent page on regular expressions in Stata itself: What are regular expressions and how can I use them in Stata?
Support for operations across multiple files In essence, word processors are designed to edit only one file at a time. Thus, if you have 10 do files each containing a reference to the path "/u2/here" which you want to change to "/u3/there", you need to edit the files one after another. In contrast, many text editors will permit you to work with multiple files simultaneously, thus allowing you to make the change in all files through one action. Another feature that is useful when working with multiple files is the ability to identify and to browse through the differences between two or more files, and to patch differences between them. This can be invaluable when you want to know if (and how) two raw data files differ, or when you want to see where an updated do or ado file has been revised.
Extensibility In addition to the features described above, some text editors allow users to modify and to extend their built-in functionality by writing their own editing functions using a standard language (e.g., Lisp, Tcl, Python) or the editor's own language. This is similar to what one can accomplish using macros and/or Visual Basic in MS Word, but with a much greater level of flexibility and access to the operating system, and in a way that is easier to generalize for use on different platforms.
In short, we urge strongly that you don't use a word processor to edit text files, such as data or program files. Negatively, even if you manage to do it, it takes much longer, and the chance of mistakes is much higher. Positively, good text editors have many features specifically useful for such files.
Stata users will naturally be doing other things on computers apart from using Stata, and in some cases their use of Stata will be only a small fraction of their computer time. Which text editors might be a good choice for you will depend not only on the ways in which you use Stata, but also on what else you do, on the platform you use (Macintosh, Unix/Linux, Windows), and on your personal tastes. Talk to people who work in your area, preferably near enough to phone for advice, and see what they use. Best of all, you will be well advised to ask some local expert who can give guidance, particularly if that expert is skilled with a particular editor and is willing to help out a bit as you climb the learning curve.
Broadly speaking, the importance of a text editor to you as Stata user will depend on how many of the following kinds of file you will produce, look at or change:
Although Stata's data management facilities are excellent, it is often the case that questions about text data files are best handled upstream by looking at them in a text editor. (In passing, however, we draw attention to the excellent hexdump command added in Stata 7, which is invaluable for identifying some kinds of problems in data files: it can even be useful for looking inside binary files.) Similarly, some editing of a log file may be easier in a text editor than in a word processor. Finally, if you are working with do files a lot, and especially with programs defined by ado files, then features provided by good text editors such as syntax highlighting, which is explained below, will be proportionately valuable to you.
Richard M. Heiberger and Burt Holland have some detailed comments on text editors for statistical analysis in their Statistical analysis and data display: An intermediate course with examples in S-Plus, R, and SAS, Springer, New York, 2004, Appendix E. They write (p.663):
`An excellent text editor is an indispensable tool for the statistical analyst. The editor is the single program in which we spend most of our time. We use it for looking at raw data, for writing commands in the statistical languages we use, for reading the output tables produced by our statistical programs, for writing reports, and for reading and writing correspondence about our studies to our clients, consultants, supervisors, and subordinates.'
They also suggest various requirements for any text editor to be used in interacting with a computing language (pp.663-4):
They recommend Emacs strongly.
Within windowed versions of Stata, check out the Do-file Editor, which may be opened by clicking on its icon or by typing the command doedit. This does not claim to be a full-featured text file editor, but we have found it very good for many small to moderate tasks. The main documentation for doedit is in Stata's Getting Started volume for each platform.
The main advantage of doedit is full integration with the rest of Stata. Being able to do or run part of a do file is a notable feature.
Take the time to learn about all the facilities in the Edit and Search menus, such as "Balance", "Match", "Shift Left", "Shift Right", etc., which are documented in the appropriate chapter of each Getting Started volume.
Note that the upper limit on files which can be read is 128K bytes (but Stata for Macintosh has no such limit). That's large enough to handle a typical do or ado file a few thousand lines long (and if yours are much longer, perhaps you should think of subdividing them).
Note also that under Windows the length of a filename cannot exceed 128 characters, which is the limit imposed by the Microsoft call used. A work-around to fix this is on the StataCorp to do list.
In Stata for Macintosh and Stata for Windows, you can open multiple Do-file Editors.
(Nicholas Winter and Hans J. Baumgartner:) There are some quirks in the Do-file Editor's handling of fonts under Windows. Size and font type can be selected through the pull down menu (Edit, then Preferences); however, characteristics such as bold and italic may not be set directly. The Edit, Preferences menu can be used to reset the face and size of the font, but not the bold or italic characteristics. A work-around is to paste some non-bold, non-italic text into the editor. Note that all invisible paragraph marks in the window must be pasted over, the easiest way being to select all text with Ctrl-A before pasting. To set the new font characteristics as the default, you must save the file being edited. (Before Stata 8.2, the editor took on the font attributes of text pasted into it. For example, if text in Arial bold italic were pasted into the editor, then those formats would override all default font settings. This is now fixed.)
(David Wagstaff:) In Stata before version 8, you can change the color of the font – if working on Windows and with access to MS Word – as follows.
(Note, however, that such a change in the Do-file editor is in a sense subverting its purpose. It is intended to be a text editor, not a word processor. Given the way Windows works, users can change colors, or make text bold or italicized, but such details are between you and the operating system.)
(Håkon Finne, Ronán Conroy, Hans J. Baumgartner, Kit Baum:) You may want to install a font for the Do-file Editor that makes it easier to distinguish (e.g.) 0 (zero) from O (upper case of o) and 1 (one) from l (lower case of L). Note that the Editor accepts fixed-width TrueType fonts only. If you install a new font, it will appear in the Edit, Preferences menu. In particular, ProFont is free and available for Macintosh or Windows. It is designed for programming, making most of the distinctions you need between confusable characters. Check out http://www.tobiasjung.net/profont/index.html.
Under Macintosh,
Under Windows, download the zip file, open it and drag the ProFontWindows.ttf file to the Windows Fonts directory, thus installing it.
(Nicholas J. Cox:) User-written programs adoedit (Dan Blanchette) and
fedit (Nicholas J. Cox) are downloadable from SSC. In Stata, type (for
example)
. ssc desc adoedit
for further information. The main idea of both is to use Stata's findfile command to find a specified file along the user's adopath and to open the Do-file editor on that file. In the case of fedit users are encouraged to modify the program to call up a favorite editor; in both cases users are discouraged from modifying any of Stata's official files.
The alternative to using Stata's own do-file editor is to use an external editor. While it is possible to invoke Stata and your chosen editor as entirely separate applications, it is easy and beneficial to set up closer integration between them. There are different ways to do this: for example, to set up calling of the editor from within Stata, or to run Stata from within your editor. The next section discusses how to do this with AutoIt. Otherwise further details are given under each editor discussed in detail.
The Do-file Editor of Stata has one advantage over external editors: it is fully integrated with Stata and commands can be executed directly from the editor, with a keyboard shortcut or the click of a button. External editors often have a richer set of features, including syntax highlighting, but they lack integration with Stata.
This section shows how external text editors can be integrated with Stata in a way similar to the Do-file Editor. This can be accomplished with AutoIt, a free, open source scripting language designed for automating tasks in Windows. (AutoIt is not available for other platforms.) Two sample scripts are available via http://huebler.info/2005/20050310_Stata_editor.html, which also gives detailed instructions. The first script runs an entire do-file from a text editor. The second script runs selected lines from an editor.
Requirements
Software needed:
In the case of EmEditor, the scripts can be called with the External Tools feature. Go to the Tools menu and select External Tools and then Customize Tools. Click on New and enter the information for the first script: Title (e.g., "Run do-file"), Command (the full path to the compiled script), and Icon Path (e.g., the path to the Stata executable, but any other icon can be used). Click on OK and again OK. Go to the Tools menu and select Customize Toolbars. Select the desired toolbar and click on Customize. Add the new icon to the toolbar and click on Close. Repeat the steps for the second script; select a different icon so that the two scripts can be distinguished easily. To call a script click on one of the two new icons in the EmEditor toolbar.
With TextPad the scripts can also be called by adding them to the toolbar. Go to Configure, Preferences, Tools, click Add, and browse to the compiled AutoIt script. Then right-click on the toolbar, select Customize, Commands, add an icon for the script, and move the icon to the TextPad toolbar.
(Many thanks to Dimitriy V. Masterov, Eva Poen, Amanda Tzy-Chyi Yu and Nicholas Winter for their contributions.)
(David Wagstaff) Below is the code for my editors.ado, which
illustrates how I can call either of two separate editors. I run Stata 9
on a Windows XP machine that is connected to a 19-inch monitor. With it, I can
have my Stata windows opened and still have access to the shortcuts for
my editors.
program define editors
version 8
window menu append submenu "stUser" "Editors"
window menu append item "Editors" "EditPad" "winexec e:\tools\editors\editpad.exe"
window menu append item "Editors" "UltraEdit" "winexec d:\progra~1\UltraEdit\uedit32.exe"
end
(Jens M. Lauritsen) Edit the contents of your profile.do
to include a line like
qui window menu append string "Edit" "&P Pfe" "winexec \program files\pfe\pfe32.exe"
or in Stata 8
qui window menu append item "stUser" "&P Pfe" "winexec \program files\pfe\pfe32.exe"
This example would add the Windows editor PFE, which I use, to the menu of Stata. Naturally, change the details given your own editor and its location on your system.
With Stata 8 and Macintosh OS X, winexec is available
with a limitation. The limitation is that only Mach-O native applications
may be launched this way, not CFM applications. How you can tell the
difference? From an OS X command line such as one you would find while running
the Terminal application, type (for example)
file /Applications/Stata/StataSE
If it responds "Mach-O executable PPC", you can launch it using winexec. If instead it responds "PEF binary", it is a CFM application and may not be launched by winexec.
Consider the TextEdit application located in the
/Applications directory. If from the Terminal you type
file /Applications/TextEdit
you'll get the response "/Applications/TextEdit: can't stat
`/Applications/TextEdit' (No such file or directory)".
That's because the TextEdit application is what's known as a "bundle" in OS X
lingo. Even though you see the application TextEdit from the Finder, it is
really a directory called TextEdit.app that contains a bunch of files that
make up the application. The actual executable is buried somewhere in there.
As it happens, it is in /Applications/TextEdit.app/Contents/MacOS/ –
so to launch TextEdit from Stata, you would type
. winexec /Applications/TextEdit.app/Contents/MacOS/TextEdit
So what you want to add to your profile.do is
qui window menu append item "stUser" "TextEdit" "winexec /Applications/TextEdit.app/Contents/MacOS/TextEdit"
Incidentally, Stata 8 is a bundle, so it is possible to launch another
instance of Stata by specifying the path of the executable
. winexec /Applications/Stata/StataSE.app/Contents/MacOS/StataSE
Don't forget that Stata will take command line arguments (see http://www.stata.com/support/faqs/mac/advanced8.html#startup).
You can also pass arguments to applications launched by winexec (assuming
they will accept them). For example,
. winexec /Applications/TextEdit.app/Contents/MacOS/TextEdit /Users/someuser/myfile.do
will launch TextEdit and open the file myfile.do. However, you must specify the absolute path to the file: Stata can not resolve the path for you, because it has no idea that the argument you are trying to pass is a path.
Details differ, but the main idea of syntax highlighting is that different elements of the syntax of a language are colored in your text window(s) in different ways. For this to work, someone has to write a specification of the syntax, such as Stata syntax, in a form intelligible to the editor. Even an imperfect specification can be a great help in aiding your editing: for example, apparent mistakes may be coded distinctly, which helps you to spot unmatched quotation marks, braces, square brackets and parentheses. Additionally, or alternatively, in some varieties of syntax highlighting a list of Stata command names is used to identify command calls. If an editor offers syntax highlighting for one language, then it probably offers highlighting for many more, unless it is the editor part of some development environment built around the interpreter or compiler for a specific programming language. This can be useful also to people editing web documents: some prefer to use a general text editor for editing (say) HTML documents, rather than dedicated web software, if only because they find that they do not need extra tools.
To our knowledge, some kind of syntax highlighting for Stata do or ado files is currently available for Alpha, Emacs, jEdit, SlickEdit, vim, BBEdit, TextWrangler, Smultron, SubEthaEdit, Kate, ConTEXT, Crimson, EditPlus, EmEditor, Notepad++, TextPad, UltraEdit, and WinEdt, as is explained in appropriate sections below. Even if no Stata syntax highlighting is available in other editors, using (say) C syntax highlighting if available is interesting and possibly even useful.
Alpha/Alphatk is a shareware editor for the Macintosh, Unix/Linux or Windows. For download, see http://alphatcl.sourceforge.net/wikit/. For other resources, see http://magnet.fsu.edu/~hall/docscripting/alpha/. Alpha was originally written by Pete Keleher, but is now maintained by a group of programmers referred to as the Alpha Cabal.
Alpha is a powerful, multi-purpose editor originally written for the Macintosh. It is extensible through the use of the scripting language Tcl. In fact, the majority of Alpha's core functionality is implemented directly in Tcl, just as the majority of Stata's commands are implemented via ado files distributed with the program. As a result, users with even a modest knowledge of Tcl can customize and extend Alpha to meet their specific editing requirements. Out of the box, Alpha includes editing modes for more than three dozen different types of files, including several programming and scripting languages, HTML files (highly acclaimed for this), LaTeX files, PostScript files, and command files for several analytical and statistical packages (e.g., Stata, S-PLUS/R, SAS, and MATLAB).
Currently, there are two Stata modes available for Alpha. One was written by Craig Upright, and is distributed together with the Alpha package. A second mode was written by Phil Schumm, and is available by contacting him at pschumm at uchicago.edu. Both modes provide the ability to execute do files (or a portion thereof) directly from Alpha, and both provide features like automatic indenting and matching of parentheses or brackets through use of Alpha's own routines. Craig's mode provides more elaborate syntax coloring and several special routines for file marking and navigation. In contrast, Phil's mode is considerably more modest in what it attempts to do (e.g., only very limited syntax coloring), but it has been used by Phil (and others) extensively.
Alphatk is a version of Alpha written entirely in Tcl/Tk by Vince Darley. Alphatk will (in principle) run on any platform on which Tcl/Tk can be installed, and has been tested (and works nicely) on a variety of Unix/Linux and Windows systems. Alpha and Alphatk share the same set of Tcl code files (known as AlphaTcl) that provide most of the editing functions, and therefore the two editors are very close cousins. In fact, one can move easily between editing files on the Macintosh using Alpha and editing files on a Unix/Linux or Windows machine using Alphatk.
Emacs is a tremendously versatile, extensible text editor. It provides tools and features for programming in many, many languages, as well as tools for working easily in a distributed environment. It has an extremely advanced Mail/News reader, remote file editing using ssh, scp, telnet, rsh, WebDAV, and ftp protocols, class and object browsers for programming, tree-views for perusing directory structures, clean interfaces to revision and version control systems such as RCS, CVS, SCCS, and others, as well as calendars and personal information managers (PIMs), and games. In fact, one of its earlier application icons was a picture of a kitchen sink. This versatility and maturity comes with one drawback: a steep learning curve. However, if one is already familiar with other text editors such as vi (and descendants) or Brief, Emacs comes with modes which remap command key sequences to match those editors.
Emacs is open-source (it is free both as in free beer and as in free speech), and can be run on almost any computer under almost any operating system. There are now two flavors of Emacs being developed on separate tracks by two groups, the GNU Project and the XEmacs Project. Both groups provide semi-compatible versions of Emacs for a large range of operating systems and platforms: almost all Unix/Linux variants, Mac OS X (as well as an older version for MacOS 9), and almost all varieties of Microsoft Windows, as well. XEmacs has an install-shield installer for Microsoft Windows, and can be installed using the Fink MacOS X open source software installer on the Mac.
(Ronán Conroy; David Reitter) Mac OS X users who don't want to get used to Emacs' very distinctive interface might try the Aquamacs Emacs. This distribution incorporates the behavior, look and layout of a standard OS X application (including keyboard shortcuts), in addition to the standard Emacs ones.
There are two options for augmenting Emacs (or XEmacs) to play well with Stata:
ado-mode is an Emacs major mode (as extensions built to handle the intricacies of languages are called in the Emacs world) made for editing all types of Stata files intelligently. It provides
See http://faculty.bellarmine.edu/wrising/Stata for complete information and links for downloading.
ESS, Emacs Speaks Statistics, is another major mode for Emacs/ XEmacs which provides a development environment for Stata, S (and relatives including S-PLUS and R), SAS, and other statistical languages. For every Stata platform, it provides an editing mode with syntax highlighting (colorization and/or fontification) as well as parenthesis or quotation mark balancing and highlighting of Stata keywords. For Stata under Unix/Linux, it also provides an execution environment using the command-line version of Stata.
The ESS execution environment provides keystrokes for sending lines, regions, and buffers to the running Stata process for evaluation; it also diverts output from help requests into their own buffers, both for ease in look-up and to maintain a clean transcript of statistical activity. This latter aspect of ESS works well with Stata 6.0: however, newer versions do not support graphics when run from within Emacs.
One solution for this is to use ESS to communicate jointly with R for producing nice graphics while at the same time using Stata for its analysis facilities. ESS facilitates the use of a single file, formatted in LaTeX or HTML, for combining code which can be sent to different processes (Stata or R) for evaluation or produced into an HTML or LaTeX file for generating documentation. This approach, a take-off on D.E. Knuth's "Literate Programming", is known as Literate Statistical Practice (Rossini, 2001).
Currently, ESS does not support Stata to the same extent that it supports SAS and R. This is primarily due to the power that it has for handling I/O, and because recent versions of Stata (v7 and up) want to control this as much as possible.
See also Rossini, A.J., Heiberger, R.M., Sparapani, R.A., Mächler, M. and Hörnik, K. 2004. Emacs Speaks Statistics: A multiplatform, multipackage development environment for statistical analysis. Journal of Computational and Graphical Statistics 13, 247-261.
Here's the preferred decision chart for deciding on modes.
jEdit is a free, Java-based editor aimed at the programmer, written by Slava Pestov and others. Because it runs on Java, it is identical on Windows, Mac OS X, and other Unix/Linux systems. (It will not run under Classic Mac OS.) jEdit continues to be under active development, so eventually bugs are fixed (I've not found any) and new features added. Having tried many text editors with Stata, I'm now a firm fan of jEdit. The price certainly couldn't be better. It can be downloaded from http://www.jedit.org/.
jEdit supports syntax highlighting for more than 70 file types.
I've created a syntax file for Stata:
http://www.business.uiuc.edu/ghoetker/documents/stata.xml. You may copy
that to your preferred location from within net-aware Stata:
copy http://www.business.uiuc.edu/ghoetker/documents/stata.xml filename
Unless you have changed the defaults of jEdit, you should download the
file to the modes folder within the jEdit folder and leave it
named stata.xml. As noted in the file, you need to add the following
text to the file catalog within the modes folder to have
jEdit recognise Stata files:
<MODE NAME="stata" FILE="stata.xml"
FILE_NAME_GLOB="*.{do,ado,log}" />
Here is a list of some of the many points that make it such a nice editor for Stata (mostly lifted from the jEdit homepage, but edited to reflect my experience):
General:
Code editing:
Search and replace:
File management:
Customization:
Extensibility:
(Ian Watson) Here are some additional comments on integrating jEdit with Stata. Those running jEdit under Windows can also integrate Stata more closely with jEdit when it comes to writing Stata code. The following approach assumes that you have a Stata do-file inside jEdit and wish to run selected portions of the file, examine the results in the Stata output window, then return to your do-file for further editing. The sequence suggested below makes use of the F8 and F9 keys, although any other combination will work.
This approach is based on two key ingredients:
Inside jEdit, the copying to marked.do macro is assigned to F9 and the switching to Stata macro is assigned to F8. Inside Stata, F9 is mapped to a command for running marked.do, and F8 is mapped to a command for switching back to jEdit. These keys are easily remembered (F9 is the code, F8 does the switching) so that the sequence F9 F8 F9 F8 becomes almost automatic after a while.
The macro for copying selected text to marked.do can be found at my website, http://www.acirrt.com/watson/stata, and can be saved under any file name you like (but with the extension .bsh). You may need to edit the phrase new File("d:/data/marked.do") to reflect your own directory arrangements. Place the file in the macro directory of your jEdit installation. (If you're not sure where it is, just record a macro and see where jEdit wants to put it.) Then attach that macro to the F9 key using the Utilities-Global Options-Shortcuts-Macros menu.
The switching commands are done with AutoIt scripts. See
Integrating Stata and external editors with AutoIt
for more details. The first script relevant to my discussion is
Opt("SendKeyDelay", 1)
Opt("WinWaitDelay", 200)
WinActivate("Stata/SE 9.2")
which should be saved as switchtostata.au3 and then compiled to become switchtostata.exe. (You need to make sure you have your correct version of Stata (as shown in the title bar) in the last line.)
The second script is
Opt("SendKeyDelay", 1)
Opt("WinWaitDelay", 200)
WinActivate("jEdit")
which should be saved as switchtojedit.au3 and then compiled to become switchtojedit.exe.
Getting these commands to run inside their respective applications is
straightforward. At the jEdit end, just write a short macro:
Runtime.getRuntime().exec("switchtostata");
and save this as a macro file in the macro directory. Again, make sure the filename has a .bsh extension, and then attach this to the F8 key.
At the Stata end, both the F8 and F9 keys can be mapped to their
relevant commands by inserting the following code into your profile.do
file (located in Stata's root directory):
global F8 "shell d:/data/switchtojedit;"
global F9 "do d:/data/marked;"
To make sure everything works correctly, make sure both jEdit and Stata can "see" the files they need to see. In my case, I've placed the AutoIt executables in the d:/data directory, and I've also sent the selected Stata code from jEdit to a file called d:/data/marked.do. Modify these paths, as necessary, to make things work on your machine.
Finally, while these details assume a Windows installation, the same approach can be taken with Macintosh and Unix/Linux installations. The copy to marked.do macro does not need to be modified, but the AutoIt scripts will need to be replaced by scripts appropriate to the relevant operating system.
SlickEdit is a text editor from SlickEdit, Inc. (Morrisville, NC) which is available for Windows XP, 2000, NT, Me, and 98 and for Linux, Solaris, AIX, HP-UX and IRIX. The web address is http://www.slickedit.com/.
I haven't found a file I could not load into SlickEdit, and we have some large files (over 100 Mb). Also, navigation through the file is fast. You could pull the vertical bar to the top and bottom of the file with no problem. You could have a directory with 100 files in it, highlight all of them, and press Enter. They will all be opened in staggered, separate windows in a few seconds. If you have two files loaded, you can split the screen horizontally or vertically to compare them.
There is built-in emulation for CUA, Brief, Epsilon, vi, GNU Emacs, Visual C++, ISPF and CodeWarrior. There is syntax highlighting in everything from Ada to XML, and also for Stata: see below. SlickEdit has its own language called Slick-C, but if you are not used to low-level languages, many things can be accomplished through the menus. If you use the Windows Explorer, you can set menu features so that double-clicking on files with extensions such as ado, do, txt or dat will load those files into SlickEdit. All files you work on can be autosaved to a backup directory so you don't lose any work. There's a built-in calculator; you can shell out to the operating system; you can compare two files for differences, run macros, set key bindings, etc.
Compared with the other editors described in this FAQ, it is expensive, but if your organization wants you to be productive, and you can pick up one new thing to do with the editor once a week, it is worth every penny. I started using SlickEdit about 1996 and now our organization owns several dozen copies.
To install SlickEdit on the Stata menu,
edit the contents of your profile.do to include a line like
qui window menu append item "stUser" "SlickEdit" "winexec vs.exe"
A Stata color coding lexer may be reached via http://www.slickedit.com/support/su_macros.php or copied directly from http://www.slickedit.com/download/usermacs/stata.vlx
vim is an editor with a considerable pedigree. To simplify a complicated history, involving several people: About 1970 Ken Thompson at Bell Labs wrote the Unix line editor ed. This was developed at Berkeley into an extended line editor ex in about 1976, and then into a screen plus line editor vi in about 1978, principally by Bill Joy. (For some prehistory, see Dennis Ritchie's notes on QED at http://cm.bell-labs.com/cm/cs/who/dmr/qed.html.)
There are many clones of vi (which is pronounced as "vee-aye"). vim is by far the most popular, and the only one to be discussed here. vim 1.14 in 1991 was its first public release. Major features of subsequent releases include support for multiple buffers and windows (3.0, 1994), a graphical user interface (4.0, 1996), syntax highlighting (5.0, 1998), folding and vertical splitting (6.0, 2001) and too many highlights to choose (7.0, 2006).
If you are on a Unix/Linux platform, then almost certainly all these editors will be available to you: vim may often be available as vi. vim has been ported to several platforms beyond Unix/Linux, including Macintosh and Windows: see http://vim.sourceforge.net/download.php. I use vim on Windows, and have found it very stable. Once when Windows crashed, I was able to retrieve the whole of a long editing session which I foolishly had not written to file.
vim is charityware. Those who appreciate it are asked to make a donation to a Ugandan charity supported by vim's maintainer, Bram Moolenaar.
There is a website at http://www.vim.org, which leads to download sites. Many vim users have personal web pages on their favorite editor.
vim is a combination of screen editor and line editor. You can see one or more portions of one or more files in one or more windows, and can insert, delete and change text more or less as you would in a word processor. In addition, you can change modes and issue commands, either in a text window or outside it. Switching between different modes can be tricky at first: it is only fair to say that some people find this aspect of vim offputting, but regular users find that knowing even a few commands imparts both power and speed. Many vim commands are just a single character, and can be combined with other parts of the syntax. As just a few examples, d$ deletes to end of line, d) to end of sentence, d} to end of paragraph, . is repeat last change, and so on. Although vim has an enormous number of commands, many users find that about a hundred or so are sufficient for almost all their editing needs.
In addition, many of the keystrokes with standard interpretations in interacting with your operating system retain meaning within vim. Windows users in particular should be reassured that much can be done in ways familiar to them. For example, there is much emphasis in most introductions on using the keys h, j, k and l for moving left, down, up and right on the screen: because these keys are placed centrally on keyboards, anyone who masters this is able to work very efficiently. However, in no sense is this compulsory, and those who like me have long since internalised the use of cursor keys for these movements can continue to use them. Similarly, rather more is possible with the mouse, and even via menus, in GUI versions of vim than is clear from some discussions. However, vim is no more a menu-driven program than is Stata. If you really want a menu-driven editor, do look elsewhere.
vim has the ability to do color syntax highlighting. When used at a Unix/Linux terminal, the colors are limited to those available for that terminal. The GUI version of vim (gvim) does not have this limitation. As of Vim 7.0 up, syntax files written by Jeff Pitblado of StataCorp for Stata do-, ado-, class-, and smcl-files are included in the standard release.
The most up-to-date guide is the User Manual at http://vimdoc.sf.net, which may be downloaded and printed.
There is a dedicated book by Steve Oualline, Vi IMproved–Vim, New Riders, Indianapolis, 2001. See http://www.vim.org/iccf/click5.html and in particular the rather large list of errata at http://www.moolenaar.net/vim_errata.html. I have found it useful, but not organised or edited very well. Some reader reviews can be read at http://www.amazon.com/exec/obidos/ASIN/0735710015.
An older book by Linda Lamb and Arnold Robbins, Learning the vi editor, O'Reilly, Sebastopol, CA, 6th edition 1998, covers the old vi and several clones including vim. See http://www.oreilly.com/catalog/vi6. Some reader reviews can be read at http://www.amazon.com/exec/obidos/ASIN/1565924266. This book follows in the O'Reilly tradition of well written and highly reliable technical texts, and contains much very useful material. It would be great if the next edition were a rewrite focusing on vim. A cheaper companion reference is Arnold Robbins, vi editor pocket reference, O'Reilly, Sebastopol, CA, 1999. See http://www.oreilly.com/catalog/vipr/. Some reader reviews can be read at http://www.amazon.com/exec/obidos/ASIN/1565924975. This is a handy guide to the most commonly used features.
Older Unix documentation remains not only of historical interest, but also of some use in giving good explanations of how the commands fit together. Although out of print, Berkeley Software Distribution, 4.4 BSD User's supplementary documents, USENIX Association and O'Reilly, Sebastopol, CA, 1994, is one excellent collection which may be accessible to you. Failing that, various versions of manuals by Bill Joy and others may be found with a search engine.
The following Stata programs are examples of how vim may be called
easily from within Stata to edit named files using
shell or
xshell or
winexec.
(If the version of the editor you are using is called vi, then clearly you should use that name
instead.) For Unix/Linux (console) users,
program vim
version 8
* discard
shell vim `*'
end
and for Unix/Linux (GUI) users,
program vim
version 8
* discard
xshell vi `*'
end
In Stata ! is shorthand for shell and !! is
shorthand for xshell. Both of these
commands are blocking; Stata will wait for vim to exit before continuing.
Alternatively, Unix/Linux (GUI) users can use, for a non-blocking launch of
vim,
program vim
version 8
* discard
winexec xterm -e vi `*'
end
Similarly, under Windows, I have found the following ado file useful
for calling up vim to edit files from within Stata.
program vim
version 8
* discard
winexec \vim\vim61\gvim.exe `*'
end
(Note that the particular location of the executable on my machine is wired into the last example code. The location on your machine is naturally likely to differ: if so, amend as necessary.)
The effect of the shell, xshell or winexec command is to fire up the executable for vim and pass along the arguments (none, one or more, usually filenames) to that executable as `*'. That is, once you have put these commands in a file vim.ado along your adopath, you can type within Stata vim mydo.do or vim myprog.ado and vim will open with that file loaded. When you close the editor, you will return to Stata.
Commented out in these programs, but possibly useful, is a discard command, which clears all programs from Stata's memory. This is a brute force way of ensuring that, when editing an ado file, there is never any discrepancy between the programs defined by one or more just-edited files and those in Stata's memory from the previous times the programs were defined. The very small overhead incurred in obliging Stata to clear all programs is in my experience trivial compared with the occasional loss of time spent puzzling over results and then realising and fixing the fact that Stata is still using the version of the program in memory. This discard statement need not, and should not, be used if you never edit ado files to change them.
(John D. Boy) See http://www.karpfenteich.net/pit/vimall.html for information on a free for private use program called shortcut with which you can define a shortcut-keystroke to launch vim from every Windows application and later jump back to the original application with another keystroke. (If you prefer using another editor, you can adapt the shortcut-macros to work with any other Windows 32-bit editor you like.)
(Dimitriy V. Masterov) This guide explains how to run Stata do-files from vim on a Windows XP machine using the free scripting language called AutoIt. This method will map F8 to save and run the whole file, and F9 to run part of the file you have selected in visual mode or with ordinary highlighting. The mappings will work both in visual and insert modes.
" STATA DO-FILE SCRIPTS
fun! RunIt()
w
" *** CHANGE PATH AND NAME TO REFLECT YOUR SETUP ***
!start "C:\Program Files\Scripts\rundo.exe" "%:p"
endfun
:map <F8> :<C-U>call RunIt()
:imap <F8> <Esc>:<C-U>call RunIt()
fun! RunDoLines()
let selectedLines = getbufline('%', line("'<"), line("'>"))
if col("'>") < strlen(getline(line("'>")))
let selectedLines[-1] = strpart(selectedLines[-1], 0, col("'>"))
endif
if col("'<") != 1
let selectedLines[0] = strpart(selectedLines[0], col("'<")-1)
endif
let temp = tempname() . ".do"
call writefile(selectedLines, temp)
" *** CHANGE PATH AND NAME TO REFLECT YOUR SETUP. USE \\ INSTEAD OF \ ***
exec "!start C:\\Program Files\\Scripts\\rundo.exe " . temp
" Delete the temp file after Vim closes
au VimLeave * exe "!del -y" temp
endfun
:map <F9> :<C-U>call RunDoLines()
:imap <F9> <Esc>:<C-U>call RunDoLines()
" Maps Ctrl+Tab to switch between vim tabs as in Firefox :imap <C-Tab> <ESC>:tabN :map <C-Tab> :tabN " Useful shortcut to access _gvimrc: Just type Gvimrc at ex prompt :com Gvimrc :tabnew C:/Program Files/Vim/_gvimrc
A check on any download site will reveal a number of text editors available for the Macintosh. See, for example, Version Tracker. Don't forget that the Macintosh comes with its own text editor, Simple Text (Classic Mac OS) or TextEdit (OS X). Simple Text is limited to small files and offers only limited facilities for writing programs. TextEdit is more powerful, but still lacks essential features for text editing.
Of various free cross-platform editors, Emacs, jEdit and vim all are under continual development, rich and powerful, and essentically identical across platforms. The first two have modes specifically designed for editing (a)do files. For more details, see the respective entries.
Communication from a text editor
to Stata can be accomplished nicely via Apple Events. Although Stata
currently only supports the four required events – open application, open
file, quit, and print – these are sufficient to accomplish the level of
integration provided by Stata's own Do-file editor. For example, if your
editor will permit you to execute an AppleScript and pass it the name of
the file you are currently editing (referred to here as myfile), then
the following simple script will switch to Stata and execute the file:
tell application "StataSE"
activate
open file ":myfile.do"
end tell
To specify an absolute path, enter
tell application "StataSE"
activate
open file "Macintosh HD:Users:someuser:Desktop:myfile.do"
end tell
Alternatively, without AppleScript, the Stata command (for example)
. shell bbedit -c my.do
will open BBEdit to create my.do in the current working
directory, and then close the file. You can then
. do my
You can edit the file again with
. shell bbedit my.do
Bare Bones have a simple and powerful marketing strategy: they make a version of their text editor available free, to encourage you to try it. TextWrangler, which replaced BBEdit Lite, is swift and responsive, and its features include powerful find-and-replace (including multiple files), detection and removal of high-ASCII characters, auto indent, line numbers and cursor position display. Like Stata's Do-File Editor, TextWrangler will balance brackets, and when you type a right bracket the corresponding left bracket flashes. The interface is ergonomic and uncluttered. The biggest advantage of TextWrangler is the speed with which it processes large files.
TextWrangler may whet your appetite for BBEdit (US$179, US$119 academic), which has valuable additional features, including powerful HTML tools and additional shell support. For a detailed comparison, see http://www.barebones.com/products/bbedit/threeway.shtml.
Both TextWrangler and BBEdit support syntax coloring through a module downloadable from http://dataninja.wordpress.com/2006/02/28/stata-language-module-for-textwrangler/.
Better integration of TextWrangler or BBEdit with Stata can be achieved through the use of AppleScripts which will send commands or a file of commands to Stata for execution. These scripts should be placed in (e.g.) TextWrangler's scripts folder ~/Library/Application Support/TextWrangler Support/Scripts/. Both TextWrangler and BBEdit allow you to assign key commands to AppleScripts, which lets you execute files with simple key combinations. To assign a key stroke go to the Window menu and select Palettes, then Scripts, and choose key combinations you find convenient. I (Ben Hulley) use command-shift-l and command-shift-k.
BareBones editors also include a tool which enables a quick transition from
Stata to your chosen editor. In either editor's preferences under the
Application pane, select the Install 'Edit' Tool
to install a command line activator. Then from within Stata type:
. // create a new file named "myfile.do" in the current directory
. winexec edit -c myfile.do
. // move to editor without creating a file
. winexec edit -l
. // move to editor and opens myfile.do (if myfile.do exists)
. winexec edit myfile.do
To avoid excess typing, create an ado file similar to the following:
program twedit
version 8.2
winexec edit `*'
end
Then the command
. winexec edit -c myfile.do
becomes
. twedit -c myfile.do
Additionally both BBEdit and TextWrangler have the ability to open from and save to an FTP server, which makes the two workable alternatives to a Unix/Linux-based editor for those who are not using XWindows servers on the desktop Macintosh. One can open a file on the Unix system, have it in a window on the Mac desktop, hit Save to revise the copy on the Unix/Linux system (via FTP transfer, all in the background) and click into a telnet window to run the revised program. I (Kit Baum) find it to be quite superior alternative to using a different editor when I am working on Unix/Linux than I use on my desktop Mac, and the feature set, as noted above, is very rich and powerful.
Smultron from http://sourceforge.net/projects/smultron is a free, open-source text editor written in Cocoa for Mac OS X Panther. It has a neat, elegant interface, especially suited to managing groups of files (projects). It has line numbering, support for syntax coloring in a number of languages including Stata, multiple text encodings, code snippets, a toolbar, a status bar, HTML preview, multi-document find and replace with regular expressions, display of invisible characters, authenticated saves, command-line utility and .Mac synchronisation of preferences. Smultron looks and feels a lot like SubEthaEdit. Both are well suited to people who are new to text editors. Smultron's advantages are that it recognises Stata syntax (including many user-contributed ados from SSC) without the need to install any additional files or make any modifications and it continues to be free, while SubEthaEdit is now shareware (although old versions continue to be free).
The Coding Monkeys have an innovative editor that is entirely Cocoa-based (as of February 2006 US$35, US$19.95 academic). SubEthaEdit's most noticeable feature is real-time collaboration: multiple users can work on the same document at the same time, seeing each other's edits as they go. However, SubEthaEdit is a fully-fledged text editor in its own right, with full support for regular expression search and replace, syntax coloring, bracket matching etc.
However, there are free versions for both current and older (10.2) of OS X. These are full-featured text editors which support Stata syntax highlighting.
Stata syntax coloring is provided through a mode file provided by Fredrik Wallenberg based on the BBEdit module by Benjamin Hulley. It identifies comments, strings, macros and functions by different colors. User-defined functions (ado files) that are included (very few at present) are italicized. The mode file needs to be installed in ~/Library/Application Support/SubEthaEdit/Modes/ (or the equivalent for your system or network-wide libraries). If the folder does not exist, it should be created. Note that you need to relaunch the editor to enable the language mode.
The Stata.mode file is available at: http://sims.berkeley.edu/~fredrik/files
From the SubEthaEdit homepage:
SubEthaEdit does integrate with FTP Clients which support the ODB editor suite. This includes Interarchy, Fetch, NetFinder, Cyberduck, FTPeel, Fugu and Transmit. Just configure SubEthaEdit as an external editor in these applications. From now on you can fire up your FTP client, chose "Edit with SubEthaEdit" and have changes uploaded automatically on save.
(Here Unix is defined very broadly, to include flavours of Linux as well.) For many years, there have been two especially prominent editors on Unix and similar operating systems, vi or vim and Emacs. Both are packed with features, and both have a moderately steep learning curve, yet they are very different in style. There has long been part-serious, part-jocular argument in Unix user communities about their relative merits. For one survey of these two editors and some others, not without its own bias, http://www.catb.org/~esr/writings/taoup/html/ch13s02.html.
For cartoon expressions of this rivalry, see http://ars.userfriendly.org/cartoons/?id=19991216 and http://ars.userfriendly.org/cartoons/?id=20000510.
For mugs, mousemats and T-shirts, see http://www.geekcheat.com.
Both of these editors have been ported to other platforms, including Macintosh and Windows, and so they are here regarded as cross-platform editors and documented above under the headings Emacs and vim.
In addition to the specific sources of information mentioned above, many general texts on Unix give introductory or reference chapters on these editors. Two good examples are Paul W. Abrahams and Bruce A. Larson, UNIX for the impatient, Addison-Wesley, Reading, MA, 2nd edition 1996 and Arnold Robbins, Unix in a nutshell, O'Reilly, Sebastopol, CA, 4th edition 2005.
Kate (and Kwrite, a trimmed down version) is an easy-to-use and versatile editor that comes with the K Desktop Environment (KDE). Users coming from Windows will find Kate and Kwrite especially intuitive to use.
KDE 3.4 and later ship a Stata syntax highlighting file by default. If not present, the Stata syntax file (and installation instructions) can be found in the syntax area of the Kate website at http://kate.kde.org/syntax/. The most convenient way of installing the Stata syntax file is through the menu in the editor: Settings > Configure > Highlighting > Download. Selecting Stata and clicking "Install" will download and install the syntax file.
This lightweight editor, available as a component of the pine email client distribution ( http://www.washington.edu/pine/), is very attractive for those who are connecting to a Unix/Linux system with telnet. Although its feature set is very limited, it has the great advantage of displaying its commands at the foot of the screen, so no memorization is required. Using the desktop system's facilities to copy and paste, it is possible to work quite effectively in pine if one's needs are limited to modest revisions to Stata programs, and support for remote XWindows use is limited (e.g. over a PPP dialup modem connection, or from another continent).
An introduction to Pico is given by Deborah S. Ray and Eric J. Ray, Visual quickstart guide: UNIX, Peachpit Press, Berkeley, CA, 1998, pp.64-72 (2nd edition, 2003, pp.72-77).
(addition from A.J. Rossini:) While pico is extremely attractive, and shares some keybinding with Emacs, it has been my experience that it seems to be extremely difficult to jump from pico to Emacs, much more than from just about any other editor, so one might think carefully about this choice. (The same applies for converting from pico to vim.)
As many Windows users will know, two editors are provided with all versions of Windows in extensive use at present. The great advantage, and the great disadvantage, of Notepad is that it is very simple. It can also not read large files. Wordpad has more features, and can read larger files, but both are very limited by comparison with the other editors described in this FAQ. If you are accustomed to Windows ways, and especially if you make extensive use of MS Word, they will probably appear easy to use, even on first acquaintance, being quite menu-driven.
Stata for Windows users can open Notepad independently of Stata, or within Stata. For the latter, type in the command window winexec notepad, optionally specifying the name of the file to be edited. See help on winexec. (Or do so via an ado file, as explained in more detail under vim above.)
Wordpad is perhaps better viewed as a very limited word processor, rather than an enhanced text editor. It defaults to a proportional font and RTF (rich text format) for saving files. If you try to write (for example) Stata do files in Wordpad you may have considerable problems saving them with the extension do, trying to get Stata to read your RTF file, etc. Although Wordpad has many extra features compared with Notepad, these are essentially word processing features and are of no use for editing text files. Hence I do not recommend it for that purpose.
Nevertheless, for completeness, note that the same winexec device does
not appear to work for Wordpad unless the full path leading to the
executable is specified. In practice, therefore, it would be better to call up
Wordpad with something like the following minimal Stata program. Check
that the executable is in the place specified here in your version of Windows,
and amend as necessary.
program wordpad
version 8
winexec "c:\program files\accessories\wordpad.exe" `*'
end
Once you have put these commands in a file wordpad.ado along your adopath, you may open Wordpad by typing in the command window wordpad, optionally specifying the name of the file to be edited. (For more comments on this approach, especially for those editing ado files, see under vim above.)
ConTEXT is a small, fast and powerful text editor for Windows written by Eden Kirin, a student at Zagreb University in Croatia. It was developed mainly as a tool for software developers and features syntax highlighting for many programming languages. It is free, and may be downloaded from http://www.context.cx/.
My previous text editor was PFE, and I find ConTEXT a more than worthy successor.
ConTEXT is robust. It claims to open files of unlimited size, and I can vouch for that up to tens of megabytes. It will also open an unlimited number of files: this certainly works well with several dozen. That's great for then doing a search/replace in all open files, or just the active file.
It has a Stata (7SE) environment for syntax highlighting. This works well with Stata 8, only failing to highlight some of the new graphics commands, but that should be easy to amend.
ConTEXT allows column-based text selection and operations, which is often helpful (e.g. for extracting a column of figures from output).
Other features include maintaining backups; auto-indent options; conversion from DOS to Unix/Linux and Macintosh file formats; and commenting/uncommenting code.
The package is written by one person, in response to his dislike of current editors. This does lend a kind of purity and simplicity of design. ConTEXT is Pricelessware 2006, 'the best of the best in Freeware', as determined by the readers of alt.comp.freeware. See http://www.pricelessware.org/.
The Crimson editor from
http://www.crimsoneditor.com/ is a free editor for Windows,
so small that it can be held on a floppy disk. Syntax highlighting
for HTML, C/C++, Perl, Java, Matlab and LaTeX is automatic, and for Stata
is obtained after writing the files extension.do and
extension.ado containing the two lines
LANGSPEC:STATA.SPC
KEYWORDS:STATA.KEY
in the directory link of the program. In fact support for dozens of languages is implemented under this editor, and any new language can be added easily.
I love this editor: it is so simple and versatile. One of its many features is that text can be edited in column mode: that is, you can copy and paste rectangular selections, which can be very useful when programming. Stata do or ado files can be launched from within the editor after programming a user tool.
EditPlus (http://www.editplus.com) is a full-featured shareware text editor (as of February 2006 US$30 after 30-day trial period). It is currently available only on the Windows platform. The shareware version is fully enabled and retains its functionality even after the 30-day trial period.
EditPlus has an extensive list of features for all types of programmers. A non-exhaustive list of features that I use daily and that would be of interest to Stata users would include:
Another nice feature is the ability to define document templates. Most of us probably have a little incantation that we use to begin our Stata files. For example, I start each Stata do file with:
* Comments
* Author: Lee Sieswerda, date
capture log close
log using *.log, replace
set more off
...
log close
In order to avoid typing this every time I start a new do file, I have it set as my default Stata document template in EditPlus.
For those who make their Stata files available on the Internet, EditPlus has integrated FTP support and a preview web browser (which was quite helpful in drafting this contribution to the FAQ). Also, judging by the large number of user-written syntax, auto-completion, and cliptext files that are available on the EditPlus website, there appears to be a fairly extensive user community.
I have used some of the other editors listed in this FAQ and compared them with EditPlus. EditPlus lacks the scripting language of NoteTab, but NoteTab lacks syntax highlighting and I personally found its interface inelegant. EditPlus is more full-featured than PFE, but then PFE is free. EditPlus is not nearly as powerful as Emacs (what editor is?), but it is considerably easier to learn to use. Most recently, I have been using EmEditor, which I have found very nice indeed.
And finally, I have only a couple of complaints about EditPlus. First, the EditPlus directory window only allows you to open files, not rename or delete them. Second, while you can configure a user-defined tool to pass the current file to Stata via the command line, it will always create a new instance of Stata. Since first writing this section of the FAQ, I have come to realize that this has more to with the way Stata is designed than EditPlus. See the discussion on ESS for more insight. In any case, there is a partial workaround: create a master do file that lists all of the do files you want to run and send that to Stata, rather than the individual files. Obviously, this still does not give the flexibility of Stata's built-in text editor, but can be useful in some circumstances.
Of course, these are very minor irritations and should not prevent anyone from giving EditPlus a try.
It would be easy to write an ado for EditPlus along the lines of that for Wordpad above.
EmEditor is a text editor for Windows by Emurasoft. A fully functional 30-day trial version can be downloaded from http://www.emeditor.com. As of May 2006, a single-user license for EmEditor version 5 costs US$29.99 (Standard) or US$39.99 (Professional). EmEditor is also offered in a free version with fewer features.
EmEditor supports multi-platform files (Macintosh, Unix/Linux and Windows), multiple files can be open simultaneously, and the size of text files is only limited by the amount of memory. Features of interest for Stata users include:
It would be easy to write an ado for EmEditor along the lines of that for Wordpad above. In addition, Friedrich Huebler has written two AutoIt scripts that make it possible to execute Stata commands directly from EmEditor. See the section on Integrating Stata and external editors with AutoIt.
Notepad++ is a freeware editor for Windows downloadable from http://notepad-plus.sourceforge.net. It is actively maintained, as of January 2006.
It has many great features, including:
I think the syntax highlighting interface deserves special mention here because it is quite distinctive. At any time you can click a button and a tabbed dialog appears that spells out all of your syntax highlighting settings for a given language. This allows you to modify your highlighting choices flexibly and on the fly. The result is that you get near perfect syntax highlighting. This is more important than it seems on the surface. Near perfect syntax highlighting means that you can more effectively find errors in your code because when you notice something amiss visually, it is almost certainly a coding problem and not just a flaw in the syntax highlighting. Plus, if you download a command from SSC you can add it to the list of highlighted words instantly and right within the interface - no need to search out and edit the the syntax definition file. The syntax highlighting options are very detailed and complete, allowing you to modify virtually any detail you can think of quickly and easily.
It is also worth noting that you do not need to find and download a syntax definition file to get started. Just download the user-written Stata command getcmds from SSC. It provides you with a list of all of Stata's official commands, which you can then paste into the Notepad++ syntax highlighting definition system.
The only deficiency I have experienced with Notepad++ is that there isn't a built-in help system. If you have trouble using a particular feature, you have to consult the website. This is only a serious problem if your corporate firewall inexplicably blocks access to SourceForge, which hosts the Notepad++ website. That should not be a problem for most people.
NoteTab does not have a capability for syntax highlighting, other than for HTML in NoteTab Pro. Such a capability is in the pipeline, I was told.
The potentially most useful feature of NoteTab (all versions, though Light might be nobbled a bit) is the scripting language which enables complex editing tasks and facilitates interaction with other applications. According to Help: "NoteTab integrates seamless support for Perl and Gawk interpreters; scripts can be stored in NoteTab's Clipbook and applied directly to highlighted text or the whole document." I can't vouch for that, but I will simply describe some of my own experience with NoteTab.
I have used NoteTab (for MATLAB, mostly) for several years, since when it was MiniNoteTab, for low-level stuff, not using any of the advanced features as they were introduced. Recently I wanted to improve the interface between editor and Stata, specifically to emulate Stata's editor. With a modest investment of time I managed to do that, with two clips that enable one to do or run selected lines of code or the entire file directly from NoteTab. These are available from http://www.notetab.com/other.htm.
Then I explored NoteTab's (Std or Pro) outline documents. These are structured documents that are displayed in two windows, headings on the left, the text associated with the highlighted heading on the right. I found this a convenient way to organize by topic (regression, ANOVA, etc.) the do files I have written for teaching. Click on a heading, click on a file name, right-click/open file at cursor, click on run...Seamless.
Finally, to create the original file list I wrote a clip that lists all do files in a specified directory along with the contiguous comments at the top of the file that begin with *. I have now done the same for listing ado files in ..\ado\personal\a-z.
These simple tasks were accomplished without too steep a learning curve. Of course the language looks difficult at first, but the clipbook help is convenient and NoteTab comes with sample clip libraries that are of some help. There is also a resource of user-supplied clip libraries at NoteTab.
(Guillaume Frechette:) Various extra tips:
(Nicholas J. Cox:) See also Svend Juul's notes on using NoteTab Light to handle Stata output at http://www.folkesundhed.au.dk/uddannelse/stata/introduction/notetablight.pdf
It would be easy to write an ado for NoteTab along the lines of that for Wordpad above.
PFE is a freeware multi-file text editor written by Alan Phillips, formerly of Lancaster University, UK, and is frequently mentioned on Statalist. Note that the author stopped developing the editor in 1999, and does not answer email questions on it. Nevertheless, http://www.lancs.ac.uk/staff/steveb/cpaap/pfe/ contains links to download sites. Moreover, PFE is still reliable and versatile, and continues to receive good reviews from users at its download sites. Many of these reviews contain appeals to Alan Phillips to donate the code as open source, so that other programmers can produce upgrades, but I am not aware that this has happened, or is about to happen.
A helpful feature of PFE is the ability to run DOS and Windows applications from inside the editor. This can be done with a single mouse click, without having to remember any command lines, by using PFE's customizable Execute menu, which the user can configure with up to 16 items, each with a menu name of the user's choice. For instance, the user might want to launch Stata or run TeX from inside PFE, starting in the same directory as a file currently being edited. Optionally, output from DOS and Windows applications may be captured in a command window inside PFE.
I have used PFE since 1997. From 1997 to 2002, it was the default application on my system for opening most files, including Stata do, ado, log and smcl files. In 2002, when my desktop machine was upgraded, I replaced PFE with TextPad, which has most of the same capabilities (and a little bit more), but which is not free. This was done as a precautionary measure in case PFE did not work under the new system (Windows 98 SE). As it happened, PFE did work under the new system, and the advantages of TextPad over PFE are small (I think), but by then I had already paid for TextPad.
It would be easy to write an ado for PFE along the lines of that for Wordpad above.
TextPad is a shareware text editor from http://www.textpad.com. Prices for a single-user licence (as of February 2006) are modest at (e.g.) US$30 or £16.50 + VAT. I have found TextPad reliable and versatile.
TextPad has not had a major update since July 2003. While it has many valuable features (including multiple windows, macros, replace using regular expressions, a clip library where you can add bits of code that you use regularly for easy insertion into later programs), it is beginning to feel a bit dated. It can also be customized to use the keystrokes that you prefer. If you want a text editor with a strong Windows flavour, TextPad would be an excellent choice. It is frequently mentioned on Statalist.
Syntax highlighting for Stata 6, 7 and 8 files is possible with syntax files produced by J. Scott Long. The latest version is downloadable from http://www.indiana.edu/~jslsoc/files/software/textpad/stata.syn. An earlier version is downloadable from http://www.indiana.edu/~jslsoc/files/software/textpad/stata6.syn. In essence, these file are long lists of Stata commands and keywords, which are colored distinctly within TextPad. Note that the files at Scott's site are more up-to-date than that from the TextPad site. For further comments, see http://www.indiana.edu/~jslsoc/spost.htm.
Various hints by Ivar Pettersen on enabling syntax highlighting, running a do file in Stata in the background, running selected text in Stata, and working with Unix/Linux Stata from a Windows perspective can be found at http://www.svt.ntnu.no/iso/Ivar.Pettersen/Textpad%20for%20Stata%20folder/ramme.html.
It would be easy to write an ado for TextPad along the lines of that for Wordpad above.
UltraEdit is a shareware text editor developed by Ian David Mead and available from http://www.ultraedit.com. As of February 2006 a single-user license costs US$39.95. We have found it fast, stable, and reliable. UltraEdit has many features useful for programming in many languages. These include support for:
To configure UltraEdit to open Stata and run the file open in
UltraEdit, go to Advanced and then Tool Configuration.
Suppose that you name your menu item Stata SE and set the working directory
to d:\. The command line should read (modify executable as needed)
c:\stata\wsestata.exe do "%f"
Stata SE now appears on the bottom of the Advanced menu, so that clicking on it brings up Stata and runs the current file.
It would be easy to write an ado for UltraEdit along the lines of that for Wordpad above.
WinEdt (http://www.winedt.com) is a flexible and versatile native editor and shell for MS Windows with a strong predisposition towards the creation of LaTeX documents. Despite this predisposition it can be put to other uses (e.g. writing Stata code) in a rather neat way. (Please note that there is also a distinct and unrelated Windows text editor called WinEdit.)
WinEdt is distributed as shareware (try-before-you-buy software). The program may be used for an evaluation period of 31 days. Prices (as of February 2006) are US$30 for students, US$40 for educational users, and US$70 for commercial users. Site licences are also available.
WinEdt allows the set-up of a Project, which will automatically relate a set of associated files. I find this feature particularly useful when I am working with many do files related to a single project. Some other helpful features of WinEdt are delimiter matching, block selection, and extended Find/Replace facilities.
WinEdt also has a highly customizable interface and a quite powerful and well documented macro language. It also has a fairly large user community, with a good mailing list and a website designed exclusively for the purpose of sharing free user-written add-ons to WinEdt (http://www.winedt.org).
Stata users should note that Philip Greenwood has written a very complete and well documented module for Stata: see http://www.winedt.org/Config/modes/Stata.php. After installation of this, WinEdt will automatically recognize both do and ado files, enabling several Stata-specific features, all of which can be activated through either the menu-driven dialog boxes in the Accessories menu, or short-cut keys. The features include clever syntax highlighting, active strings, running do files in batch mode and interactively, running selected parts of a do file, and exporting Stata highlighted syntaxes as HTML files.
It would be easy to write an ado for WinEdt along the lines of that for Wordpad above.