[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: bug#5852: 23.1; Incorrect references in ses-mode
Date: Fri, 30 Jul 2021 17:01:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> are run sequentially in the command loop : post-command hook of
> command N does not overlap command N+1, please confirm …

That's usually true, yes.  There can be exceptions when command N itself
can run commands during execution, via a recursive command-loop
(e.g. query&replace uses that, or minibuffer interactions).

> Now, I have another speculation : SES gets the current cell from the
> cursor position by reading some buffer text property
> 'cursor-intangible.  I speculate that the radix of the bug is that when
> a command sets this cursor property, then the buffer is actually
> modified in the backgroun, and the change may not be yet in effect
> when the next command runs.  Could you confirm / infirm this
> speculation.

Hmm... no that doesn't sound right.  Emacs does try to do a few things
in the background, but it's quite limited (things like `font-lock`,
basically).  When a property like `cursor-intangible` is set, it
happens immediately.

> One more thing is the following : in SES the cursor-intangile property
> is the symbol corresponding to the cell object (which under the hood
> is a vector), not the cell object itself. This means that the property
> has to change when there are row/column insertion / deletion, which
> also inherently change the buffer, because of symbol relocation. I
> think this might be some bad design choice, and pointing directly at
> the cell object would have saved some troubles (and probably would
> also create a bunch of other problems, so do not take my statement for
> sure).

Indeed, pointing directly at the cell's vector would probably be better
(at least from the point of view of insertions/deletions but), but if
so, each cell would probably need to contain its own name (or its


reply via email to

[Prev in Thread] Current Thread [Next in Thread]