[John Mullahy]

In #178 I suggested that an immediate twoway pcbarrowi command, analogous to twoway pcarrowi, be implemented in v17. For the time being, however, I just realized that recast can help, e.g.

twoway pcarrowi `y1' `x1' `y2' `x2', recast(pcbarrow)

[Wouter Wakker]

I would like to see lincom support multiple expressions just like nlcom does, as well as a post option. I have been working with distributed lag models where I want to estimate cumulative effects for year t, t+1, t+2 etc. I now have to use nlcom, but it's a lot slower than lincom.

[jerome falken]

It would be really nice if the data editor/viewer could have tabs (a-la chrome) to switch between different frames.

[Jen Walker]

I think it would be great to have the ability to embed graphs in output - such as log files and the results window.
I welcome any suggestions if people have made this work.

[William Lisowski]

My apologies for yet another post on this topic, which risks drowning out post #183 by which it was inspired.

Commenting on #188, the two characters in question are the ASCII 0x60 (name: grave accent, AKA backtick, incorrectly AKA left-single-quote) and ASCII 0x27 (apostrophe) characters - part of the fundamental 0x00-0x127 range of ASCII (from 1967 onward) - so they are likely to appear similarly on every contemporary keyboard that includes them.

Stata the software shows - in the Do-file editor window - what people see on their keyboards.

StataCorp the publishers of the Stata PDF documentation and the Stata Journal show - in those publications - something that does not appear on keyboards - so that other than in the note quoted in post #186 there is no indication of what to type - and when copied and pasted, rather than typed, into the do-file editor do not cause local macro interpolation when the code is run.

I'm now of the opinion that the best approach would be for Stata to enhance its paste command to scan the clipboard before pasting (into the Do-file or Command windows) and make appropriate changes to replace (all? most? many?) of the Unicode White Space characters with a Unicode "space" (U+0020), rather than implement a separate command to clean them up, and to replace all "smart" (i.e., typographical) single and double quotation marks ( ‘ ’ “ ” ) with the appropriate (for Stata) substitutions from the ASCII subset of Unicode ( ` ' " " ). This won't help those who are using a different editor to create Stata code, but so be it. Philosophically, this is a lot like "paste and match style" commands we've all seen, except it would be the default, with "paste and retain junk" as an option, perhaps.

[Nick Cox]

On my keyboard the left-single quote is a backtick and the right-single quote is vertical. If that's true for anybody else's keyboard, then there is an inconsistency somewhere; either Stata doesn't show what people see on their keyboard, or it shows something different in its documentation or output that doesn't correspond to what is on keyboards.

I think it's the experienced users who have an idea what Stata should show or document, and I would like to agree with them as I feel fairly experienced too, but it's how people learn to use these keys that is also important.

[Joseph Coveney]

You are yet another person caught by StataCorp's editorial habit of using — in their PDFs and in the Stata Journal — the typographical left and right "single quotes"

I just looked at the entry for macro in the user's manual (PDF), and not only does it use the cute single quotation marks instead of what's supposed to be used, the documentation even says that's what is to be used:

To substitute the macro contents of a local macro name, the macro name is typed (punctuated) with surrounding left and right single quotes (`').(bottom paragraph of Page 280 of the Stata Programming Reference Manual Release 16; p.pdf)

I never noticed that before. It really does need to be bulk corrected, as William says above in #184.

Added: but, when I copied and pasted as above, it does become the accent grave and apostrophe.

[William Lisowski]

Apologies - my wording was technically precise to leave no ambiguity when the suggestion is reviewed at StataCorp, but should have included something like the following discussion copied from my FQA list (Frequent Question Answers). Below is an explanation that will not be new to some readers.

You are yet another person caught by StataCorp's editorial habit of using — in their PDFs and in the Stata Journal — the typographical left and right "single quotes"

‘v’ 

rather than the "accent grave" and "apostrophe" characters

`v'

users must type for Stata to recognize them.

Doing that enhances the typographical elegance of the publications while increasing the difficulty of copying and pasting code from PDF publications into Stata. This editorial habit reflects the days of Stata 1.0 when copying and pasting from documentation meant using real paste, but to me is less defensible in the era of paperless documentation.

Luckily the output of the help command does not suffer from this problem.

[Richard Williams]

I don't 100% understand William's post #184. But, I do know that, if I am searching the PDF manuals and search for the left quote,

`

I can't find it. Whatever character the manual is using is not the same as the character Stata wants you to use. Perhaps the manual looks prettier that way, but I prefer functionality.

[William Lisowski]

In the spirit of Clyde's suggestion at #183, it would also be helpful if Stata's command interpreter were to quietly treat the Unicode left and right single quotation marks (U+2018, U+2019) as if they were Unicode/ASCII accent grave accent and apostrophe (U+0060 and U+0027) required to dereference a local macro, so that new users who are attempting to build from the examples in the PDF Stata Manuals would actually be able to copy and paste the code from the PDF and have it not fail.

Either that, or make a bulk change to the documentation so that the characters in the documentation are the characters required by Stata, and look a lot more like what you see on the screen. What looked handsome when copying code was done by retyping doesn't work so well with PDFs.

[Clyde Schechter]

From time to time, people copy Stata code from a website (including this Forum), a word processing document, or code displayed in an email message (not as a do-file attachment), and then get bizarre error messages when it runs. This is due to the inclusion of non-printing characters that these pretty-print programs use to control layout and display of text.

These bizarre errors are perplexing because it isn't obvious what is wrong: what seems to be a perfectly good Stata command fails in some inexplicable way. Precisely because the cause of the problem is not visible to the human eye, it isn't immediately obvious what is going wrong, and it takes some doing to figure it out. Once you do figure it out, it is not easy to filter those non-printing characters out of the do-file, and one often has to resort to manually retyping the code.

It would be great if the do-editor had a command (probably something in the Edit window) to Purge Non-Printing Characters that would remove them all at a single click or keystroke.

[jerome falken]

Faster contour plot (using MP cores if necessary).
I use it a lot, would like if it could be faster.
Thank you.

[I-Chin Wu]

I hope Stata 17 could provide official support for non-parametric cumulative incidence estimation and state occupation probability in the presence of competing risks. Currently, these could be estimated by stcompet and msaj. Thank you.

[Leonardo Guizzetti]

In addition to #179, I would like to see the option of having variable labels longer than 200 characters.

[Clyde Schechter]

I would love to have variable names that exceed 32 characters.