bug#5852: 23.1; Incorrect references in ses-mode

[Vincent Belaïche]

By doing the test manually on my home PC I found some interesting
difference. After

2 RET

on my home PC the cursor goes to the end of buffer narrowed region,
while on my office PC it goes to B2. This means that the TAB that
follows won't the same effect. On my home PC it creates a 3rd row,
while on my office PC it creates the 3rd column.
I found the reason why so : my home PC had some customization for the
ses-after-entry-functions. After erasing customization I had the same
behaviour …
Anyway, that does not affect the bug-5852 test function as it only
uses ses-jump for motion.
  V.

Le dim. 25 juil. 2021 à 08:18, Vincent Belaïche
<vincent.belaiche@gmail.com> a écrit :
>
> The bug-5852 test function does not reproduce the bug on my home PC either …
>   V.
>
> Le dim. 25 juil. 2021 à 08:17, Vincent Belaïche
> <vincent.belaiche@gmail.com> a écrit :
> >
> > The same test function, but with comments :
> >
> >
> > (defun bug-5852 ();;---
> >   "Check no irrelevant reference is created when a row is inserted and
> > a formula is yanked"
> >   (interactive);;---
> >   (let ((ses-initial-size '(3 . 3))); size before last row insertion,
> > due to all preceding TAB & C-o
> >   (with-temp-buffer
> >     (ses-mode)
> >     (dolist (val '(
> >                    (ses-edit-cell 0 1 1) ; 1 RET
> >                    (ses-edit-cell 1 0 2) ; 2 RET
> >                    (ses-edit-cell 1 1 (+ B1 A2)) ; ( + SPC B1 SPC A2 RET
> >                    (ses-edit-cell 2 0 3) ; 3 RET
> >                    (ses-edit-cell 2 1 (+ B2 A3)) ; ( + SPC B2 SPC A3 RET
> >                    (ses-jump A3) ; C-n
> >                    (ses-insert-row 1) ; C-o
> >                    (ses-edit-cell 2 0 4) ; 4 RET
> >                    (ses-jump B2) ; C-p
> >                    ))
> >       (apply 'funcall-interactively  val)
> >       (ses-command-hook))
> >   (let ((beg (point-marker))); C-SPC
> >     (ses-jump 'C2) ; C-f
> >     (copy-region-as-kill beg (point) nil); M-w
> >     (set-marker beg nil))
> >   (dolist (val '(
> >                  (ses-jump B3); C-n C-b
> >                  (yank) ; C-y
> >                  (ses-jump B4); C-n
> >                  (yank); C-y
> >                  ))
> >     (apply 'funcall-interactively  val)
> >     (ses-command-hook))
> >   (ses-repair-cell-reference-all)
> >   )))
> >
> > Le dim. 25 juil. 2021 à 07:56, Vincent Belaïche
> > <vincent.belaiche@gmail.com> a écrit :
> > >
> > > On more significant difference between the function bug-5852 and the
> > > example is the the initial size is (3 . 3) instead of (1. 1). This is
> > > because I speculated that only the last row insertion (C-o) plays a
> > > role.
> > >
> > >   V.
> > >
> > > Le dim. 25 juil. 2021 à 07:48, Vincent Belaïche
> > > <vincent.belaiche@gmail.com> a écrit :
> > > >
> > > > Just to add something : reading again SES code, and (info "(elisp)
> > > > Command Overview") I am a bit skeptical about the explanation in my
> > > > previous email.
> > > > It seems that only key strokes are queue, but command execution and
> > > > post command hook are in sequence, so not done concurrently.
> > > > I wrote this function to try to reproduce the bug, and on my office PC
> > > > it does not reproduce it:
> > > >
> > > > (defun bug-5852 ();;---
> > > >   "Check no irrelevant reference is created when a row is inserted and
> > > > a formula is yanked"
> > > >   (interactive);;---
> > > >   (let ((ses-initial-size '(3 . 3)))
> > > >   (with-temp-buffer
> > > >     (ses-mode)
> > > >     (dolist (val '(
> > > >                    (ses-edit-cell 0 1 1)
> > > >                    (ses-edit-cell 1 0 2)
> > > >                    (ses-edit-cell 1 1 (+ B1 A2))
> > > >                    (ses-edit-cell 2 0 3)
> > > >                    (ses-edit-cell 2 1 (+ B2 A3))
> > > >                    (ses-jump A3)
> > > >                    (ses-insert-row 1)
> > > >                    (ses-edit-cell 2 0 4)
> > > >                    (ses-jump B2)
> > > >                    ))
> > > >       (apply 'funcall-interactively  val)
> > > >       (ses-command-hook))
> > > >     (let ((beg (point-marker)))
> > > >       (ses-jump 'C2) ; C-n
> > > >       (copy-region-as-kill beg (point) nil)
> > > >       (set-marker beg nil))
> > > >     (dolist (val '(
> > > >                    (ses-jump B3)
> > > >                    (yank)
> > > >                    (ses-jump B4)
> > > >                    (yank)
> > > >                    ))
> > > >       (apply 'funcall-interactively  val)
> > > >       (ses-command-hook))
> > > >     (ses-repair-cell-reference-all)
> > > >     )))
> > > >
> > > > Please note that the main difference with the provided example is that
> > > > motion is done with ses-jump, and not with motion commands. Also the
> > > > save to keyring is not done interatively.
> > > >    V.
> > > >
> > > > Le sam. 24 juil. 2021 à 23:46, Vincent Belaïche
> > > > <vincent.belaiche@gmail.com> a écrit :
> > > > >
> > > > > Hello Lars,
> > > > >
> > > > > Sorry for not making any feedback for so long, actually I was just
> > > > > distracted by some other business, and I somewhat had forgotten about
> > > > > it.
> > > > >
> > > > > I suspect a race condition between the post command hook and the next
> > > > > command. That is to say when one yanks the fomula (the first yank),
> > > > > one relocates the reference but for this one uses current references
> > > > > that have not yet been relocated because the previous post-command
> > > > > hook execution is not yet over.
> > > > >
> > > > > The bug does not show every time I do the experiment. I tried this
> > > > > morning with my office PC which is a fast machine, and it proved out
> > > > > quite hard to reproduce, even when I launched some big C program
> > > > > compilation in parallel to eat the mips.
> > > > >
> > > > > Next week I will do some experiment with my home PC which is quite
> > > > > quite slower, and I make some feedback. Unfortunateless both machine
> > > > > do not have the same emacs version, but anyway all changes in SES
> > > > > since the version on my home PC are not related to this bug, so
> > > > > nevertheless that will be a good indication whether my guess is
> > > > > correct.
> > > > >
> > > > >   V.
> > > > >
> > > > > Le dim. 18 juil. 2021 à 15:37, Lars Ingebrigtsen <larsi@gnus.org> a 
> > > > > écrit :
> > > > > >
> > > > > > Vincent Belaïche <vincentbelaiche@orange.fr> writes:
> > > > > >
> > > > > > > I will investigate why and feed back once I have a better idea of 
> > > > > > > what
> > > > > > > is happening.
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > this was a year ago.  Did you make any progress on this issue?
> > > > > >
> > > > > > --
> > > > > > (domestic pets only, the antidote for overdose, milk.)
> > > > > >    bloggy blog: http://lars.ingebrigtsen.no