bug#26395: 25.1; ses.el git master, inhibit-quit on some cell evaluations

[Vincent Belaïche]

Hello,


Le 28/07/2019 à 02:37, Kevin Ryde a écrit : > Vincent Belaïche
<vincent.belaiche@gmail.com> writes:
>>
>> However, since some processing (updating the cell values) might be
>> quite lengthy, you want to be able to quit during that.
>
> This is a while ago for me, but I arrived at it only from the formula
> eval part.
>
> No doubt storing data and formatted etc should be atomic.  I hoped
> only that perhaps those could otherwise be in a consistent state when
> a particular formula is evalled, so quit out of something wild is ok.
> It would leave some or all recalculates still needed of course.

SES has two zones in the buffer.

- print area is what you see data area is where the document object is
- stored

The document object is a vector of cell objects + a few parameters
(column count/width, cell width, local printers), each cell object is
also implemented as a vector.

IMHO what really needs to be atomic --- otherwise recovery is
jeopardized :

1) keep correct the number of lines in the print area --- if you don't
   have that, locating the data area is jeopardized

2) keep correct the cell widths in the print area, and cell intangible
   property --- otherwise the print-area point to cell id is broken

3) any update of the data area.

Just reading the code I found one place where this was not observed, and
I just made a correction --- see
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c1b180153f57777b64e27c45633d8a05e02dda5a

There are surely a number of other ones which I still need to spot and
fix.

FYI cell calculation + update of the print area on the one hand is
deferred with the list ses--deferred-recalc, and update of the data area
is also deferred with the list ses--deferred-write, so inherently there
is a risk when you quit to drop the deferred operations and make the
cell values inconsistent with the result that calculations would
otherwise have, or to break the reference lists, or to make the printed
cell values inconsistent with the actual cell values in the document
object, or to make the data area inconsistent with the document object.

In the latter case (document object inconsistent with data area),
reconstructing all will overwrite document object by what is read from
data area, loosing your latest edits. Similarly saving the document will
not update to consistency the data area, so if you save + close + reopen
the file, that won't solve it.

What really is needed is the « Dirty » indicator for the user to get
warned, and not go on editing a document while there are such
inconsistency. This is especially true for inconsistency between
document object and data area.

I need to fix that, when I am done with remaining bugs in cell renaming.

  Vincent.