Yes, I understand.  Normally I use Eclipse, which does what I want for "save
as..."

The bigger issue is that R can't tell the location of an open script, which
makes it harder to create new versions of existing work....

Say you have some great analysis going in "Research 2011-01-01" with a
folder for data, code, gui, other languages, excel, whatever else.

Then you want to make a new folder for Research 2011-01-02" with the same
structure.

Making sure that you're setting the right directory in the new version adds
a layer of complexity which would be nice to avoid.  It would be really nice
to just copy the folders, and let the script detect it's own location so
that it could read from the data sub-directory, the gui's sub-directory,
etc.  What I want to be able to do is copy the tools I create into different
client folders so that anyone can just use the tool without changing the
source code.... which is simple for you or I, but prevents newcomers from
using the tools.

Apparently I'm in the minority on the next part: but the "save as" thing I
was describing before seems very strange to me.  As I teach new people R
it's always kind of a hangup that requires a little more explanation, but
maybe it's the way I'm looking at it.

Thanks for your reply Duncan.


On Mon, Mar 14, 2011 at 6:57 PM, Duncan Murdoch <murdoch.dun...@gmail.com>wrote:

> On 11-03-14 5:03 PM, Gene Leynes wrote:
>
>> As much as I love R, there are still the occasional shortcomings.
>>
>> I would love to find a solution to the "save as..." problem.
>>
>> Steps to reproduce the problem:
>>
>>    1. Open any version of he R GUI in Windows
>>    2. Choose "File>  Open" from the menu
>>    3. Open a script that is in a different directory
>>    4. Choose "File>  Save As" from the menu
>>
>>
>> In just about any other application you would be presented with a GUI
>> showing the current folder of the script and the current name of the
>> script.  You could then edit the name and save.
>>
>> In R, you have to find the directory of the script and the script name.
>>  It
>> can be annoying from a GUI perspective, especially if you typically work
>> in
>> one directory and store your scripts somewhere else, and the problem is
>> worse when you have many script versions or directories.
>>
>> I know there are many ways to work around this issue.
>> I also know about the batch file project.
>>
>> However, it seems like this is something that users shouldn't *need* to
>> work
>> around.
>>
>> I think this is related to the fact that R has no way of knowing the
>> location of any open script file.
>> (Please correct me if I'm wrong about that last part! )
>>
>> I think this has come up before, but I couldn't find it in my searches.
>> Is this a problem for other users as well?
>> Should I post this to the development list?
>> Is this change known to be possible / impossible?
>> Can I help make the change?
>>
>
> I think it's simply a matter of different working patterns.  R offers the
> current working directory to save into.  For some people, that's fine.
>  Others (like you) want some other default.
>
> I don't think we want to make the editor so elaborate that it caters to
> every taste.  If you want a better editor, there are lots out there,
> including several that have good integration with R (Emacs, Eclipse, WinEdt,
> TinnR, etc.)  I think it would be best to use one of those editors,
> customized to suit your needs.
>
> Duncan Murdoch
>
>
>> Thanks
>>
>> Gene
>>
>>        [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-help@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
>

        [[alternative HTML version deleted]]

______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Reply via email to