[Rich Goldstein]

in addition to, and better than defv, are some programs written by Maaren Buis; see http://www.stata.com/statalist/archi.../msg01294.html

[Marco Savegnago]

Nick, Rich,
thanks for pointing this out.

Marco

[Ariel Karlinsky]

I wish that stata would be better fitted by default to the large screens the vast majority of us uses. variable names should not be shortened (with the dreaded ~) unless instructed to. column width in different tabulation commands (table, tabulate, summarize, etc.) should fit automatically and not break names into several lines.

[Nick Cox]

Where are the data supporting the "vast majority"? Masses of experienced Stata users I know (that's equally unquantified) use Stata on small laptops as a matter of routine. The (small) point is that any discussion here is not well served by unsubstantiated wild assertions!

I think that what you want will come sooner or later in terms of optional settings but it's not trivial to implement this across a large number of commands. Naturally I can't tell you when.

[Ariel Karlinsky]

Your'e right of course, I do not have any data on the common/mean screen size of modern stata users
I think my suggestion still holds though: even stata users with laptops (and small screen laptops at that) today probably use them at high resolution. also, setting font size seems to me like a much better option than stata's shortening and line breaking...

[Jesse Wursten]

If anything, it would be great if the summarize command allowed a varwidth option analogous to estimates table. sum remains one of the easiest ways to quickly count the occurence of binary variables (that was a horrible description, but I think you know what I mean). But the table it produces quickly becomes illegible if many of the variables have long names. E.g. we run a lot of tests on our data, which have fairly long names as they need to convey a lot of information to a wider audience than the programmer (and variable labels are not a particularly useful solution in this situation). Running sum test* leads to a table filled with test_~c14 for example, where the underlying variable is test_ratioExpenditureRdhc14. My screen is sufficiently wide to show this name and all the output of the sum command, but the only way to get such ouput on the screen that I've found is a more elaborate tabstat command.

And I would be surprised if more than 5% of the Stata users know of tabstat's existence whereas everyone I've met so far was taught about summarize (but that of course, is simple conjecture).

[Nick Cox]

It's not quite the same problem but I have a problem with trying to read illegible output on Statalist approximately 100 times more often than output being too large. That's partly down to advancing age, etc., but mostly down to the monitor sizes I use (down to phones; certainly the latter are irrelevant to your proposal).

(I really do have a memory for what I find difficult..., even if not a dataset.)

[wbuchanan]

Although it can be done manually, I think some way of wrapping value labels in graphs - in particular - could be a great feature to add. In education in the US, some of the regulatory language can get fairly long (i.e., Native Hawaiian or Pacific Islander) and having intelligent breaking that would fit the labels to the marks would definitely make it easier to avoid iterating through formatting graphs.

[Kazi Bacsi]

There's this extremely useful feature of replace that the number of real changes are reported. For debugging it would be also nice to introduce something similar for rename and drop, for such guys as me, who tend to use * without the necessary caution. Like "n variables were renamed/dropped". What do you think?

[Clyde Schechter]

I don't know if this quite serves your purpose, Kazi, but -rename- has a -dryrun- option that will show you exactly what will be -renamed- to what without actually changing anything. I don't know of anything analogous for -drop-, though.

[Jesse Wursten]

While we're on that topic, one thing that'd be great for code testing purposes would be a replace..., generate(varname) option, where the variable generated indicates if the variable was changed. This would make it a lot easier to debug and check whether the code does what you think it does. (of course, this can be done in a user program)

[Tim Morris]

Here is my wishlist for a simulate upgrade which would make it fit for use in non-trivial simulation studies:

1. Include an option (ideally default) to post the repetition number
2. Allow simulate to save strings, e.g. scenario names rather than numbers
3. Allow saving of c(rngstate) to be saved for each rep (this is contingent on 2 – it is >5,000 character string so would be strL)
4. Allow multiple rows of data to be created within a rep: if two methods are applied to one simulated dataset, allow two rows of results to be save for that rep, one for each method (wide format can be unwieldy for large simulation studies)

(See here for the shortcomings of simulate and how the post commands beat it for serious simulation studies)

Thanks, Tim

[wbuchanan]

Support for SQL_VARIANT types in ODBC commands. I thought I was going to be able to pull off some nice/slick backend tricks with a SQL function to return labeled or unlabeled values but when I tried calling it from Stata I ended up getting:

. odbc lo, exec("SELECT a.* FROM dbo.F_DEMO_ENROLL('10/01/2016', '10/31/2016', DEFAULT) AS a") dsn(fcpsbb)
note: grade is of a type not supported in Stata; skipped
note: sex is of a type not supported in Stata; skipped
note: race is of a type not supported in Stata; skipped
note: swd is of a type not supported in Stata; skipped
note: ell is of a type not supported in Stata; skipped
note: frl is of a type not supported in Stata; skipped
note: tag is of a type not supported in Stata; skipped
note: gap is of a type not supported in Stata; skipped
note: hhm is of a type not supported in Stata; skipped
note: migrant is of a type not supported in Stata; skipped
note: section504 is of a type not supported in Stata; skipped
note: immigrant is of a type not supported in Stata; skipped
note: refugee is of a type not supported in Stata; skipped

The reason for the SQL_VARIANT casting was to maintain consistent logic/business rules for the data returned by the function and facilitate the data being used on the back end for reporting purposes as well as importing it into Stata with less memory overhead (e.g., not having 37 character long strings in a variable but having a TINYINT type that is returned as a SQL_VARIANT type).

[Anders Alexandersson]

I wish better protection of the stata.trk file to prevent duplicate entries. I reported the problem here.

[Sergio Correia]

I wish better protection of the stata.trk file to prevent duplicate entries. I reported the problem here.

To work around the bug, I always uninstall before installing.

EG

cap ado uninstall somepackage
ssc install somepackage

... some weeks later

cap ado uninstall somepackage
net install somepackage, from(SOME_FOLDER)