[Richard Williams]

FYI, I get really confused when I have multiple Stata windows. I too would like an easy way to keep the windows straight.

[E. David Aja]

I wish inlist() could accept more string arguments; it would be quite convenient to be able to do something like

levelsof x, s(",") local(foo)
keep if inlist(y, `foo')

[Sergio Correia]

I wish inlist() could accept more string arguments; it would be quite convenient to be able to do something like

levelsof x, s(",") local(foo)
keep if inlist(y, `foo')

E. David Aja

I often have that problem, so I wrote a quick solution (available within the ftool package in SSC):

* ssc install ftools
sysuse auto
levelsof make
local_inlist make `r(levels)'
di `"`inlist'"'
cou if `inlist'

Basically, -local_inlist- constructs a string of multiple inlists, so you don't have to worry about the limit. It also supports labels.

[Jesse Wursten]

This has probably been requested a thousand times already, but I would really like to see a table of contents in dofiles. Imagine if you could divide your code into (sub(sub(sub)))sections and that the dofile editor would read this and provide a table of contents window. Wouldn't that be great? You could click on the titles in the toc window to immediately go to this section. Maybe you can even collapse them (but now I'm daydreaming). The TOC can then immediately serve as a summary of the dofile - if you name your headings properly, you can see in one glance what the dofile does from a global perspective. The syntax could be super simple, e.g. *# is a section, *## is a subsection.

In my dofiles, I do this to some extent by using * for section ** for subsections and so on, but I still need to create the summary myself. As a result, 9 times out of 10, the summary is horribly outdated and incomplete... I feel implementing this would lead to a) more structured code, b) better readability of code and c) as far as I can tell an almost absolute first for Stata amongst programming languages.

PS: This is what the outline looks like in Google Docs

[Anders Alexandersson]

Jesse Wursten
You can use the LaTex command \tableofcontents together with the new user-written command markstat (SJ 17-3).

search markstat

Specify the command at the top of the Stata Markdown (.stmd) file.

\tableofcontents

[E. David Aja]

E. David Aja

I often have that problem, so I wrote a quick solution (available within the ftool package in SSC):

* ssc install ftools
sysuse auto
levelsof make
local_inlist make `r(levels)'
di `"`inlist'"'
cou if `inlist'

Basically, -local_inlist- constructs a string of multiple inlists, so you don't have to worry about the limit. It also supports labels.

This is great; thank you.

[Daniel Bela]

There have been a few mentions about extending Stata's do-file editor here (and on previous wish lists as well).

I want to second some of them: It would be fantastic if Stata's do-file editor would introduce even more IDE features (the project feature already is really helpful in larger projects).
The most important additions I would like to see are (in the order of importance for me):

1. integration for version control systems (git, bzr, svn at least; a customizable variant to manually integrate any VCS would be ideal, of course)
2. automated detection of nested documents (sub-do-files that are integrated via include, do or run), and a neat way to open them (without having to add them to a project file)
3. availability of adding a "monitored" directory to a project file, auto-adding all files that are created in this directory to the project (even if they are created later on)
4. a way to structure do-files in the way that Jesse Wursten wished in #34: have some comment convention to mark sections in do-files (via markdown? or simple magical comments like *!Stata section: BLABLA), and then give us the possibility to display a table of contents-pane for navigation; this also would be a possible way solve the request to have permanent bookmarks

I would really love to see such features in the do-file editor.

Regards
Bela

[Jesse Wursten]

I would like the collapse command to accept prefix/suffix-like syntax instead of only targetvarname = varname.

E.g. the code below would calculate the mean of the DL_* variables and then store the (weighted) share of observations used in used_*.

collapse (mean) DL_* (count) used_* = DL_* [iweight = weightvar], by(month)

As added bonus, it would be great to have a rawcount similar to rawsum. Or even better, make the [weight] option only apply to the variables that precede it, with potentially many different weights specified.

As an added added bonus, it would be great if some of the main functions could be moved to mata/C, like the user-written commands fcollapse and gcollapse which can easily be ten times as fast. Unfortunately, neither supports weights at the moment.

[Sergio Correia]

fcollapse supports weight (at leat the Github version does). gcollapse doesn't, but it shouldn't be very hard to implement it (just look for the ~10 lines in fcollapse that depend on weights and add them).

As an aside, I would *really* suggest people to switch to gtools instead of using the default Stata commands. With ftools I get a 4x or higher speedup, but gtools is a completely new ballpark.

[Jesse Wursten]

Ah, indeed the version on github supports weights, the one on SSC does not yet. I fully agree with switching to gtools whenever possible - a collapse of four variables in a medium sized dataset (8M obs) went 5x as fast using gcollapse compared to collapse and that's on the lower side of the speed gains possible.

   1:     10.23 /        1 =      10.2340 // gtools
   2:     34.05 /        1 =      34.0460 // ftools
   3:     52.70 /        1 =      52.7020 // collapse

[John Mullahy]

Please consider this thread's discussion from several months back on the possibility of adding some sort of discrete option to twoway contour...heatmap.

https://www.statalist.org/forums/for...ontour-heatmap

[Daniel Bela]

Did someone already mention (again) something like import spss and export spss?
(Or import pspp and export pspp, if that's easier to implement, as the PSPP data format documentation is freely accessible.)

If yes: bump.
If no: It would be really helpful for data exchange with non-Stata users. There are several user written commands that try to fill this gap (most notably Sergiy Radyakin's usespss and savespss), but none of them work flawlessly with modern Stata versions, or on non-Windows operating systems, or do not support conversion of characteristics, or require an instance of SPSS or Stat/Transfer installed. The current situation, if you're in need to exchange data with SPSS users, is unsatisfactory.

Regards
Bela

[Weiwen Ng]

In the absence of Stata buying MPlus, I would like to see some additional postestimation statistics added for latent class/profile methods. Normalized entropy and sample size-adjusted BIC would be convenience features. You can program SSBIC quite easily, discussed more below. There was some recent discussion on how to do entropy as well.

I would particularly like to see an implementation of the Lo-Mendell-Rubin adjusted likelihood ratio test. This compares a model with K classes with a model with K-1 classes; the difference in -2*log likelihood does not follow the usual chi square distribution for reasons I don't understand but the linked article explains. Then, automating the bootstrapped LR test described in the paper linked would be very nice. It appears that the bootstrapped LR test is the current gold standard for model selection.

That said, it appears like the adjusted BIC is also acceptable, and that's very easy to calculate. This code should do it:

webuse gsem_lca1
gsem (accident play insurance stock <- ), logit lclass(C 2)
scalar SSBIC_class_2 = -2 * e(ll) + e(rank) * ln((e(N)+2) / 24)
di SSBIC_class_2

In the above:
e(ll) is the log likelihood.
e(rank) is, I believe, the number of parameters.
e(N) is the sample size.

[Nigel Moore]

I'm sure that there's a 'good reason' for the arcane choice of units in graphs. I'm equally sure that there are many users that would like to keep it 'just so'.

But for those of us publishing in the scientific literature, where line art requirements are dictated in metric units and point sizes, inches and 'teeny tiny' are not really helpful.

In deference to those who prefer it 'just so', it would be nice to at least have a preference option for metric/points.

[Tom Snell]

A feature I would find incredibly useful would be auto-complete suggestions for existing variables names within the command window and do-file editor. Similar to the way in which Excel shows a list of matching named ranges when you type the first few letters of an existing range.