Re: Problem with reloading of a session's files

From: phayz <russelldicken....at.gmail.com>
Date: Tue, 23 Mar 2010 19:37:53 -0700 (PDT)

On Mar 24, 11:44 am, mitchell <mforal.n....at.gmail.com> wrote:
> Russell,
>
> > I often edit files contained on a USB key (obviously for portability
> > reasons). Today I started TA and as configured, it loads each of the
> > files listed in the session. However one of these files was contained
> > on a USB key which is no longer plugged into the PC. Instead of TA
> > simply not loading this file, or giving an error message that the file
> > can't be loaded, an empty editor window is created, with the path and
> > filename of the file which *was* on the USB key when TA was last quit.
>
> > I believe this to be a bug but I wanted to be sure before reporting it
> > as such.
>
> This is expected behavior. If you were using a file->open dialog and
> typed the name of a nonexistant file, that file would be created. It
> is a shortcut to creating a new file, file->save_as, navigate to the
> folder, type the filename, ... too much.

Wow! I find that strange. Surely a more logical action to create a new
file would be File -> New and voila!, you can type whatever you want.
gedit for instance, gives an error message when you try to open a file
which doesn't match the name you type into the File Open dialog.

> You do bring up an interesting issue in that if session files are not
> found, the file is created instead of a notification being brought up.
> I would think someone seeing an empty buffer would be alerted that the
> file doesn't exist, but is a notification necessary? Thoughts anyone?

I definitely think TA should be notifying the user if a session file
specifies a file which doesn't exist. As you say, if you're expecting
a file to open and the buffer for that file is empty, you would
probably realise that the file wasn't able to be opened. Not providing
the user some sort of notification that the file's not accessible
means more effort for the user in trying to work out why. If this
happens, the user has to open Windows Explorer (or similar) and try to
work out why the path contained in the session is no longer
accessible.

Regards,

Russell Dickenson
Received on Tue 23 Mar 2010 - 22:37:53 EDT

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 11:40:47 EST