[Maarten Buis]

Whenever I work on a new project, I start by copying and pasting a "header" or "preamble" to each new do file. I searched to see if there was functionality to automatically append something like this whenever I start a new file but came up short on the search. I think this would be a useful enhancement. For example, here the default header I load (nothing special but seems to be the most common first-steps for me):

That is a fair request. The mkproject package on SSC allows you to define your own templates. For .do files you can use the boilerplate command from that package.

[Scott Adams]

Bert Lloyd re: #148/149 -- yes! That does work, thank you. If only all my wishes came true so easily!

wbuchanan re: #150 -- I have not noticed any negative effects, I suppose they are possible. I just wanted to shut off graphics so Stata would not draw plots that have a large number of points, when all I really needed was to look quickly at the shape (e.g., a diagnostic plot of some kind). This solution works well enough for my purpose.

[Clyde Schechter]

I have a request for a change in the PDF documentation for -merge-. In fact, I would like to see it done in version 18. The documentation is good about pointing out that -merge m:m- is usually a bad idea and explaining why. But it, and the section on "troubleshooting m:m merges" are deficient in that they only talk about converting them to 1:1, 1:m, or m:1 -merge-s. From doing this kind of troubleshooting for many people here on Statalist, I think that it is also common that the actual command needed is not -merge- at all, but rather -joinby- (or, rarely, -cross-). I also have the distinct impression from Statalist that large numbers of users have never heard of -joinby-.

I think the documentation on -merge- would be improved if it also advised users to consider -joinby- when they are thinking of doing an m:m -merge-.

[Joseph Coveney]

I think the documentation on -merge- would be improved if it also advised users to consider -joinby- when they are thinking of doing an m:m -merge-.

I'd go so far as to recommend changing the behavior of -merge-, itself, (and only begrudgingly under version control) to either give an error message pointing out ("Are you thinking of -joinby- [with hyperlink to helpfile] or -cross- [with hyperlink to helpfile]?") or automatically performing a Cartesian join with perhaps a warning on the time and memory requirements.

[George Ford]

People ask quite frequently how to outreg2 the first stage results of ivregress and similar commands. It would be nice if the first stage could be stored in some way that they could be recalled or outreg'd.

[Clyde Schechter]

Joseph Coveney In previous Wishlists I, too, have called for a change to the behavior of -merge-. As StataCorp has resisted that suggestion for many years, I am turning to other tactics to reduce the harm done by -merge m:m-. In spirit, though, I fully agree with you.

[Henry Strawforrd]

I would really like to have a general try - except logic that can be applied to any command and error. Capture only works for certain commands and errors.

[daniel klein]

Capture only works for certain commands and errors.

Could you be more specific? Provide an example in which capture does not work and explain how a try-except construct should work.

[Henry Strawforrd]

For example

try {
some non-linear / non-parametric estimator

}
except convergence not achieved {
 Remove some X or be a bit more parametric
}

[daniel klein]

So what's wrong with

capture some non-linear / non-parametric estimator
if (_rc == 430 /* convergence not achieved */) | (e(converged) == 0) {
    Remove some X or be a bit more parametric
}
else if ( _rc ) {
    display as error "some other problem with the model"
    exit _rc
}

[Henry Strawforrd]

Ah that works? I thought you only get _rc with capture confirm. Okay, then the existing procedure is more general than I thought.

[Clyde Schechter]

Request for a minor convenience:

Give -egen- the -before()- and -after()- options, as well as letting the newvar be optionally followed by :label_name, just like -gen-. Obviously it is easy enough to work around these limitations, but it would be nice to be able to compactify the code a bit in this way.

[daniel klein]

You can capture any command. After capture, _rc (or c(rc)) contains a non-zero return code if there is a problem. Often, the return codes are specific; sometimes, they are general. You can see the list of return codes here.

[daniel klein]

Request for a minor convenience:

Give -egen- the -before()- and -after()- options, as well as letting the newvar be optionally followed by :label_name, just like -gen-. Obviously it is easy enough to work around these limitations, but it would be nice to be able to compactify the code a bit in this way.

Sounds like a minor convenience, but I imagine this could be quite challenging. The way egen.ado is set up right now, it passes all options through to the _g*.ado files that implement the various egen-functions. So how do you implement the new options? Adding before() and after() to the main program, i.e. egen.ado, might break (community-contributed) code that uses these options for other purposes. Putting the change under version control takes away from the generalized syntax. You could change the official egen-functions to accept before() and after() but that would not extend to community-contributed functions and, thus, take away from the generalized syntax.

Implementing :lblname is not straightforward, either. Some egen-functions, e.g. groups(), optionally create value labels. What should egen do with conflicting label names, e.g.

egen newvar:foo = group(bar) , label(foobar)

[Clyde Schechter]

Re #164: Good points. I hadn't given much thought to how this would be implemented. I had vaguely considered that the top level of -egen-, where parsing is being done, would identify -before()- and -after()-, retain the appropriate variable name, remove them from the options and then pass on other options to the function being called. Then, again in the top level, just before returning, execute the appropriate order command I tacitly assumed that this maneuver would be fairly easy to do, but perhaps it isn't so.

As for conflicting with labels generated by the -egen()- functions themselves, I must admit the possibility didn't even occur to me, and I agree that resolving that conflict has considerable downsides no matter how it is done.