[Clyde Schechter]

Here's a minor annoyance that could be eliminated easily, I think. For good and understandable reasons, commands that display variable names will abbreviate the longer ones, and there are options that give the user some control over that process. But the options are different across commands. Thus, for -describe-, you have -fullnames- (which means take the whole name or the standard abbreviation with no other options). But for -ds- you have -varwidth()- which lets you specify how many characters you want. -list- also lets you specify the desired number of characters, but that option is called -abbreviate()-.

It gets confusing which option goes with which command. Why not harmonize them with a common option that works and does the same thing in all of these commands (and any others that display variable names that I might have overlooked here? Evidently, the pre-existing options will have to be retained, at least under version control, but going forward...

[Bruce Weaver]

In the same vein as Clyde in #106, import delimited has option varnames(#) to indicate that variable names should be read from row #, whereas import excel has the firstrow option. It would be nice to have a common option that works for any import command.

[Jesse Wursten]

1)
Perhaps a very silly suggestion... but I think it might be a good idea to change error 101 from

=exp not allowed

to

=exp not allowed (did you mean to use ==?)

This could avoid confusion among the new Stata users, especially those with zero programming experience.

2)
I would personally appreciate a mode that 'fills in' all macros when printing to the command window. I use globals and locals very often, but always find it frustrating that in the command window (is that the correct term?), I just see ${depvar} instead of log_employment or log_turnover etc. This would also make it a lot easier to spot errors in assigning macros. I suppose there are good reasons why Stata does not do this right now, but a toggle would already be great (e.g. in a similar vein as set trace on/off).

3)
This is probably the most obscure request, but it would be nice if there was a way to access the name/path of the dofile currently being executed, through e.g. c(dofilename).

[Nick Cox]

