Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: Copying Stata code with line numbers

From   Jeph Herrin <[email protected]>
To   [email protected]
Subject   Re: st: Copying Stata code with line numbers
Date   Thu, 08 Mar 2012 15:58:03 -0500

As a longtime Vim user, I have to add to Nick's list

 4. Efficient navigation and editing without recourse to a pointer

Vim will let you reach for the mouse if you want to, but just think of all the wasted time and energy....


On 3/8/2012 1:35 PM, Nick Cox wrote:
There are many more than three; that's the key point.

I use Vim for most editing, including what many would do in a word processor.

Off the top of my head, the following are especially helpful:

1. Support for multiple windows (same file or different).

2. Versatile find and change features with regular expression support.

3. A command language that allows very fast operations once you know
it. (Sound familiar?)


On Thu, Mar 8, 2012 at 4:34 PM, Airey, David C
<[email protected]>  wrote:

I find the Stata do file editor just fine for complex data analysis.

However, I also find the RStudio IDE enough for me.

Maybe at some point I will depend more on an external editor. However,
all my programs are built from smaller programs, and I never have
had a program that needs more than a screen. What am I missing?

I know some do spend 99% of their time in a text editor, and spend
considerable effort linking (sometimes failing) the editor to other programs.

Nick, what 3 aspects of Vim (or whatever) make it so useful in your
personal Stata programming?


I don't know where Partho gets the impression that "very few regular
Stata programmers use the built-in editor".

More seriously, I am happy to agree that good text editors are
immensely helpful, but I'd place the emphasis elsewhere.

Let's not get sidetracked by distinguishing "regular programmers",
however defined, from other users, or by focusing on what they use,
not least because the do-file editor is not primarily designed as a
programmers' editor. It is for do-file editing, primarily. So, it is
aimed very much at all users who are not satisfied by interactive
sessions in which each command is typed one at a time. That should be
most users. (A do-file is not a program as such. Whether it defines a
program is a different issue.)

A little history here: When the do-file editor was introduced into
Stata there were already very well-developed text editors in existence
and Stata's developers were very well aware that many users were using
them intensively: after all, that was precisely what the developers
were doing themselves. Also, there was not, and is not, any kind of
consensus on the leading text editor, even within users of a single
operating system. Even among Unix users, there was much friendly and
some angry disagreement between users of vi, emacs and other editors.
So, there was no real mileage in announcing to Stata users that the
standard would be to use a particular external editor, even one that
was free. (It remains true, I think, that many Windows users make
little or no use of text editors any way; most of the students I ask
(age ~ 20) don't seem to know about Notepad, not that they are missing

In essence, the Stata do-file editor was originally _designed_ to be a
very simple editor, one that could be learned very quickly and had
just about the minimum needed. Criticising it as unsophisticated is
like criticising a bicycle for not being a plane.

Over the years  StataCorp have subverted that original aim to some
extent by adding some features in most if not all subsequent releases,
but there is no intention to try to match the better-developed editors
in functionality.

I program in Stata and when that gets a little serious I always switch
to my favourite text editor, which happens to be Vim. But I use
Stata's do-file editor daily too. It's fine, indeed very helpful, for
little editing jobs, not least in fiddling with code or data fragments
from Statalist questions. I suspect that's a common mix of styles.


*   For searches and help try:

*   For searches and help try:

© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index