Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
Helge Hafting wrote:
rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
I might be a bit annoying, but let's pretend we don't know the
problem
with the filesystem checks. Then, how would you explain to
someone that
you're implementing administrative tools, touching many files and
thinking of all different special cases with the risk you forget
one,
while you can find out whether a file is loaded just by looping
over all
buffers in the memory and comparing a handful of strings to each
other.
As I have said somewhere else, you can probably do very very many
string
comparisons before the user will notice.
Yes, but the problem is that you CAN'T do this just by comparing
strings. In many cases, to be sure, you could tell that the file
is loaded by comparing strings. But you can't be sure it isn't
loaded just by comparing strings. Maybe it's loaded, but under a
different pathname.
I wonder if this loadifneeded stuff is too complicated?
How about getting rid of loadifneeded, and simply load everything
unconditionally? (And disallow closing of needed files as well,
only close the view if the user tries.)
That's already exactly what we do :-)
I think the check is needed because e.g. the master buffer could be
saved under a different name. Are there other ways buffers could vanish?
I don't think so. But I think we are not focusing on the right issue
here. loadIfneeded() just verify that all child documents are properly
loaded. This in itself should not be time consuming at all. If we have
a problem with FileName comparison, we should maintain a Buffer
pointer inside the InsetInclude. This way, the test would only be to
check this pointer is null or not.
But there is the way I mentioned, yes? If you save the master buffer
under a different name, then the master buffer isn't loaded any more. Of
course, we could catch that particular case, and I actually did start
implementing precisely the proposal you've just made, but stopped
because of worries of the sort we're now discussing.
rh
