Re: Slow access to files using UNC path

[Stefan]

>> How about choosing the file name based on the date the buffer is
>> created?
> Then restarting emacs 20 times in one day will result in an
> unnecessarily large amount of files.

Not if your "date" changes less than 20 times per day.
And in what way is that different from what happens if you choose the date
based on the time the buffer is saved?
I must still be missing something.

>> How about using "foo/bar-latest at first and switching to "foo/bar-<date>"
>> in before-save-hook?

> So theoretically bar-latest will never be written to? So basically
> you're suggesting that instead of a blank value in the
> buffer-file-name variable, we use something more misleading?

In what way is it more misleading?

> At the moment emacs does not easily facilitate the dynamic generation
> of a file name at save time.

Indeed, it doesn't.  The very idea of a buffer-file-name variable is based
on the premise that the buffer corresponds to one particular file.

> Your increasingly complicated suggestions would solve the problem, but
> this level of complexity in what is ultimately a hack in the first place
> seems unnecessary, IMHO.

I don't find "foo/bar-latest" more complex than "".  But maybe that's just me.

> If recent changes in emacs are going to prevent "" as a
> buffer-file-name from working,

It already isn't working if you turn on uniquify.  Nothing to do with
recent changes.  Your choice of "" has fundamentally two problems:
1 - it's not a valid file name (and it's not an absolute file name).
2 - it's not unique.  Emacs likes to have at most one buffer with a given
    file name.
None of those two necessarily cause Emacs to break, but they both induce
various more or less minor problems.

> then perhaps it would be better to have a save hook which is called prior
> to the buffer-file-name being checked, so these elaborate hacks are not
> necessary in the first place.

Now that's probably true.


        Stefan