I'd add my general strong agreement.
Phil refers to
http://fmwww.bc.edu/repec/docs/textEditors.html
but that's an out-of-date version. Please look
at (and if necessary revise your set-up to
refer to)
http://fmwww.bc.edu/repec/bocode/t/textEditors.html
A further revision (with correction on Mac editors)
is currently stuck in fog on the Grand Banks, but will
no doubt get to the Boston machine when Kit Baum has finished some
much more urgent projects.
To expand on one detail: that FAQ is necessarily
a compilation from very well-informed people with
details on many quite different editors, and it's
difficult for me as compiler to be clear that everyone
understands the same thing when syntax colo[u]ring
or highlighting (hiliting, !) is mentioned.
Highlighting command names or other key words is one
interpretation. Something that is sensitive to syntax is
another. In either case you can end up looking at rather
lurid fruit salad.
Nick
[email protected]
Phil Schumm
> On Apr 4, 2006, at 12:49 PM, Ron�n Conroy wrote:
> >> The word is that syntax highlighting is not going to happen. It
> >> conflicts with the idea(l) of -doedit- as a minimal editor and
> >> arguably the people who want it most are already using serious
> >> editors. (Don't shoot the messenger on this one!)
> >
> > I disagree (not with Nick, of course, but with the point of view).
> > There are probably a lot of Stata users out there who rely on
> > Stata's own editor. It doesn't bloat an editor to make it
> do syntax
> > colouring. And colouring would help the people who most need it -
> > beginners who are getting to grips with writing Stata code.
>
>
> It's important to remember that with Stata, "syntax coloring" (or,
> perhaps more accurately, "command highlighting") is a somewhat
> ambiguous concept. There are two main reasons for this:
>
> 1) Unlike a language with a small and stable set of commands, the
> list of Stata commands (i.e., all built-in commands together
> with all
> commands defined on the user's ado path) is large and always
> changing. In fact, it can even differ between users (depending upon
> which additional ado-files they have installed).
>
> 2) The same word can in one context be a command and in
> another refer
> to something else (e.g., a variable name).
>
> For these reasons, any attempt to color commands in Stata would
> either (1) be incomplete and inconsistent, or (2) require
> considerably more machinery than is used (or even available) in most
> current coloring routines (at least the ones with which I am
> familiar). Personally, I'd rather have no coloring at all than have
> to deal with (1) (though I accept the fact that some may disagree
> with this).
>
> In my personal setup (which I have been happy with for a long time),
> I have good coloring support for comments (in all their possible
> forms), which I find to be invaluable. I also use coloring for
> strings (i.e., words inside double quotes). I've occasionally
> thought it would be nice to have coloring for macro expansion (i.e.,
> content inside `') and/or compound double-quoted strings, however
> these are often combined within nested expressions, and so I don't
> know in reality how useful they would be. Note that what I current
> use is essentially restricted to "syntax coloring". I did at one
> point consider (not seriously, but rather as a thought experiment)
> the idea of coloring the various pieces of a Stata command
> line based
> on parsing it's syntax (this would in theory get around the two
> problems identified above). However, apart from the obvious
> technical hurdles, it occurred to me that having too much color on
> the screen might actually become detrimental. For example, since
> comments are essentially the only things colored in my setup, they
> really jump out. This would be less true if a lot more of the
> content were colored.
>
> As everyone knows, the issue of text editors is a religious one. In
> particular, the following is true: (1) any features you implement to
> please one person are very likely to simultaneously displease
> another, (2) attempts to get someone to change his or her editor are
> likely to be futile and, in some cases, arouse a hostile reaction,
> and (3) it's difficult and inefficient to use different editors for
> different tasks. In my case (and I suspect for many others),
> my text
> editor is the most important piece of software on my machine (except
> for Stata, of course!). I use it for everything, including writing
> code (in multiple languages, including Stata), writing papers and
> letters, editing configuration files, and inspecting files of all
> kinds. As a result, I know it like the back of my hand. And
> although I occasionally pop into other editors (including Stata's
> current do-file editor) for small tasks, I always return to my
> preferred editor for anything substantial. IOW, for users like
> myself, enhancements to Stata's built-in editor are not going to be
> of much value.
>
> That said, I realize that many users may use the built-in
> editor much
> more frequently than I do, and I certainly wouldn't argue against
> adding a few additional lightweight features which might be helpful
> for such users. I do believe, however, that if you are a user who
> feels constrained by the limitations of the current built-in editor,
> you will in the long run be much happier if you take a little
> time to
> read the text editor faq, find an editor you like, and stick with it.
>
>
> -- Phil
>
> P.S. The url for the aforementioned faq is http://fmwww.bc.edu/repec/
> docs/textEditors.html.
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
