On 07/13/2012 03:47 AM, Jean-Marc Lasgouttes wrote:
Le 13/07/2012 00:24, Pavel Sanda a écrit :
Richard Heck wrote:
This leads to the harmless message above, but more importantly, it
means
that the undo stack is lost every time a file is saved-as. This
looks like
a regression to me.
Richard, would it seem right to add a parameter to Buffer::reload
asking
to preserve the undo stack in this case?
You mean to preserve undo stack for each reload of file or just for
save-as
scenario? We also reload automatically after commit/checkout VCS
operation which
can change read-only status.
This is why I propose to add a parameter to reload telling whether
undo should be discarded.
OTOH, it looks like doing a reload in after save-as is a bit harsh. Is
the goal only to sanitize IncludeInset?
It certainly wouldn't surprise me if there were something simpler we
could do. It was definitely a big hammer, that commit.
The primary goal was to deal with the fact that children, parents, etc,
may no longer be where there are supposed to be. But the Buffer contains
all kinds of pointers (e.g., in the TOC, in the reference cache, etc)
that may point to children and the like. So I'm guessing there are other
issues.
I have been pondering for some time whether the updateBuffer mechanism
could be extended with an enum telling what to update, in order to be
able to run it for specific tasks. For example
updateBuffer(EXTERNAL_FILES) could check the validity of all external
files we hold. I had other applications in mind, but I can't remember
them ATM.
That's quite a good idea, I think. I'm sure we'd discover uses for this.
I can well remember putting comments in the code that said things like,
"What we actually want here is such-and-such, and the way to get it is
to update the Buffer...."
Richard
