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

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

[Kevin Ryde]

In debian packaged emacs 25.1 but git head ses.el, it seems cell
evaluations sometimes run with inhibit-quit.  For example, initial entry

    emacs -Q /tmp/foo.ses
    Ret                           # enter formula
    inhibit-quit Ret              # the formula
    =>
    displays t

I hoped no inhibit-quit while running formulas (and thought there wasn't
previously), as protection against slow or accidentally infinite forms.

I noticed this in my stock charting program where I communicate with a
database sub-process by accept-process-input, and that func doesn't run
under inhibit-quit.  I could with-local-quit and bail out in a sensible
way, but perhaps there's not meant to be inhibit-quit anyway.


In GNU Emacs 25.1.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-01-01, modified by Debian built on x86-csail-01

Important settings:
  value of $LANG: en_AU.iso88591
  locale-coding-system: iso-latin-1-unix

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

[Lars Ingebrigtsen]

Kevin Ryde <user42_kevin@yahoo.com.au> writes:

> In debian packaged emacs 25.1 but git head ses.el, it seems cell
> evaluations sometimes run with inhibit-quit.  For example, initial entry
>
>     emacs -Q /tmp/foo.ses
>     Ret                           # enter formula
>     inhibit-quit Ret              # the formula
>     =>
>     displays t
>
> I hoped no inhibit-quit while running formulas (and thought there wasn't
> previously), as protection against slow or accidentally infinite forms.
>
> I noticed this in my stock charting program where I communicate with a
> database sub-process by accept-process-input, and that func doesn't run
> under inhibit-quit.  I could with-local-quit and bail out in a sensible
> way, but perhaps there's not meant to be inhibit-quit anyway.

Yes, ses.el binds inhibit-quit all over the place, presumably out of an
overabundance of caution (not wanting to mess up the display).  But it
shouldn't do that while computing the formulas, you'd think.

I've Cc'd the maintainer; perhaps he can weigh in here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Vincent Belaïche]

Hello,

I am not sure what was the exact intention, as this is code which was
written before I became maintainer of SES.

My understanding is that if you quit during modifying the formulas, then
the SES object that under the hood holds all the inputs of the
spreadsheet might get corrupt, and then it would be impossible to
recover from that situation. However, since some processing (updating
the cell values) might be quite lengthy, you want to be able to quit
during that.

Probably there should be some indicator in the mode bar that the
referenes/values/ or display are « dirty », after some quit has occurred
and until the user makes some repair cell reference all + recalculate
all + redisplay all.

Please note that :

- the « repair cell reference » exists ---
   ses-repair-cell-reference-all --- this is one of the additions I did.

- recalculate all exists --- ses-recalculate-all

- but there is not redisplay-all as such, you need to call
   ses-reconstruct-all that will do all three operations, to my
   knonwledge there is no way if you just want to repair the display (for
   instance you have quitted during changing a column width, so the
   cells references and value are not broken, just the display is broken)

FYI, Updating the cell value through the formulaes is made by
post-command-hook, not during the editing of the formula by itself.

Please not that when time allows, my intention was to add some commands
to make some cell permutations (for instance row or column
transposition). I have still not done that, because there are remaining
bugs with the cell renaming, and I wish to solve that before. Also,
quiting/undoing during cell renaming is probably not well supported.

Anyway this discussion is certainly usefull as I have not yet thought
how to handle quiting during such a permutation, and handling undoing of
it --- idealy quitting would be possible, and undoing would undo only
that part that have been done before the quit.

   Vincent.


Le 26/07/2019 à 11:57, Lars Ingebrigtsen a écrit :
 > Kevin Ryde <user42_kevin@yahoo.com.au> writes:
 >
 >> In debian packaged emacs 25.1 but git head ses.el, it seems cell
 >> evaluations sometimes run with inhibit-quit.  For example, initial entry
 >>
 >>     emacs -Q /tmp/foo.ses
 >>     Ret                           # enter formula
 >>     inhibit-quit Ret              # the formula
 >>     =>
 >>     displays t
 >>
 >> I hoped no inhibit-quit while running formulas (and thought there wasn't
 >> previously), as protection against slow or accidentally infinite forms.
 >>
 >> I noticed this in my stock charting program where I communicate with a
 >> database sub-process by accept-process-input, and that func doesn't run
 >> under inhibit-quit.  I could with-local-quit and bail out in a sensible
 >> way, but perhaps there's not meant to be inhibit-quit anyway.
 >
 > Yes, ses.el binds inhibit-quit all over the place, presumably out of an
 > overabundance of caution (not wanting to mess up the display). But it
 > shouldn't do that while computing the formulas, you'd think.
 >
 > I've Cc'd the maintainer; perhaps he can weigh in here.
 >

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

[Lars Ingebrigtsen]

Vincent Belaïche <vincent.belaiche@gmail.com> writes:

> Anyway this discussion is certainly usefull as I have not yet thought
> how to handle quiting during such a permutation, and handling undoing of
> it --- idealy quitting would be possible, and undoing would undo only
> that part that have been done before the quit.

Yes, I think that'd be very nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Kevin Ryde]

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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I am not sure what was the exact intention, as this is code which was
  > written before I became maintainer of SES.

If you think it is worth the trouble, you could try to contact
previous developers and ask them.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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.