[John Eiler]

I have to ask....do you go days without saving do-files?

I usually save pretty frequently, at least once an hour. The danger here in my experience is just making a small but important change and then you get disconnected from a remote session and don't realize it wasn't saved and you go on assuming your bug fix is there the next day, but, oops, it isn't!

Btw, in the time it took me to type the above short paragraph, this web page just autosaved twice! Anyway, this sort of auto-save is now so standard everywhere except Stata that it now makes Stata seem behind the times.

[Leonardo Guizzetti]

Ah I understand what you mean. I've sometimes been caught out a couple hours of work. For scratch work that I'm not ready to commit to a saved file, I've been known to stash it in Notepad++.

[FernandoRios]

It is more like one day's work of programming. (how much difference because of an apostrophe!)
But I some times get overconfident and forget to save, (and not turn off work computer). That is all on me
That happens in particular when I'm programming a particularly tricky task. (Shortcode but long hours of thinking about how to do it).

[Leonardo Guizzetti]

One thing I wish Stata would do. Save do-files backups.
More often that i would like to admit, I lose days of programming work because Stata would shutdown for no reason (very rare but happens). I know I can recover the latest submitted code looking into the temp folder, but I wonder how hard would it be for Stata's editor to save a copy of all open programs regularly on the background.

I think an autobackup feature is a perfectly good and useful feature. An alternative idea for this is how the likes of R Studio, Sublime Text Editor or Notepad++ handle persistent "workspaces", so that even unsaved files are auto-saved and restored whenever the program is restarted.

I have to ask....do you go days without saving do-files?

[FernandoRios]

One thing I wish Stata would do. Save do-files backups.
More often that i would like to admit, I lose days of programming work because Stata would shutdown for no reason (very rare but happens). I know I can recover the latest submitted code looking into the temp folder, but I wonder how hard would it be for Stata's editor to save a copy of all open programs regularly on the background.

[Leonardo Guizzetti]

One feature that I think would be very easy to implement is to add code folding for frames. Sometimes, I execute several hundred lines of code in a frame before copying a couple of things to the default one and it can get painful scrolling through thousands of lines of codes associated with different frames. Folding frame code would be very helpful and easy to implement.

wbuchanan has hit on the obvious solution, using curly braces -{}-. I think it would be difficult to implement as is for frames unless one explicitly binds the operations performed using those frames also in curly braces, such as

frame myframe: {
   ... do something
}

The above allows cold folding. Further, by explicitly adding the braces, it signals that the block of code is somehow contiguous. Then again, it is also a matter of style and taste whether one finds the braces useful or distracting.

Now envision how, I presume, frames are used more commonly.

frame change myframe
... do some things
frame otherframe: do something else
...back to myframe

Where should one define the block of code to fold? Is it lines 1-2? 1-4?

[wbuchanan]

John Schawrz
I’m pretty sure there are existing ways to do this with some of the frames commands. I can’t remember the syntax at the moment, but there is a command that allows you to execute code on a frame that is contained within curly braces; the curly braces would then make it possible to fold the code contained within it.

[John Schawrz]

One feature that I think would be very easy to implement is to add code folding for frames. Sometimes, I execute several hundred lines of code in a frame before copying a couple of things to the default one and it can get painful scrolling through thousands of lines of codes associated with different frames. Folding frame code would be very helpful and easy to implement.

[Marc Campo]

I don't know if there is an option in 16 (I am running 15.1) and there is no shortage of workarounds, but in roctab, it would be helpful if there was an option to specify that higher values on the test result in a reduced risk of the outcome/disease.

[David Bishai]

Stata needs an easier way to do spatially autocorrelated survival models. R has spatsurv. Stata offers a nightmare of attempting to trick its Bayesian survival estimator to accept a covariance matrix that is insanely hard to load.

[Sven-Kristjan Bormann]

Stata could also offer a warning or an error message if the name of a local and the counter in a foreach-loop are the same.
A construct like

local date 12345 12345 12345
foreach date of local date {
    di `date'
}

will fail without notice. I can guess why this happens but it is still an unexpected behavior for some users. See the problems with the code in this thread.

[Christopher Bratt]

#102 states

better description of the errors. Stata errors messages are usually very general and leaves no way to know where things have gone wrong, unlike those in R and Mplus.

I agree. Error messages in both R and Mplus make it quite easy to understand what caused an error. In R you can just copy the error message and google it. Often you'll find the solution at Stack Overflow as several before you have encountered the same error.

Stata often basically says "something went wrong". This is a bit surprising. StataCorp has put a lot of effort into developing a language that is easy to use and easy to remember if you return a few months later, and Stata has excellent manuals.

But it would have been great if more effort went into generating specific error messages. If such a specific error message itself is not sufficient for the user, they might more easily find the solution by googling it, provided the specific error message is mentioned in online manuals and/or someone before you encountered the error and received help, for instance at Statalist or at Stack Overflow

[Joseph Coveney]

Regarding #240: I used to work up the graphics commands interactively from the command line, too. But because of the very problems you describe, I now just create a one-off do-file in the editor and either execute it or select-execute the command (including the continuations).

It's nearly equivalent to interactive, and when I get the graph to my liking, I either (1) just copy-and-paste the final command into the proper location of the main do file or (2) go ahead and save the one-off graph-command do-file and have the main do-file call it.

[William Lisowski]

re: #238: Underlying this request is a more general theme - the disparity between the syntax accepted interactively and that accepted from do-files. The #delimit command is one example. The comment and continuation syntaxes are more frequently encountered examples that make it awkward to change from testing and editing a command as part of a do-file to testing and editing it interactively through the Command window. When I'm repeatedly banging on a graphics command to try to get it to do what I want, which always takes me an inordinate amount of time because I don't do it often, it is helpful to have single environment for editing and running, and the audit trail in the History window. But first I have to dink around to get all the continuation out of the command without accidentally deleting an option or two, and then when I get it right, put the continuation back in when I return it to my do-file.

My wish is that the Command window interpreter gain greater consistency with the do-file interpreter.

[Rich Goldstein]

re: #238 - why not just put the "#delimit ;" in your profile.do file so it is set on each time you open Stata?