Re: st: RE: Critique on comment syntax and suggestions

["Mason, Bryce" <Bryce.Mason@lmu.edu>]

Regarding Mr. Winter's point #2, I suspect that the code that checks the do-file contents could also check global parameters set outside of the editor, and would not think that this would pose a problem for the color coding. It would be wonderful if the folks at Stata could make the coloring consistent with the parsing.

Regarding Mr. Samuels citation #3 of the referenced Stata example, I do not see how the action of "//" is relevant to my case using "*". We all know how // works and it is independent of any delimiter.

While we are being pedantic, we should be careful how we use "line" so as not to be ambiguous, as one doesn't know if it means a single row of text with the inevitable carriage return or the set of characters between delimiters. The whole point of using a delimiter is that a line can span multiple rows. We would go crazy if we had to use "cr" because some of our commands are so long.


On Jan 28, 2011, at 1:10 PM, Nick Winter wrote:

Two points:

First: The command *is* part of the comment, as far as Stata is
concerned, because (1) the delimiter is ";", and (2) there is no ";" on
the prior line.  That one does not intend it to be part of the comment
does not change the fact that by Stata's consistent rules, it is in fact
part of the comment.

Second, The question is why the syntax highlighting does not color it as
a comment.  Here I think things are a bit more complicated.  If a .do
file explicitly sets the delimiter to ; and then later sets it back to
cr (carriage return), then the syntax highlighting function could, in
theory, track that and highlight comments accordingly.

However, a user can set the delimiter outside the do file. In this case,
the delimiter for a Stata session might be ; even though the do file
makes no mention of #delimit.  In this case the syntax highlighting
function would have no way to know what the delimiter is (or would need
even more complex logic to check the current state of the delimiter at
any given moment.)

That the delimiter can change seems like it presents a fundamental
ambiguity for syntax highlighting.

Nick winter

On 1/28/2011 3:04 PM, Steven Samuels wrote:
As I look at Stata's output, I do think I see a small bug in the results
display.
*****************************
sysuse auto, clear
# delimit ;
// This next line won't get processed because I forgot to put a semicolon
drop if mpg ==.;
******************************

Output (SMCL or text)
****************************
sysuse auto, clear
. # delimit ;
delimiter now ;
. // This next line won't get processed because I forgot to put a semicolon
drop if mpg ==.;
(0 observations deleted)
*****************************

Notice that the line beginning the valid command is started by a
continuation character ">". I would call this a bug, but it does not
mean that the line is part of the comment!

Steve



I think there is a small inconsistency, as Joseph pointed out. A

You are not correct, Daniel; the following line is _not_ a part of the
comment. Take a look at Joseph's message, especially his example 3 at
http://www.stata.com/statalist/archive/2008-09/msg01271.html

Steve

On Jan 28, 2011, at 2:34 PM, Daniel Feenberg wrote:


On Fri, 28 Jan 2011, Steven Samuels wrote:

--


--


I've been bitten in the past by omitting semicolons. I now use
continuation characters, and reserve the semicolon to delimit single
commands, especially for graphs, that have many, often long, options.
I find such commands easier to read and modify if each option is on a
single line. If I use continuation characters in such commands, the
lines look messy unless I line the characters up. For me that's too
much work. As Nick said, it's personal taste.

Bryce, you are asking Stata's do-file editor to find syntax errors, and I

Not really - the line:

drop if criticalvar=1;

is stricktly speaking part of the comment, and he is asking that it be
colored as a comment, to match the view that Stata will take. Currently
the editor is treating it as executable, which is clearly an incorrect
parsing of the code.

don't think that's its function. After reading the second post David
referred to (it's by Joseph Coveney), I don't really see a bug. Off
topic, "Stata" is spelled "Stata." See the FAQ Section 8.2.

Steve





*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/

*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/

--
--------------------------------------------------------------
Nicholas Winter                                 434.924.6994 t
Assistant Professor                             434.924.3359 f
Department of Politics                  nwinter@virginia.edu<mailto:nwinter@virginia.edu> e
University of Virginia          faculty.virginia.edu/nwinter<http://faculty.virginia.edu/nwinter> w
S385 Gibson Hall, South Lawn
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/

Bryce Mason, Ph.D.
Director of Institutional Research
Loyola Marymount University
1 LMU Drive, Suite 4820
Los Angeles, CA 90045-2659
e: bryce.mason@lmu.edu<mailto:bryce.mason@lmu.edu>
w: (310) 258-8838
f: (310) 338-1841




*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/