[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

[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

[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]

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.

[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

[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.

[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

[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

[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.

[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')

[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.

[Jesse Wursten]

See this thread for a discussion:

https://www.statalist.org/forums/for...ng-set-matsize

I would like to do what you did if I can be convinced it won't hurt me, but there are differing statements on this.

Ah, good to know.

An unrelated request for Stata 16. This may be a Microsoft Windows thing, but imagine you create three instances of Stata. Then you will have Stata, 2 - Stata and 3 - Stata as window titles. This is great. What I would thoroughly appreciate is that the same applies to dofile editors and data browsers. That is, if I type browse in 2 - Stata, then I'd like the browse window to be 2 - Data Browser and doedit leads to 2 - Do-file Editor.

Now, I often have multiple instances of Stata open which I can tell apart, but lose track of which browse and dofile editor window corresponds to which Stata. Especially when you try to do some manual parallelisation or are just working on multiple similar datasets at the same time, this gets confusing quite quickly.

EDIT:
Stretch goal 1: move the name of the dataset loaded to the front of the window titles
Stretch goal 2: let us name the windows ourselves (potentially as option in the use command)

[Richard Williams]

Is there even a reason you can set a lower matsize? I did set matsize 11000, permanently at some point and I don't think that's ever hurt me in any way?

See this thread for a discussion:

https://www.statalist.org/forums/for...ng-set-matsize

I would like to do what you did if I can be convinced it won't hurt me, but there are differing statements on this.

[Jesse Wursten]

Stata frequently tells me I need a bigger matsize for the problem I am running. So, I give commands like

set matsize 7500

This is a pain. When I run equivalent models in Mplus or lavaan, they don't whine at me about such things. I wish Stata could just set the matsize dynamically. Or at least give better messages about what the matsize needed to be set to. I don't want to experiment to have to figure out what the optimal matsize is for every problem.

Is there even a reason you can set a lower matsize? I did set matsize 11000, permanently at some point and I don't think that's ever hurt me in any way?

[Richard Williams]

Stata frequently tells me I need a bigger matsize for the problem I am running. So, I give commands like

set matsize 7500

This is a pain. When I run equivalent models in Mplus or lavaan, they don't whine at me about such things. I wish Stata could just set the matsize dynamically. Or at least give better messages about what the matsize needed to be set to. I don't want to experiment to have to figure out what the optimal matsize is for every problem.