From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#5852: 23.1; Incorrect references in ses-mode Date: Fri, 30 Jul 2021 17:01:29 -0400 Message-ID: References: <845zfpi242.fsf@gmail.com> <871r7vrbez.fsf@gnus.org> <8735s2zydl.fsf@gnus.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34747"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stefan Kangas , Lars Ingebrigtsen , Vincent =?UTF-8?Q?Bela=C3=AFche?= , 5852@debbugs.gnu.org, =?UTF-8?Q?G=C3=B6ran?= Uddeborg To: Vincent =?UTF-8?Q?Bela=C3=AFche?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 30 23:02:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m9Ze1-0008se-97 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Jul 2021 23:02:13 +0200 Original-Received: from localhost ([::1]:55726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9Ze0-0004jX-7o for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Jul 2021 17:02:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9Zdq-0004jG-D1 for bug-gnu-emacs@gnu.org; Fri, 30 Jul 2021 17:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49522) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m9Zdq-0004MA-4i for bug-gnu-emacs@gnu.org; Fri, 30 Jul 2021 17:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m9Zdq-0001Bi-3D for bug-gnu-emacs@gnu.org; Fri, 30 Jul 2021 17:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Jul 2021 21:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5852 X-GNU-PR-Package: emacs Original-Received: via spool by 5852-submit@debbugs.gnu.org id=B5852.16276789014540 (code B ref 5852); Fri, 30 Jul 2021 21:02:02 +0000 Original-Received: (at 5852) by debbugs.gnu.org; 30 Jul 2021 21:01:41 +0000 Original-Received: from localhost ([127.0.0.1]:32835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9ZdV-0001B9-G2 for submit@debbugs.gnu.org; Fri, 30 Jul 2021 17:01:41 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9ZdT-0001Aw-MQ for 5852@debbugs.gnu.org; Fri, 30 Jul 2021 17:01:40 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 93D8F100221; Fri, 30 Jul 2021 17:01:33 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E13941001E8; Fri, 30 Jul 2021 17:01:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1627678890; bh=V3JrspgM5evauSTBI+GfTQxBmP2Gvnsy8FNwfouJHxA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=jGoOPDjWiMuSBhA3qBcF+e8FtxXzwHH2Qfd9TceOheEeHvqXnoAxtCKMT/H8O+b3G 3zno+0s/nsEOpYbJNo0fjIRJuwc0gwpTgoSCikuhHcpVXv3y89EuhnaqkXWOunLW8c IbtliyV0M/LHTT5zJbmL0I+7xXEXxwXs1zM/jogGEIUEYBYCCEgYl17Ym2I3CHLUQc 8b0bVTEfxsFUNMC8VAVGWg62TE7BPmjv+ng6TmGsCjhv9bwW+8MnXcYkquPwOEkMRK kAN3B2vKJnukUBOa2z+qrg3ZTpMDAFCgWAK/jI38qFDFAnrQuX8fbSR8fsOhdpueE3 CgwpJ3AbyirJw== Original-Received: from alfajor (unknown [216.154.29.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 93924120208; Fri, 30 Jul 2021 17:01:30 -0400 (EDT) In-Reply-To: ("Vincent =?UTF-8?Q?Bela=C3=AFche?="'s message of "Sun, 25 Jul 2021 19:27:21 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:210950 Archived-At: > are run sequentially in the command loop : post-command hook of > command N does not overlap command N+1, please confirm =E2=80=A6 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 coordinates). Stefan