Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: RE: My Stata wishlist


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: st: RE: My Stata wishlist
Date   Wed, 5 Apr 2006 00:07:24 +0100

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. 


Nick 
n.j.cox@durham.ac.uk 

> -----Original Message-----
> From: owner-statalist@hsphsun2.harvard.edu
> [mailto:owner-statalist@hsphsun2.harvard.edu]On Behalf Of Nick Cox
> Sent: 05 April 2006 00:04
> To: statalist@hsphsun2.harvard.edu
> Subject: RE: st: RE: My Stata wishlist
> 
> 
> 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 
> n.j.cox@durham.ac.uk 
> 
> 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/

*
*   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/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index