[James Sanders]

Apologies if this is a redundant request. A .do file autosave feature of sorts would be helpful. Stata itself rarely crashes but operating systems can with some frequency. When the operating system and Stata are restored, unsaved work in .do files is gone. Spelunking through temporary folders rarely if ever succeeds in recovery of unsaved code. I understand the need to save early and save often, but in practice it doesn't always work that way. If this is an easy feature to add, it would represent a high value addition to Stata.

[wbuchanan]

Not sure if I've mentioned this before, but it would be really nice to have a consistent way to map aesthetic attributes to data values across all graph types. For example, colors can be attributed in bar and pie graphs using the over option, but to do the same in a scatterplot requires constructing multiple calls to the scatter command for each of the different values of the variable that would be represented as a different color.

A potentially quick/easy request would be to also standardize the syntax for the import and export commands where applicable (e.g., using the first option for both import delimited and import excel, being able to write variable labels as headers for delimited output, etc...).

[Christophe Kolodziejczyk]

1. Functions log1p() (for log(1+x) and and expm1() for exp(x)-1 added to Stata and Mata.
2. Implementaton of integers in Mata (to get faster loops)
3. An official panelsum() function and other built-in utility functions for panel-data
4. possibility to call C or Fortran plugins from Mata.

[wbuchanan]

A few new creturn values:

fvarnames = names of the variables currently in memory
ftypes = storage types for the variables currently in memory

I'm guessing these exist somewhere and is how the ds command works, but if it was possible to get the equivalent of the r(varlist) return macro without the overhead of using the command (when scanning all variable names) this would be a nice convenience feature.

[Thong Nguyen]

Could we have a new package like 'dlnm' in R software for using distributed lag non-linear model? The model has been used more and more commonly in environmental epidemiology, such as a study on the impact of weather-related (or meteorological) variables on human population health (including some mortality or morbidity variables). I am not familiar with R software, so I really hope that Stata 15 have a new package or new command for the distributed lag non-linear model. I also attached some documents related to the model. Thanks!

[Ariel Karlinsky]

I can't remember if I (or anyone else) has already mentioned this or not: Have the user in control in every command that posts to the result window of whether or not to abbreviate variable names, labels, setting column widths, etc. It seems that too much of my time is figuring out whether this command or that command gives me the ability to control these and how. Have in the General Preferences a check mark for "always display full names and labels" or something similar. It's true that some still use lower resolution/size screen (as in laptops), so I'm not saying disregard the ability to abbreviate entirely, but don't have it as a default or at least allow the user to specify if he wishes to or not - across the board.

[Robert Reynolds]

It looks like the topic of disallowing undefined macros hasn't arisen on the Stata 15 Wishlist yet, so I'm going to take the risk of risk of bringing it back to life. I know it has been discussed in at least the past two wish lists. I've read those discussions, and I'm missing something. I don't understand why providing an option isn't viable.

The objection appears to center around the idea that a lot of existing code will break if one turns on such an option. It seems to me this is true only if the option is globally applied. Would it not be possible to provide an option that is in effect only for the do file in which the option is specified and not for any code invoked from that do file? For some other languages with whose internals I am more familiar, this would be the equivalent of a compiler/interpreter directive affecting the processing of only the file in which the directive is specified.

Also, just to head off another common objection, some people say, "Why don't you code defensively if you're so worried about undefined macros?" The problem is that I can't code defensively against misspelling, which is by far my most common "use" of undefined macros.

[David Radwin]

I mentioned it a few years ago, but I would like a built-in Stata command to calculate centiles, and their standard errors, using svy settings with replicate weights. I'm not the only one--see, e.g., http://www.statalist.org/forums/foru...licate-weights .

(In the meantime, we can use epctile by Stas Kolenikov, available from SSC.)

[Austin Drenski]

Running the do-file editor on a separate thread

It would be useful if the do-file editor could be run on a background thread (or some similar construct), so that long-running and potentially blocking commands in Stata do not lead to a degraded or unresponsive editor experience.

At present, with Stata 14, I frequently run two Stata instances at all times, one to draft code and one to execute the code, which is less than ideal.

I've given this a quick google and have not yet come across any explanations for why this isn't possible, but I am very interested to hear if there are any insights into the current design.

[Jesse Wursten]

Running the do-file editor on a separate thread

It would be useful if the do-file editor could be run on a background thread (or some similar construct), so that long-running and potentially blocking commands in Stata do not lead to a degraded or unresponsive editor experience.

At present, with Stata 14, I frequently run two Stata instances at all times, one to draft code and one to execute the code, which is less than ideal.

I've given this a quick google and have not yet come across any explanations for why this isn't possible, but I am very interested to hear if there are any insights into the current design.

For what it's worth, you can use external text editors to create dofiles (they are just text files with a .do extension). Of course they might not be complete with regards to command highlighting and so on. You can then simply type "do <path>/<dofilename.do>" in the command window once you've saved the dofile in the text editor.

Regardless, it would be great if Stata ran the dofile editor in a separate thread and also ran a copy of the dofile, not the original. Now a dofile is locked up if it is used in a different stata instance, which complicates working on dofile while they are running on a cluster for example.

[Austin Drenski]

For what it's worth, you can use external text editors to create dofiles (they are just text files with a .do extension). Of course they might not be complete with regards to command highlighting and so on. You can then simply type "do <path>/<dofilename.do>" in the command window once you've saved the dofile in the text editor.

Regardless, it would be great if Stata ran the dofile editor in a separate thread and also ran a copy of the dofile, not the original. Now a dofile is locked up if it is used in a different stata instance, which complicates working on dofile while they are running on a cluster for example.

Your point is well-taken. Some members of my team do choose external editors (e.g. Notepad++ or VS Code) in place of duplicate Stata instances. So while the problem can be worked around, it's certainly a point of friction that is far less pronounced in other IDEs.

Having Stata execute a read-only copy of the do-file would also be a useful improvement to allow for editing and saving while the do-file is being executed.

[John Grove]

1. Ability to have more than one dataset open at the same time without needing to resort to tempfile.

2. Ability to use local macros without running all of the DO file at once.

[Marc Kaulisch]

From this thread: http://www.statalist.org/forums/foru...e-api-in-stata
and in my own experience Stata 14 is missing a way to communicate with an API that needs a SSL connection.
Be honest I expect StatCorp to do it anyway because that is state of the art in 2017 but if they don't I wanted to have raised my hands for it.

[wbuchanan]

Marc Kaulisch by an SSL connection are you referring to requests made over HTTPS? If so, Stata 14 already handles that. If you make a request via HTTPS Stata 14 spins up the JVM and handles the request using some internal Java code (if you net install a package with a Java binary from an HTTPS endpoint you'll need to restart Stata in order for the binary to be visible on the classpath). If you're referring to some other type of authentication (e.g., JSON tokens, OAuth 1/2, etc...) there would need to be a bit more involved since it would need to handle any exceptions from the end point during authentication or from issues with the web servers themselves (e.g., 404 errors, etc...).

[wbuchanan]

John Grove your #2 request is already taken care of. Just define the local macros in the command window instead of the do file editor.