[David Rochman]

As per Nick Cox suggestion

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

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

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

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

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

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]

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?

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

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

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

[Richard Williams]

This is about as trivial as you can get, but it annoys me. I sometimes copy output code that appears in a document that looks something like this:

. webuse nhanes2f, clear
. * This will cause an error
. sum age

Most lines that start with a period will run fine, but lines that have a comment will not, i.e. you get a message like

. . webuse nhanes2f, clear

. . * This will cause an error
* is not a valid command name
r(199);

end of do-file

r(199);

I then have to edit or delete the comment lines. I wish Stata would recognize the comment as a comment, just like it recognizes other commands that start with a period.

[Amin Sofla]

Amin Sofla Can you clarify what you mean by these? The do-file editor already uses font color to distinguish, for example, comments, command names, functions, quoted material, and contents of local macros. And the preferences menu in the do-editor allows you to set these colors however you like, as well as to specify distinctive coloring for certain other things. And what do you mean by "text highlight color" and what would it be used for?

Dear Clyde,

Thanks for your reply.

Indeed, the do-file editor already has font color. However, there is not an option in the Manu Bar to choose a color for a specific text (or code), or highlight it (e.g., by color).

Besides, I think that it would be much nicer if Stata’s do-file editor contains some features of 'Microsoft Word' or 'Latex' in its Menu Bar. The suggested additional features are e.g.,

• Having header level for the text

If the written text has a header, we can then create a table of content at the beginning of the do-file. And, by clicking on a specific text in the table of content, we can jump to that section in the do-file editor.

• Providing comment

This feature will enable us to provide a comment by selecting a specific part of the code in the do-file editor.

etc.

[Clyde Schechter]

Amin Sofla Can you clarify what you mean by these? The do-file editor already uses font color to distinguish, for example, comments, command names, functions, quoted material, and contents of local macros. And the preferences menu in the do-editor allows you to set these colors however you like, as well as to specify distinctive coloring for certain other things.

And what do you mean by "text highlight color" and what would it be used for?

[Amin Sofla]

Adding ‘text highlight color’ and ‘font color’ to the do file editor.