[John Mullahy]

A small wish would be to expand the built-in symbolstyle options for msymbol(...) in twoway scatter. For example

- # *

etc.

[Clyde Schechter]

While I can certainly appreciate the value of enabling detailed control over the production of .docx and .pdf files from within Stata, this might prove to be more trouble than it is worth. While I think the Adobe .pdf file format has been pretty stable for a long time, Microsoft has a habit of introducing new "features" with some frequency. And now that they are moving to a new business model where you rent the software and they automatically upgrade you at their whim, even if you would prefer to keep what you have, StataCorp might find itself having to devote excessive resources to revising Stata every time Word gets changed. In my view, that might come at the expense of being able to improve the statistical and data management functions, or result in a steep price increase for Stata.

In saying that, I realize that my perspective is influenced by a workflow in which I keep most of my output in the form of data sets, spreadsheets (for which -export excel- does everything I need) and .smcl files and only occasionally need to present the results in Word or PDF documents. So your mileage may well vary from mine.

[Leonardo Guizzetti]

I would like to see more formatting options for tables and cells in putdocx and putpdf. For example, manually specifying column widths, or applying cell formatting to multiple cells at once.

[Sonnen Blume]

#178

Editing variable names, labels, etc.



I think I see what you want. That seems to go with having much bigger, or more, monitors than many of us have. Otherwise put, needing space to do such editing is why

varm

is the way it is.

Documenting good examples



Thanks for the positive comments. Again, my reaction is not that this would not be good, but rather that there are already many ways of providing broadly similar public resources.

I'll mention first the StataCorp FAQs. As should be apparent, StataCorp are entirely positive about community-contributed FAQs. A long while ago, there were suggestions that someone should monitor Statalist and encourage turning the best postings into FAQs. Long story short, this hasn't often happened, but there is no reason why people should not encourage this.

Now the Stata Journal. The Stata Tips are designed largely for this purpose. I'll put on a hat here as the Editor who tends to deal with those and encourage submissions. Under a related heading, I will give a couple of personal examples. Clyde Schechter and I recently tried to distill the essence of many threads on handling strings and of generating indicator variables into fairly detailed surveys (yet not, we hope, too long or too difficult for users seriously wanting to understand). The string piece came out in SJ 18(4) and the indicators piece should come out in SJ 19(1). Indeed many of the Speaking Stata columns are reactions to repeated threads on Statalist.

There are many ways to promote good practice. Whether we need another is a good open question.

Graphical requests

Graphs (1) (2) are already programmed or programmable easily in Stata. The desire behind (3) I've met in a different way with corrtable (SSC). I'd suggest that you post a new question on (1) and (2) which I will answer, as nothing depends on StataCorp adding future functionality.

(4) and (5) lie beyond my interests, so I have nothing to say; what do others think?

Thanks for your detailed response! I'll make a new post for making Graph 1 and 2.

[Richard Williams]

If you would be copying commands from within Stata, it is already possible to select any arbitrary set of entered commands from the Command Log (either either by holding Ctrl or Shift while selecting) and a simply copy and paste (Ctrl/Cmd+C, Ctrl/Cmd+V) will copy those commands as plain text.

The command log won't show commands executed from a do file, although they may appear in the output.

These are trivial problems that you can work around but I'd prefer they not be problems at all. Why can't Stata just consistently ignore leading periods?

[Leonardo Guizzetti]

What would be nice is another Copy option (in addition to Copy as table, Copy as HTML, etc.) that allows one to Copy commands (without the leading periods). That's not exactly what you asked for in #181, but it would have the same effect.

If you would be copying commands from within Stata, it is already possible to select any arbitrary set of entered commands from the Command Log (either either by holding Ctrl or Shift while selecting) and a simply copy and paste (Ctrl/Cmd+C, Ctrl/Cmd+V) will copy those commands as plain text.

I don't know why Stata's command interpreter appears to selectively mask/ignore a leading period for some commands and not others, but maybe this can be made more consistent as a partial solution to these annoyances.

[Bruce Weaver]

Thanks. You can also just delete the period before the *. But the point is, if you’ve copied the code from somewhere, you’d like it to run as easily as possibly without having to do any tweaking of it.

I get that, Richard, and have had similar thoughts myself more than once. I was just thinking that henceforth, I may have to switch to // in my own code where I have previously used * to mark comment lines. (A double-tap on the / key is probably easier than Shift-8 to produce * anyway!)

But even that doesn't necessarily eliminate all of the editing that might be required. E.g., the output from

sysuse auto, clear
// Model 1
regress mpg price

is:

. sysuse auto, clear
(1978 Automobile Data)

. // Model 1
. regress mpg price

So even after using Search & Replace to replace <. > with a blank, one would still have to delete (or comment out) the line showing the file label info.

What would be nice is another Copy option (in addition to Copy as table, Copy as HTML, etc.) that allows one to Copy commands (without the leading periods). That's not exactly what you asked for in #181, but it would have the same effect.

Cheers,
Bruce

PS - Shortly after posting that reply, it occurred to me that we may frequently be copying Stata output from sources other than the Stata output window (e.g., web-pages). And in those cases, having a Copy commands option in Stata won't help!

[Richard Williams]

