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

[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

[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

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

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

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

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

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

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

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

[John Mullahy]

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

- # *

etc.

[Marc Kaulisch]

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.

I am not sure how often Microsoft is changing its data format .docx but to me it looks quite stable since a few years.

I am using Stata mainly for data management and reporting tasks. Recently, I was able to create quite a number of reports with Stata automatically but it costs me a lot of time to put page numbers, header and footer into the documents. These are my feature wishes for Stata 16.

I am not sure if these features wishes are such a burden to StataCorp because it also is a market opportunity and makes it much more valuable for users like me. Especially, it keeps me away from other solutions available outside.

[Leonardo Guizzetti]

I am not sure how often Microsoft is changing its data format .docx but to me it looks quite stable since a few years.

and

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.

The Open Word XML format has been standardized, and while Microsoft does not necessary "play nice" with cross-compatability between formats, it does have a legacy of maintaining backwards compatibility for some time. For example, the ability to read and write Word 97 format .doc files are still maintained 20+ years later. Stability of the format (or a core set of format features) is important for Microsoft to be able to keep its hold over word processing.

I agree that it would not be prudent of StataCorp to try to introduce every Word feature, but something like column and row sizing is reasonably simple and can already be done by some alternative software. It's a small thing to those who don't rely on automated report generation, but it does add a nice level of polish to a final product (and can save lots of manual intervention).

I am using Stata mainly for data management and reporting tasks. Recently, I was able to create quite a number of reports with Stata automatically but it costs me a lot of time to put page numbers, header and footer into the documents. These are my feature wishes for Stata 16.

Indeed this can be done, as I have recently discovered. You make use of the -putdocx append- command, which combines multiple Words files together. Take note that the order of combination matters here, so you can make complicated reports, but it may require trial and error with the order. In the toy example below, I assume that I have a Word filed called -myheaders.docx- which contains some text in the header, and some text and page numbers in the footer. The program will take that file and combine it with one that Stata generates. One report is generating by appending the headers either first or last, and you can see that only one order produces the intended result. (I think the reason for this is that styles are accumulated based on the last file appended, but I don't know for sure and haven't investigated much.)

cd "my path here"   // put "myheaders.docx" file here

putdocx begin , pagesize(letter) font(Arial, 11, black)
putdocx paragraph
putdocx text ("This is a test.")
putdocx save "mybody.docx", replace

putdocx append "mybody.docx" "myheaders.docx", saving("myreport1", replace)  // this works as intended
putdocx append "myheaders.docx" "mybody.docx", saving("myreport2", replace)  // this does not work

[Gordon Fick]

I would like to suggest that Stata consider adding a new command to handle the 'Log Binomial' model using constrained optimization. Bernardo Andrade's lbreg in R is making the use of the Log Link with Bernoulli Regression viable now. Convergence issues are quite dramatically improved compared with the methods used in Stata's binreg or glm.

[Gordon Fick]

While it is possible to use Generalized Additive Models [GAMs] in Stata, I think one must use a rather dated interface involving DOS. If one is using a Mac or a Linux machine, I gather that one cannot use this older code. Is it not time for Stata to develop an implementation that is a part of the main system? One sees the use of GAMs quite often these days. GAMs are part of the arsenal of methods to address linearity issues.