Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: A suggestion for multi-line commands


From   "Dupont, William" <[email protected]>
To   <[email protected]>
Subject   RE: st: A suggestion for multi-line commands
Date   Wed, 7 May 2003 12:37:44 -0500

Nick

Many users will initially generate their commands using the point and
click interface.  This does generate rather lengthy commands.  The more
you take advantage of the options on the dialogue boxes, the lengthier
these commands become.  I still think that having some way of making
these commands easier to read in the Stata Command window would be of
value.  Also, when people start using do files, the easiest way to do
this is to generate code interactively via the dialog boxes and then
using the cmdlog command to generate do files.  This will undoubtedly
lead to do files that are not as elegant as could be created by an
expert user.  However, making such files a legible as possible is
important, and would increase the value of the graphical user interface.

Your point about confusion between ">" as a continuation symbol and ">"
as an inequality symbol is valid.  Perhaps some other symbol or
combination of symbols might be better.

Bill

-----Original Message-----
From: Nick Cox [mailto:[email protected]] 
Sent: Wednesday, May 07, 2003 12:05 PM
To: [email protected]
Subject: Re: st: A suggestion for multi-line commands


Bill Dupont 

> Background:
> 
> Stata version 8 gives us greatly increased flexibility, particularly
in
> regards to graph commands.  A cost of this flexibility is that the 
> commands are much more complicated and much longer.  These commands 
> would be much easier to read if they could be written on multiple
lines
> with the user controlling the line breaks.
> 
> Stata allows such control in do files through the #delimit command, 
> which replaces the enter key by the semicolon as the command
delimiter.
> This works well for disciplined experienced programmers.  It works 
> poorly for inexperienced users whose computing experience is largely
of
> the point and click variety; it does not solve the problem of 
> interactive command entry.  (I have found that trying to teach SAS
to
> clinicians is a disaster, in large part because of the difficulty
they
> experienced remembering to correctly delimit their commands with
> semicolons.)  In my opinion, reserving the enter key to indicate the 
> execution of the current command is very important for inexperienced 
> users.
> 
> Suggestion:
> 
> Stata output already uses a right pointed bracket (>) in column 1 to 
> indicate the continuation of the command from the previous line.
Would
> it be desirable to make the  <alt>Enter key break the command in the 
> Stata Command window and enter a ">" as the first character of the
new
> line.  This would allow users to enter nicely formatted multiline 
> commands in the command window while preserving the Enter key to
mean
> "execute the current command".  For example, the command
> 
> twoway (scatter glyco ph, msymbol(circle_hollow) ) (line yhat ph),
> ylabel(0(50)300) xlabel( 6.9(.1)7.5) ytitle(Plasma Gycolate (mg/dl))
> 
> might be reformatted as
> 
> twoway (scatter glyco ph, msymbol(circle_hollow) )
> >      (line yhat ph)
> >      , ylabel(0(50)300) xlabel( 6.9(.1)7.5) ytitle(Plasma Gycolate
> (mg/dl))
> 
> A ">" character at the beginning of a line in a do file could then
be
> allowed to indicate that the current line was a continuation of the 
> preceding one.  This would unify the syntax of Stata output with
Stata
> input from both the Stata Command window and from do files.
> 
> Questions:
> 
> Would this addition be of use to the Stata community?
> Would it be very difficult for Stata to implement?
> Have I overlooked anything in the manuals that is equivalent to this 
> suggestion?

I'm agnostic on the principle. I don't want to have to devote 
any mental effort to distinguishing real > characters and continuation
> characters, a detail very minor in principle, but sure to be a small
source of irritation. 

Beyond that, I'm most struck by your example which seems to depend on a
previous 

regress glyco ph 
predict yhat 

The whole sequence strikes me as far more convoluted than I 
would want to type myself for this problem and than I would 
expect students to type routinely, given the existence of alternatives. 

One is 

scatter glyco ph || lfit glyco ph 

and another is 

regress glyco ph 
regplot 

given prior installation of -regplot- from SSC. 

No doubt you have many other examples, but to my mind the 
teaching issue often boils down to providing very simple wrapper
commands which mean that students very rarely have the problem 
you describe at the outset. 
 
Nick
[email protected]
*
*   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–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index