Thanks. You can also just delete the period before the *. But the point is, if you’ve copied the code from somewhere, you’d like it to run as easily as possibly without having to do any tweaking of it.

[Leonardo Guizzetti]

Re #181 and #182, using C-like "comment blocks" (/* and */) also gets around the problem. Modifying Bruce's example code also works:

. sysuse auto, clear
. /* Model 1 */
. regress mpg price

[Bruce Weaver]

Re #181, using // in place of * gets around the problem. E.g., the following code runs without error:

. sysuse auto, clear
. // Model 1
. regress mpg price

[Richard Williams]

On the trivial but annoying side: I often copy from a handout or the output screen things like:

. use "https://www3.nd.edu/~rwilliam/statafiles/logist.dta", clear
. * Model 1
. logit  grade gpa tuce psi

The problem is that lines like the second, which start with a period followed by an asterisk, produce errors:

. . * Model 1
* is not a valid command name
r(199);

Other Stata commands don't mind if they are preceded by a period but comments do. I would therefore like lines with a period followed by an asterisk to also not produce errors.

[Nick Cox]

#177 How best to suggest to StataCorp that they provide some resource? Use [email protected]. Nothing much is easier than forwarding an email to someone better fitted to do the job!

[Nick Cox]

#178

Editing variable names, labels, etc.

varm takes to a separate window for editing. By editing label names directly on variable menu, I meant editing on the window that shows the variables and labels on the right side of the interface.

I think I see what you want. That seems to go with having much bigger, or more, monitors than many of us have. Otherwise put, needing space to do such editing is why

varm

is the way it is.

Documenting good examples

I find Statalist extremely helpful, and perhaps the most helpful of this kind on the internet, still I find the website containing the example charts more efficient and organised. I see many contributors like Nick, Clyde end up doing too much work, everyday, and sometimes have to answer the same questions which is inefficient. This can be avoided greatly by having an online repository of codes where people can share their reproducible examples, once for all. Greater good for greater number!

Thanks for the positive comments. Again, my reaction is not that this would not be good, but rather that there are already many ways of providing broadly similar public resources.

I'll mention first the StataCorp FAQs. As should be apparent, StataCorp are entirely positive about community-contributed FAQs. A long while ago, there were suggestions that someone should monitor Statalist and encourage turning the best postings into FAQs. Long story short, this hasn't often happened, but there is no reason why people should not encourage this.

Now the Stata Journal. The Stata Tips are designed largely for this purpose. I'll put on a hat here as the Editor who tends to deal with those and encourage submissions. Under a related heading, I will give a couple of personal examples. Clyde Schechter and I recently tried to distill the essence of many threads on handling strings and of generating indicator variables into fairly detailed surveys (yet not, we hope, too long or too difficult for users seriously wanting to understand). The string piece came out in SJ 18(4) and the indicators piece should come out in SJ 19(1). Indeed many of the Speaking Stata columns are reactions to repeated threads on Statalist.

There are many ways to promote good practice. Whether we need another is a good open question.

Graphical requests

Graphs (1) (2) are already programmed or programmable easily in Stata. The desire behind (3) I've met in a different way with corrtable (SSC). I'd suggest that you post a new question on (1) and (2) which I will answer, as nothing depends on StataCorp adding future functionality.

(4) and (5) lie beyond my interests, so I have nothing to say; what do others think?

[Sonnen Blume]

#168 (2) Please give an example of a graph you want that you think Stata can't do. There are many kinds, no doubt, but StataCorp really need a more precise wish list than that.

(5) Do you know about varm ?

(6) Statalist exists for this purpose, and others. If you can find a way to insist that people only post reproducible problems, that would be good. It would save a lot of time and effort.

Thanks so much for your point-by-point reply!
varm takes to a separate window for editing. By editing label names directly on variable menu, I meant editing on the window that shows the variables and labels on the right side of the interface.


2& 6) Here is one example of online chart list that I use most often: https://www.surveydesign.com.au/tipsgraphs.html

I find Statalist extremely helpful, and perhaps the most helpful of this kind on the internet, still I find the website containing the example charts more efficient and organised. I see many contributors like Nick, Clyde end up doing too much work, everyday, and sometimes have to answer the same questions which is inefficient. This can be avoided greatly by having an online repository of codes where people can share their reproducible examples, once for all. Greater good for greater number!

Here are a few examples of charts offered by R that I find very useful:

1) Lolipop instead of bars that are more elegant to the eyes + facet wrap option by separating the bars by color that makes reading the chart a pleasure:

2) Showing the difference between two estimates:

3) Correlation plot:

4) Decision tree:

5) Choropleth charts:

Stata has the option to do so with shp file, which makes the task complex when only selected regions are aimed e.g. west africa. Having to depend on shp file is hard and can be avoided if Stata povides a built in function for this, like Excel 2019 is providing in a single click which even can recognise the country automatically from the names of the regions:

[Joro Kolev]

Nick Cox , what is the best way to request from Stata Corp experts that they teach us some particular topic, say on the Stata Blog, or as an article in Stata Journal?

David M. Drukker (StataCorp) for example has a brilliant sequence of "Programming an estimation command in Stata" entries.

I would like to read such an expose on Programming a linear system estimator in Stata, which is up to date with modern Stata.