[Xiaogeng Xu]

I wish two things to happen in Stata 18. First, the bookmarks can be made in different levels, i.e. level 1 and level 1.1. Second, the length limit in rename option can be longer. For instance, when I esttab using tex file, I may need latex math symbols ($\times \text{treatment}$) that can take some digits and it returned an error.

[Mead Over]

Asjad Naqvi and daniel klein , I think that Asjad might be referring to variable labels, not value labels. It would often be useful to have a way to retain (perhaps a slightly altered version of) variable labels after either -reshape- or -collapse-. I posted a program to do this on CGD's Stata website as -retainlbl-:

view net describe retainlbl, from(http://digital.cgdev.org/doc/stata/MO/Misc)

I designed version 2.0 of -retainlbl- to be run on the variables prior to executing either -reshape- or -collapse-, which would store the variable labels with the variable names in global macros. Then the user would again run -retainlbl- after completing either -reshape- or -collapse- to restore the variable labels, or perhaps slightly modified versions of those labels. This approach is consistent with -reshape-'s use of variable -characteristics- and global macros to store information on the -reshape- so that it can be reversed.

By the way, the help files for -reshape- and -collapse- could be improved by describing how these two commands deal with variable and value labels. In all versions through 17, the word "label" is absent from both help files. The PDF documentation for -reshape- is also silent on labels, while that for -collapse- says "collapse adds meaningful variable labels to the variables in this new dataset." I don't like Stata's version of a "meaningful" variable label. I frequently prefer to keep the same unchanged variable label or to add my own prefix or suffix to the existing variable label. (See the -retainlbl- help file for further detail.)

[Ali Atia]

Strongly agree with wbuchanan's recommendation in #382, but note that the ustrregexm() function using pipe operators (|) can serve a similar purpose to inlist() without the element limitation.

[FernandoRios]

FernandoRios: the 15 color limit was exactly the reason for writing the Customizing colors schemes guide to push any number of colors onto the graphs. But here they are mostly to show ranking through graduated colors. Otherwise 15 colors are sufficient but the I agree the functionality should be there and left for the users to decide.

wbuchanan: definitely agree! inlist should allow longer lists. It is a weird roadblock.

Yes, I also have my own solutions on some of my own programs. I do agree 15 colors is more than enough for many applications, which is why this is more of a real wish list, not needed for most users

[Asjad Naqvi]

If you find the time, could you open a new thread and post a reproducible example? This thread (Wishlist) is not the place to discuss such details.

I have re-run my linked example in both Stata 13 and Stata 17, and each time all labels are there. Perhaps the problem is related to the edition of Stata and/or the OS. I do not have a MP editon and I am on Windows 11.

I was just responding to your post about your claim that this is a bug. But please free to start a thread on this separately since a lot of people will benefit from this.

[daniel klein]

The feature doesn't exist in Stata 13, Stata15, and Stata 17. I just checked in all of these.

If you find the time, could you open a new thread and post a reproducible example? This thread (Wishlist) is not the place to discuss such details.

I have re-run my linked example in both Stata 13 and Stata 17, and each time all labels are there. Perhaps the problem is related to the edition of Stata and/or the OS. I do not have a MP editon and I am on Windows 11.

[Asjad Naqvi]

We cannot be sure to which exact problem you are referring. I suspect it is related to the behavior of Stata 17, losing value label definitions after reshape, which came up in another thread. If so, then this appears to be a bug and it should be fixed before Stata 18.

The feature doesn't exist in Stata 13, Stata15, and Stata 17. I just checked in all of these.

I read your post for Stata 16 suggesting it does preserve the labels. But I don't remember this and I have since upgraded to v17 so I cannot verify. I wrote this article on customized bar graphs for preserving labels after reshape using Stata v16.1 and it didn't have the label option and one had to jump through hoops to pass it on after reshape.

[daniel klein]

Please have an option to preserve labels after reshape!

We cannot be sure to which exact problem you are referring. I suspect it is related to the behavior of Stata 17, losing value label definitions after reshape, which came up in another thread. If so, then this appears to be a bug and it should be fixed before Stata 18.

[Asjad Naqvi]

Please have an option to preserve labels after reshape!

[Asjad Naqvi]

FernandoRios: the 15 color limit was exactly the reason for writing the Customizing colors schemes guide to push any number of colors onto the graphs. But here they are mostly to show ranking through graduated colors. Otherwise 15 colors are sufficient but the I agree the functionality should be there and left for the users to decide.

wbuchanan: definitely agree! inlist should allow longer lists. It is a weird roadblock.

[Asjad Naqvi]

Can we have version checks for user-written or SSC programs please especially when programming ados. For example, if a program calls another program, then, it should flag the user if he/she is using an older version of an already installed program and should upgrade it.

I sometimes get queries that packages have broken down. But this is usually because users have not upgraded Ben Jann's palettes package, etc.

"ado update" already does this checking, so the underlying functionality is there.

[wbuchanan]

Make the number of elements passed to the -inlist()- function significantly larger. Being able to include only 7 string tokens at a time is a bit odd. I imagine the restriction might be related to some underlying code written in C or something like that, but it would be great to be able to pass lists of arbitrary length to the function that would work regardless of the type of the elements.

[Nick Cox]

I've wanted the suggestion in #380 of jitter() in one dimension only.

#380 has specific reference to stripplot from SSC, in which height() width() msize() and msymbol() all offer handles to turn.

jitter() also comes for free as part of standard scatter options, but I don't willingly use it with stripplot. I would rather use the stack option.

stripplot is best for small or modest sample sizes where the principle of each data point being shown by a visible marker symbol not only makes sense but works legibly.

[Molly Jeffery]

This is small, but would be really useful: ability to jitter scatterplot points by different amounts in the x and y directions. When I create stripplots, it would be nice to be able to spread out the points horizontally without distorting the y-value

[Nils Enevoldsen]

I'd like a native compressed DTA file format.

For my DTAs larger than a couple dozen megabytes, zstd typically compresses by about 90% in a fraction of a second at the standard level. For smaller DTAs, the typical compression I see is about 50%. (This is after gathering the low-hanging fruit of casting variables to appropriate types.) Fancier variations are possible, but it seems pretty straightforward to support a “.zdta” format that is literally just a compressed .dta.