Why doesn't saving a file with "save as" in the do-file editor insert the current file name (Feature request)

[Matt Jans]

Situation:

I have a previously saved do-file open. I click save-as. In other software, I would see the current file name of the file (likely highlighted and ready for me to edit). In Stata, I just see an empty field waiting for me to give a file name.

Why?:

Seems to me this is a precaution from accidentally overwriting the current file, based on how Stata is extra safe about this with data files and other output.

Why does it bug me?:

In my workflow I sequentially version my code manually (i.e., change date and/or v1 to v2). If I do that before I open the file, no problem. But often I open it first and start editing, then need to save-as. In every other program I work in, I can just arrow (or end/home) to the part of the file name I want to change. Can't do that in Stata.

Obviously this is a small thing, and maybe I'm the only one who finds it disrupts workflow. I've looked around online, in forum, and read the do-file editor manual, but haven't seen a solution or info. I'm working in v14.

Thanks!

[Clyde Schechter]

For my part, I am quite happy with this the way it is. As you suggest, it keeps me from mistakenly over-writing the file that I started from and possibly losing it. While I'm pretty compulsive about making back ups of my files so I can recover what I might lose that way, some of my work is done remotely on servers maintained by others. So if I clobber a file by accident, I have to contact the system administrator and wait for them to restore what I lost, which can take days in some places.

But I can see where for your workflow this gets in the way. Perhaps in the future this could be governed by a user controlled setting?

[Matt Jans]

Good point, Clyde. And after thinking about why it was doing that, it seems like a good default. A little weird only because it differs from other softwares so it breaks that "mind-to-keyboard" flow. Word handles it with a dialog box asking if you want to overwrite the current file. Maybe a version of "filename_1" could be used, too. But a user setting would sure be nice. It's pretty awkward when all other programs work differently. Anyway, curious to hear how many others save-as the way I do

[Jeph Herrin]

This has often bothered me, but not as much as the directory that Stata wants to Save into. Logically, it should be the current working directory, which is available as c(pwd), but at least in Windows 7, it is whatever directory I last saved a do-file in. That is, I can navigate to a directory, open a file, use the doeditor to write a few lines, and when I try to Save, Stata prompts me to save in whatever directory I last saved a file in - I have to navigate yet again to the current directory from the Save dialog.

This is true even if the original file I opened was a do-file, and it was opened for editing! If I try to Save As, I am prompted to save it in some distant directory, perhaps one on a network drive which isn't even available. Why not c(pwd)?

[Clyde Schechter]

I agree completely with Jeph Herrin that it would make life a lot easier if the default directory were c(pwd).

[Matt Jans]

Yes! I didn't want to add too many topics to one thread, but I like that one, too. I suspect it works as is so that people are saving data/output to the wd can save do-files to somewhere else (presumably, the last place you saved a do-file is where you want to save your next one). But it's more parsimonious for all laving to be done to the current wd.

[wbuchanan]

Matt Jans a better solution for your work flow would be to use a version control system (e.g., Git, Subversion, Mercurial, CVS, etc...). When you use version control, there is 0 reason to muddy up the file system with n^n copies of what are essentially the same file (VCS all do this as well but it is abstracted from the user fairly heavily) and you get the benefit of being able to add metadata to your changes (e.g., a commit message will usually include something about what and/or why something in the source code changed). If you work with others and/or from multiple machines, using distributed CVS platforms like Git also makes the task fairly trivial (e.g., clone the repository to the new machine, make changes, commit changes, push the changes back into the main repository). It isn't directly related to the request to prepopulate the dialog, but it would solve the root issue that your brought up about the workflow. FYI, you can do any/everything you need to do with Git from the command line in Stata:

. mkdir ~/testdir

. cd ~/testdir
/Users/billy/testdir

. doedit newdofile.do

. ! git init .

Initialized empty Git repository in /Users/billy/testdir/.git/

. ! git add .


. ! git status 

On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   newdofile.do


. ! git commit -m "Just committed a new file"

 1 file changed, 1 insertion(+)
 create mode 100644 newdofile.do

. ! git log

commit 08508ac9cb3e3c00606fb21c03f2eefc33ba1c72
Author: wbuchanan <[email protected]>
Date:   Fri Mar 4 15:48:48 2016 -0600

    Just committed a new file

. ! git commit -a -m "Just added a new line to the file"

 1 file changed, 1 insertion(+)

. !git status

On branch master
nothing to commit, working directory clean

. ! git diff HEAD 08508ac9cb3e3c00606fb21c03f2eefc33ba1c72

diff --git a/newdofile.do b/newdofile.do
index 4cf51f1..9005149 100644
--- a/newdofile.do
+++ b/newdofile.do
@@ -1,2 +1 @@
 this is a new do file
-Added a new line to the do file

Since I started using Git I would find it extremely painful to not use a version control system, and if you're doing a lot of production environment and/or mission critical work it is amazing how many times it will save your bacon (e.g., you can always revert to an earlier version of the source so there's never anything that is truly unrecoverable).

[Matt Jans]

Thanks for this. You're right in the big picture, but it takes some time to learn these things (I tried GH for a weekend, and couldn't get over the learning curve, so I've just developed my own "poor man's" VC. Also, at work I can't just install programs, etc. and we don't have enough IT support for setting up GH. Syncing isn't allowed either on our web-enabled or restricted (no web) environments. So I like my system b/c it works the same way on all the PCs I have to work on and doesn't require any setup. But thanks for tip. We are starting to talk about using here.

[wbuchanan]

Matt Jans I can empathize. I had similar issues working at a state agency in the past (and had similar issues initially working here in Minneapolis). If you're interested, there are a few different resources that people have shared with me that I think are pretty useful for helping to reduce the learning curve : Git Cheat Sheet
Git workflow/model suggestions
Pro-Git (basically the Git Bible of sorts)

GitHub itself isn't completely necessary - although it is extremely useful for keeping work synched across multiple machines/users. Git by itself is really all that would be needed, and the investment in resources on the part of IT would really just be installation and/or potentially updating the software (major updates to Git are fairly rare but there is the occasional patch that will come through). Although I push a lot of my work to my GitHub account, it is completely possible to have a local installation (e.g., no need for any network interface) and if the computer is connected to networked devices, as long as you have write permissions in the directory you're good to go; when you issue the 'git init .' command, it creates a subdirectory on the path called '.git' and within that subdirectory it builds out the infrastructure it uses to hash the commits and store all the versions of the source (e.g., probably a good idea to use a .gitignore file to exclude data from being committed since each commit stores a copy of the files at that point in time). If they wanted to set up something that was comparable to GitHub (without the nice UI on the webside or GUI for the desktop side), they could get the equivalent functionality by spinning up a small VM and allowing users to ssh into the server; In this case you would ssh into the server, create the repository, and then could push to the server in the same way that the commits would be pushed to GitHub (would probably need some tweaking, but is generally what the process would look like):

ssh [email protected]:22
mkdir newRepository && cd newRepository && git init .
exit
git remote add origin 127.0.0.1/newRepository
git push -u origin master

If any of your IT folks wanted to connect with anyone that has done this in a similar environment, feel free to pass my contact info on to them. The state agency I worked at used "Selena" for VCS, but none of the developers used it (if anyone checked out anything it locked down everything) and I never had access to it. One of the biggest reasons I pushed hard for using Git where I worked was to help the agency mitigate any potential political issues by automatically creating an audit trail that could be dumped into a file fairly quickly/easily. Hopefully this helps when the conversations come up again.