[Chen Samulsion]

Thank you Nick Cox. For users who is forbidden by sagepub, Nick's article is: dm0116 Speaking Stata: Nine notes on dealing with dates and times, DOI: 10.1177/1536867X251341416

[Raymond Guiteras]

Thank you Nick Cox. For users who is forbidden by sagepub, Nick's article is: dm0116 Speaking Stata: Nine notes on dealing with dates and times, DOI: 10.1177/1536867X251341416

For me, the paper is gated on the SJ site but appears to be open access on Sagepub:

https://journals.sagepub.com/doi/10....6867X251341416

[Nick Cox]

It should be open access to all. https://journals.sagepub.com/doi/pdf...6867X251341416 is what I also recommend as a link.

[Chen Samulsion]

Why inlist(z,a,b,...) restricts the number of arguments between 2 and 10 for strings?

[Ryan Sandler]

I'd request an increase to the name length limit for stored estimates (currently required to be a valid variable name at 32 characters). While I'm sympathetic to the view that 32 characters is plenty for an actual variable name (but also see #56 and #58 in this thread for an alternate view), that logic doesn't really apply for stored estimates, which are infrequently used directly in code, and have names that are often constructed via macro loops when running several related estimations.

With -estimates store- insisting on tacking "_est_" onto the front of the name for internal naming purposes, all it takes to blow the 32-character limit is a name based on a modestly-long human-readable outcome variable name, and a couple of reasonably short suffixes for alternate specifications. A 16-character variable name, two 5-character suffixes for different specifications, plus underscores separating them, plus the 5-character "_est_" prefix and you're at 33 characters.

The amount of time I've wasted over the years re-running programs with regressions stored in a loop because I missed a place where the resulting estimate name hits 35 characters is not worth thinking about. Yes, there are any number of hacks one can do to fix the issue, abbreviating suffixes, removing underscores, renaming variables etc., generally at the cost of readability, but to me the point is that there doesn't seem to be a good reason to have to do any of this. Even an 80 character limit for estimation names paired with keeping the 32-character limit on variable names would probably resolve most issues.

[George Hoffman]

this has been brought up in various threads, but some way to save gtraph customizations and apply them when wrting a commadn to produce a graph. possible options:
1. in graph editor, a tab which would trasnlate customizations into the options to be appended to the grapgh statement. this would update in real time as the graph was customized. then moving to the 'options' tab would show the list of customization options to be copied.
2 - a commadn line tool to extract these customizations from an existing .gph file and copy to the clipboard?

i understand that the .gph file can be opened to disclose these details, but these steps are cumbersome especially when working in a differnt workspace environment (like Jupyterlab) that calls Stata in the background.
if this already exists i apologize for the request and waste of people's time.
thx

[John Mullahy]

Regarding point 2 in #171:

The undocumented command gs_fileinfo

help gs_fileinfo

returns among other things the command that produced a saved .gph graph.

It suspect that it would be straightforward to extract as a substring everything in this string that sits to the right of the comma (i.e. the options).

sysuse auto

tw scatter price mpg, msy(o) mco(blue) plotreg(marg(zero))

graph save agraph.gph, replace

gs_fileinfo agraph.gph

di r(command)

Returns:

. sysuse auto
(1978 automobile data)

. 
. tw scatter price mpg, msy(o) mco(blue) plotreg(marg(zero))

. 
. graph save agraph.gph, replace
file agraph.gph saved

. 
. gs_fileinfo agraph.gph

. 
. di r(command)
twoway scatter price mpg, msy(o) mco(blue) plotreg(marg(zero))

[Nicholas Winter]

Ability to render fonts' programming ligatures in the Stata windows.

Programing ligatures are a font feature that allows multi-character programming symbols, such as '<=', to be displayed as a single glyph (e.g., ≥).

I use Sublime Text rather than the Stata editor, and I've created a bespoke version of Fira Code with ligatures to display Stata's compound double-quotation marks distinctly. Unfortunately, Stata doesn't have a way to turn on this font feature in its own windows, but if it did these sorts of ligatures might be really helpful for folks. Note the `" and "' in the sample below (rendered in red). Also note the >= rendered on the third line--this is the default Fira Code ligature for this symbol.