[JanDitzen]

Just stumbled across this post and maybe someone else already requested it.

I usually write a lot of subcommands for my Stata programs as it helps to trace errors and test. However I sometimes find it frustrating difficult to find those programs in my ado files. When using the project browser, it would be handy if the ado file name could be appended showing all the programs and by double clicking on it, you would jump to the line the program starts.

[Chen Samulsion]

I have a question on Stata's layout. Can we dock do-file editor into command window or just replace command window with the former in main workspace? (This seems likes Matlab layout style versus Wolfram Mathematica layout style.) I used to type Stata commands in command window and then copy the right ones to do-file editor. Although this operation facilitates me to monitor immediately changes in result window, shifts between command window (or the main workspace) and do-file editor is somewhat troublesome.

[Henrique Romero]

Could we have a user-defined typing mode in the linux console (overwrite/overtype, i.e. what the "insert" key changes)? The current behavior reverts to insert mode every time a command is issued. This is not how any shell I know of works and is extremely frustrating.

If you're not what I am referring to, this post might clarify it a bit: https://www.statalist.org/forums/for...at-the-console

[Bruce Weaver]

I don't recall if it has already been mentioned in this thread, but a command to compute simultaneous confidence intervals for multinomial proportions would be useful.

Cheers,
Bruce

[Joerg Luedicke (StataCorp)]

@denversprings , please run the following commands in Stata:

window menu append submenu "stUser" "&Favorites"
window menu append item "Favorites" "&Recode categorical variable" "db recode"
window menu refresh

And then have a look at the menu "User" next to the "Statistics" menu.

For permanent use, you can put these commands into your -profile.do-.

For further information, see

help window menu

Joerg

[Ricky Gettys]

Easier way to work between datasets (This is SAS Enterprise Guide's big [and only, in my opinion] advantage over STATA). Providing an interface for navigating between datasets, even if it was a tab at the top toolbar that I could navigate between two projects easier. This would be especially useful for merges, appends, and other basic data manipulation tasks.

It would be an improvement if I were even able to distinguish between open projects easier by naming open windows. But SAS's setup of creating a work database that lets me merge as datasets are opened is really nice.

[denversprings]

Ability to create "hot buttons" or bookmarks for favorite menus -- Every user of Stata has some commands that they use semi frequently but not so frequently that they remember the command sequence (or the command sequence may be too complicated to remember). In those instances, they're forced to use the menu system or the help dialog box. For any one user, there may be just 5 or 6 of these that they would like to access more quickly. In my case -- it's the "recode categorical variable," which is rather hidden in the menu system. My recommendation, if it's possible, would be to allow the creation of "bookmarks" or "hot buttons" to one's favorite menus, much like one creates hot buttons for favorite website in one's Chrome browser. Alternatively, maybe allow users to create a customizable menu dropdown consisting of one's favorite menus.

[Bruce Weaver]

Good suggestion Petr (in #123). That would be a very nice addition for folks who use G-theory. At the moment, many of them rely on old DOS programs (written by Brennan, IIRC), wrappers for those old programs (e.g., https://groups.google.com/forum/#!forum/gstringforum), and macros that sometimes can't handle their particular designs (e.g., https://people.ok.ubc.ca/brioconn/gtheory/gtheory.html).

Cheers,
Bruce

[Petr Waldauf]

Do you plan an implementation of Generalizability theory?
(Brennan, R. L. (2001). Generalizability Theory. New York: Springer-Verlag)
Regards,
Petr

[Sergiy Radyakin]

I would like to see in a future version of Stata the Project files (*.stpr) in text format (currently binary). XML or JSON. This has been requested since the time when they were introduced:
here and here . This would be useful for automatic generation of projects and (more importantly) for versioning of code repositories.

Thank you, Sergiy Radyakin

[John Mullahy]

Would there be a way to allow negative Mata matrix subscripts to indicate exclusion of rows/columns? E.g.

mata v=1,3,6
mata y=x[-v,.]

would return y as x except for its first, third, and sixth rows. It's easy to program around this, but having the ability to build row/column exclusion directly into the matrix subscripting would be great.

[Andrea Discacciati]

It would be great to be able to run mata code line-by-line (interactively) directly from a do-file.
(Probably there are good reasons why this is not already possible, though.)

[Richard Williams]

Nick, see posts 13 on of https://www.statalist.org/forums/for...ic-regressions for an example. In that case the user-written khb routine is supposed to run under Stata 11 but wouldn't because the Mata code was compiled under 13.1. Recompiling the code under your version of Stata will solve the problem, but many people who download a program will not know that.

Version control keeps ado files working correctly with later versions of Stata, so it would be nice if that were true of Mata compiled programs too.

[Nick Cox]

Richard: What specific problems are you referring to here? Are you saying that compiled code from say 15 should work in 12 but doesn't because the compiler or other Mata internals have changed? Whose documentation is misleading?

What most user-programmers do is release their Mata source code and users don't need to know how to compile at all. There will be problems if we use Mata functions not available in their Stata.

[Richard Williams]

I wish Mata had a saveold function. You might have Mata code that would work perfectly fine in, say, Stata 12, but if you compile it under Stata 15 it won't run in earlier versions. The code has to be recompiled in the earlier version, and people using earlier versions won't necessarily know how to do that. The list periodically gets messages from people saying they can't get this or that program to run under their version of Stata even though the documentation claims the program will work with their version.

If nothing else, maybe the Mata error message when you try to run a newer version could be modified to add something like "You may need to recompile the Mata code under your version of Stata".