Bug or Design Limitation (Unexpected use case?) in new do-file editor feature

[Clyde Schechter]

In the recent updates to version 17, a new feature was edited to the do-file editor so that you could place the cursor on a line and then have that line executed, and then the cursor would move to the next line, skipping over comments and blank lines. This would lead to a very simple way to step through code one line at a time.

The problem is that a command can extend over several lines. I have found (Windows 10, version 17 MP4) that when I extend a command over multiple lines using ///, only the first line of the command is executed (if it is not, without the subsequent lines, an invalid command), and the cursor then moves to the next line of the same command. That next line, of course, is not by itself a valid command.

So this feature does not seem to work with commands that break over several lines. It would be a terrific enhancement if this behavior were modified so that it really executes one command at a time, rather than one literal line.

[Nick Cox]

Not the same point, but we already see many posts in which the underlying problem is executing code line by line from the do-file editor when local macros are being used. The result is usually wrong and often hard for newish users to debug, and to be fair. this is quite a subtle point that is easy to miss.

[Leonardo Guizzetti]

In the recent updates to version 17, a new feature was edited to the do-file editor so that you could place the cursor on a line and then have that line executed, and then the cursor would move to the next line, skipping over comments and blank lines. This would lead to a very simple way to step through code one line at a time.

This feature feels like an attempt to copy from RStudio, which has the same behaviour to step through and execute code, line by line. What seems to be broken, as you point out, is that the Do-file editor is unaware of lines that break over multiple lines. (I also suspect it would break should a user change the default line delimiter to a semicolon.)

[Chinh Nguyen (StataCorp)]

The problem is that a command can extend over several lines. I have found (Windows 10, version 17 MP4) that when I extend a command over multiple lines using ///, only the first line of the command is executed (if it is not, without the subsequent lines, an invalid command), and the cursor then moves to the next line of the same command. That next line, of course, is not by itself a valid command.

This feature was simply added due to frequent requests from our users for the ability to execute the line the cursor is on and then advance the cursor. Not supporting /// was an oversight that will be corrected in a future update. Supporting #delimit ; can be done but Stata can only look at the current state of the delimiter so users must ensure the delimiter is set properly when executing lines.

The limitation with local macros has always existed when executing selections from the Do-file Editor whether it be a single line or multiple lines. When Stata executes a selection in the Do-file Editor, it simply writes out the selection to a temporary file and executes it like a do file.

[Chinh Nguyen (StataCorp)]

(I also suspect it would break should a user change the default line delimiter to a semicolon.)

I misspoke earlier and you are correct. The Do-file Editor can't handle a semicolon delimiter when executing a single line.

[Leonardo Guizzetti]

I misspoke earlier and you are correct. The Do-file Editor can't handle a semicolon delimiter when executing a single line.

That's ok. It's commendable to continue adding features to the do file editor and I think many will find it useful.