Jesse: 3) often is asked for (e.g. at users' meetings), but do bear in mind that do-files can call do-files that can call do-files ..., so what you are asking for when there are nested calls?

[Mauricio Caceres]

Jesse: 3) often is asked for (e.g. at users' meetings), but do bear in mind that do-files can call do-files that can call do-files ..., so what you are asking for when there are nested calls?

Personally I would like a way to reference the "top level" file called via "do". So if you call "stata do /path/to/filename.do" from the command line, I would like a macro that returns "/path/to/filename.do" regardless of which program or sub-file is being called (even if filename.do calls a do file which calls a do file which calls a program and so on, it would be nice to be able to find out which was the top file that called them; similarly if you call ". do /path/to/filename.do" from the command window).

Naturally this macro would be empty if there was no file called (e.g. entering c(dofilename) to the command window directly).

[Nick Cox]

You can program that: a wrapper for do that copies its own file argument to a macro. But what would you want to do with the macro? I am lost here: if I just type

do mydo.do

then I can see what I've just typed while it's working and indeed after it's executed. So, what would I want to do with the same information?

[Mauricio Caceres]

You can program that: a wrapper for do that copies its own file argument to a macro. But what would you want to do with the macro? I am lost here: if I just type

do mydo.do

then I can see what I've just typed while it's working and indeed after it's executed. So, what would I want to do with the same information?

Maybe my (lack of) stata skill is showing here but I'm not entirely sure how to write a proper wrapper for "do". There are 3 ways in which I use "do":

1. "stata -b do" from the command line (and "stata do").
2. "execute" from the do file editor.
3. Typing it out from the command window.

The first scenario is the one I use most often (and I often call stata using external programs). The last scenario is the only one where I would know how to start, however, and even then I'm not 100% sure how to properly deal with spaces, quotes (or lack thereof), special characters (e.g. ";"), and arguments to be parsed that appear after the file name. I imagine there's a version of "gettoken" that does it? It doesn't help with scenarios 1 and 2, though.

As for why I would want this: One reason is the ability to name the log file after the do file even if your do file name changes (alternatively, the ability fo deduce the log file name if it is generated automagically, as is the case if run in batch mode). Another reason is that I find it nice to define paths to other scripts, data, etc. relative to a master do file to be executed. Being able to get the path to that file, even if it's a relative path, is very useful because it allows me to not have to worry about the current working directory. Of course, if you always change your working directory to that of the file you are about to execute it doesn't matter (since c(pwd) already exists), but I'd prefer to be able to control this part of my workflow from Stata rather than having to worry about it before running a file.

[Sergio Correia]

Maybe my (lack of) stata skill is showing here but I'm not entirely sure how to write a proper wrapper for "do". There are 3 ways in which I use "do":

1. "stata -b do" from the command line (and "stata do").
2. "execute" from the do file editor.
3. Typing it out from the command window.

The first scenario is the one I use most often (and I often call stata using external programs). The last scenario is the only one where I would know how to start, however, and even then I'm not 100% sure how to properly deal with spaces, quotes (or lack thereof), special characters (e.g. ";"), and arguments to be parsed that appear after the file name. I imagine there's a version of "gettoken" that does it? It doesn't help with scenarios 1 and 2, though.

As for why I would want this: One reason is the ability to name the log file after the do file even if your do file name changes (alternatively, the ability fo deduce the log file name if it is generated automagically, as is the case if run in batch mode). Another reason is that I find it nice to define paths to other scripts, data, etc. relative to a master do file to be executed. Being able to get the path to that file, even if it's a relative path, is very useful because it allows me to not have to worry about the current working directory. Of course, if you always change your working directory to that of the file you are about to execute it doesn't matter (since c(pwd) already exists), but I'd prefer to be able to control this part of my workflow from Stata rather than having to worry about it before running a file.

FWIW I wrote a quick script ("doa") that can be recycled for that: https://github.com/sergiocorreia/sta...master/doa.ado

It fixes two things for me:

• Autocompletion. I can do "doa 1" and it will look for files named "1*.do" , so I don't have to type the full name
• Prevents edits while the code is running. Sometimes I edit the file (from an external editor) while the do-file is still running, and that messes things up for Stata (which gets confused and might run the wrong line).

You could easily adapt it to e.g. add a "log using" line or add a macro with the path.

[Robert Picard]

Also see project (from SSC). project automatically logs all do-files based on the do-file's name. project returns the name of the current do-file in r(dofile). project changes the current directory to the one that contains the currently running do-file (top-level) so you can, for example, save a dataset based on the name of the do-file using:

save "`r(dofile)'.dta", replace

and the dataset will be saved in the same directory as one that contains the do-file.

See this recent post of mine and (project's help file of course).

[Mauricio Caceres]

FWIW I wrote a quick script ("doa") that can be recycled for that: https://github.com/sergiocorreia/sta...master/doa.ado

It fixes two things for me:

• Autocompletion. I can do "doa 1" and it will look for files named "1*.do" , so I don't have to type the full name
• Prevents edits while the code is running. Sometimes I edit the file (from an external editor) while the do-file is still running, and that messes things up for Stata (which gets confused and might run the wrong line).

You could easily adapt it to e.g. add a "log using" line or add a macro with the path.

Thanks for the suggestion. There's a couple of bugs, but they seem probably workable. I am fine with workarounds but they are annoying because it's hard to make them general. Take this scenario:

test.do

local 0: subinstr local 0 ";" ","
syntax using, test(str)
disp `"`using'"'
disp `"`test'"'

. do test using auto; test(hello) // fine
. doa test using auto; test(hello) // fails

I think this would work for most cases, right?

gettoken dofile arguments: 0
// look for `"`dofile'"'
// if not found, look for `"`dofile'.do"'
// if not found, look for `"`dofile'*.do"'
// if not found, error
// if multiple files, error
do `"`dofile'"' `arguments'

I might use something like that for now, though...

[David Rochman]

As per Nick Cox suggestion

[Richard Williams]

I wish Mata had a saveold function. You might have Mata code that would work perfectly fine in, say, Stata 12, but if you compile it under Stata 15 it won't run in earlier versions. The code has to be recompiled in the earlier version, and people using earlier versions won't necessarily know how to do that. The list periodically gets messages from people saying they can't get this or that program to run under their version of Stata even though the documentation claims the program will work with their version.

If nothing else, maybe the Mata error message when you try to run a newer version could be modified to add something like "You may need to recompile the Mata code under your version of Stata".

[Nick Cox]

Richard: What specific problems are you referring to here? Are you saying that compiled code from say 15 should work in 12 but doesn't because the compiler or other Mata internals have changed? Whose documentation is misleading?

What most user-programmers do is release their Mata source code and users don't need to know how to compile at all. There will be problems if we use Mata functions not available in their Stata.

[Richard Williams]

Nick, see posts 13 on of https://www.statalist.org/forums/for...ic-regressions for an example. In that case the user-written khb routine is supposed to run under Stata 11 but wouldn't because the Mata code was compiled under 13.1. Recompiling the code under your version of Stata will solve the problem, but many people who download a program will not know that.

Version control keeps ado files working correctly with later versions of Stata, so it would be nice if that were true of Mata compiled programs too.

[Andrea Discacciati]

It would be great to be able to run mata code line-by-line (interactively) directly from a do-file.
(Probably there are good reasons why this is not already possible, though.)