[Shen YANG]

Not sure if anyone has already posted similar suggestion.
It would be nice if Stata 19 could automatically prompt the available options for each command user types in the command window.
As a simple example, if user typed "tab xxxx", then a small window will pop up with hints of the available command options (e.g., nolabel, missing...)

[Nick Cox]

#106

I would say that the menu is intended to do something similar (but not identical).

How would this (be expected to) work if there are hundreds of possible options?

Oddly, or otherwise, very few community-contributed commands come with menu flavour. Take your pick between (1) that's more work for the programmer(s) (2) the programmer(s) are overwhelmingly committed to the language and following help files and other documentation.

[Bruce Weaver]

Adding to Nick's comment about using the GUI in #107, one can use -db commandname- to open the desired dialog directly.

[Jamel Saadaoui]

Hi All,

That would be great to adapt this Toolbox: https://econpapers.repec.org/softwar...de/s458992.htm in Stata 19.

For those working in time series econometrics.

Kind regards,
Jamel Saadaoui

[Shen YANG]

#106

I would say that the menu is intended to do something similar (but not identical).

How would this (be expected to) work if there are hundreds of possible options?

Oddly, or otherwise, very few community-contributed commands come with menu flavour. Take your pick between (1) that's more work for the programmer(s) (2) the programmer(s) are overwhelmingly committed to the language and following help files and other documentation.

Thanks for the comments. My idea was just sourced from some generic IDE environments (e.g., VScode)
They are good for giving hints to users when they enter some functions.
Of course, extending this topic, we can also imagine that some newer AI tools (e.g., CodePilot) might be better for Stata programming efficiency.

[Tobias Renkin]

- Native support for reading / writing parquet files.

- Better support for external editors (VS code, sublime, etc.)

More generally: STATA is an excellent econometrics package. In everything else - graphing, data management, GUI, etc. etc. it is hopelessly lagging behind the (mostly open source) competition. I think STATA would benefit from just focusing on what it is good at - econometrics - and building easy interfaces to other software for the rest.

[Nick Cox]

#111 is an expression of opinion. and largely unsubstantiated, but I will comment first on what I think are factual errors.

The correct spelling is Stata.

More importantly, Stata is not intended to be an econometrics package. No-one should forget or downplay its support for many kinds of statistics. I need only mention its massive support for many procedures in biostatistics or medical statistics to make the point.

One problem with external editors is that there are so many of them -- and they come and go, not quite like flowers, but with sufficient turnover to make investment in resources by StataCorp a far from obvious move. I have no interest in Stata supporting any external editor I don't use, and anyone could -- strongly, should -- feel exactly the same about the external editor I do use. So, I disagree concretely on that point: this is and isn't selfish, unless you can identify an external editor used by a majority or strong plurality of users.

[daniel klein]

#111: Can you name one software package that is better than Stata "[i]n everything else - graphing, data management, GUI, etc."? In which (objective) sense is this software better? I prefer using one software package that does a pretty decent job regarding all of these aspects over using different software packages, each specializing in another area. You may beg to differ. If you do, name the software that you want interfaces to. Perhaps others like your specific suggestions.

[FernandoRios]

In terms of Graphics. I do Agree Stata could be a bit more flexible. After some conversations with the Stata Developers, they do agree it may need to be upgraded.
The problem, however, is that it would require a complete restructure of the current environment.
Like you say Tobias Renkin , for people who want other plotting options, there is python with all their libraries. So there are other options.

[Hao Xu]

Add an option to allow dpi customization when exporting images.

[Kong Chantha]

Dear Prof,
I have one question related to estat sbcusum in ARDL in ECM form. after running ARDL in ECM form and then run estat sbcusum,

why dose it get error in function as below?

. estat sbcusum
sbs_est_cusum(): 3301 subscript invalid
<istmt>: - function returned error

Thank In advance

[Leonardo Guizzetti]

Dear Prof,
I have one question related to estat sbcusum in ARDL in ECM form. after running ARDL in ECM form and then run estat sbcusum,

why dose it get error in function as below?

. estat sbcusum
sbs_est_cusum(): 3301 subscript invalid
<istmt>: - function returned error

Thank In advance

This thread is for posting requests for the next version of Stata. You seem to have a question that seeks help, so you should make a new thread to ask for it.

[wbuchanan]

Stata's graph system is very slow: try producing a few hundred graphs in a loop. Moreover, to make a complicated graph can require a rather long (convoluted?) command.
Stata now has Python integration.
Proposal: Build a native Stata hook into matplotlib. Make the syntax as comparable to Python's object-oriented matplotlib syntax as possible. I would rather not have to combine Python and Stata code in a do-file. That's why I suggest a native Stata hook straight into matplotlib.

I don't think the concept that Brian is advocating for is bad, but I'm not sure I would use matplotlib as the example. There are higher level APIs that seem to have simpler and easier to use interfaces that might make a transition like that a bit easier for more users, as well as other libraries that are either better optimized for performance, better optimized for user interactivity, or both.

[Adrien Bouguen]

having a replace option for encode (i.e. already exists in ssc sencode but really this is needed for this specific command

[Ernesto Vincenti]

1. I strongly second Daniel Feenberg's suggestion for Parquet integration.
2. On graphics, it would be nice if changes made using the Graph Editor UI were then shown as code in the terminal. Exactly in same manner menu-based data and statistical commands are just frontends for underlying Stata code that we then see implemented. This way, if we don't know a particular graph option, we can "learn" how to code it correctly through using the Graph Editor.