From unknown Mon Jun 16 16:06:10 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#52003 <52003@debbugs.gnu.org> To: bug#52003 <52003@debbugs.gnu.org> Subject: Status: Unexpected advising behavior due to recursive implementation Reply-To: bug#52003 <52003@debbugs.gnu.org> Date: Mon, 16 Jun 2025 23:06:10 +0000 retitle 52003 Unexpected advising behavior due to recursive implementation reassign 52003 emacs submitter 52003 Daniel Sausner severity 52003 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 20 12:04:31 2021 Received: (at submit) by debbugs.gnu.org; 20 Nov 2021 17:04:31 +0000 Received: from localhost ([127.0.0.1]:43590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moTmx-0003uP-7M for submit@debbugs.gnu.org; Sat, 20 Nov 2021 12:04:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:59934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moSzn-0002ND-76 for submit@debbugs.gnu.org; Sat, 20 Nov 2021 11:13:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moSzj-0007jZ-Lh for bug-gnu-emacs@gnu.org; Sat, 20 Nov 2021 11:13:42 -0500 Received: from mout02.posteo.de ([185.67.36.66]:47759) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moSzh-0002KQ-1M for bug-gnu-emacs@gnu.org; Sat, 20 Nov 2021 11:13:39 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 0B621240101 for ; Sat, 20 Nov 2021 17:13:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1637424814; bh=aqf2PTwggHzepUIPDVeBjwgg5Bt56LsPaxWoHpIy6OA=; h=To:From:Subject:Date:From; b=RwcFT+d+UwAFQEUk65bKcRpiGlOwIXs4nMIdkmU64Ycfy/nASei4iXKPyXb9bI/k7 l+fnA/rndeOHE1HxUOJ88D2qb+lusr8H8WSaU0CELf1sXuHM4usIJTYMKO63WO6TQY 0XvMNS37MIHF9AFHq0+f4VhTnc3JydjpbN73XEA8zKNPVrVH6H69B8H38XY1vNOe55 b4u6nI45++udcdlLFksNhK2mNFrzb2PkpOcSo/HfR8+uNvZcA703DlojZTGnw8cynk nJT6xpihvgaoLBQt5ksnCpSjtoHkeaQXtM3yYvagTGV5lNwUpcxnloUes1enGCSOiy Ejlv9RjE4pktA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4HxJVj3Vqrz9rxN for ; Sat, 20 Nov 2021 17:13:33 +0100 (CET) To: bug-gnu-emacs@gnu.org From: Daniel Sausner Subject: Unexpected advising behavior due to recursive implementation Message-ID: <9f9a3c25-c473-ce45-9293-9754b8bcc113@posteo.de> Date: Sat, 20 Nov 2021 16:13:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: de-DE Received-SPF: pass client-ip=185.67.36.66; envelope-from=daniel.sausner@posteo.de; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sat, 20 Nov 2021 12:04:30 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi, I stumbled [1] on an issue that seems to affect several functions [2] in lisp/emacs-lisp/lisp.el. For the sake of brevity I'll sketch it only for forward-sexp but the problematic code is effectively duplicated and was introduced with a commit [3] about one year ago. Here's the problem: Since the commit any advice on the function forward-sexp will effectively be called twice before the actual code runs in interactive mode. In non-interactive mode everthing is as expected however. The reason is the introduction of an error message if no forward/backward sexp is found. This is implemented in a way that the functions calls itself immediately again and scans for errors: (defun forward-sexp (&optional arg interactive)   "..."   (interactive "^p\nd")   (if interactive       (condition-case _           (forward-sexp arg nil)              <-- Recursion         (scan-error (user-error (if (> arg 0)                                     "No next sexp"                                   "No previous sexp"))))     (or arg (setq arg 1))     (if forward-sexp-function         (funcall forward-sexp-function arg)       (goto-char (or (scan-sexps (point) arg) (buffer-end arg)))       (if (< arg 0) (backward-prefix-chars))))) In my (very) humble opinion that method of error catching was an unfortunate choice in that regard, that it makes the advising very counter-intuitive. I'm far from a lisp expert but my feeling is that the condition-case should only wrap the calls where things can actually go wrong. If there is interest, I'd be happy to provide a patch :-) Best regards, Daniel [1] https://github.com/emacs-evil/evil/issues/1541 [2] On a first glimpse at least: forward-sexp, forward-list, down-list, kill-sexp in that particular file. [3] Commit: df0f32f04850e7ed106a225addfa82f1b5b91f45 Author:     Mattias Engdegård AuthorDate: Fri Sep 18 12:49:33 2020 +0200 Commit:     Mattias Engdegård CommitDate: Wed Sep 23 16:31:18 2020 +0200 Don't signal scan-error when moving by sexp interactively From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 20 14:16:56 2021 Received: (at 52003) by debbugs.gnu.org; 20 Nov 2021 19:16:56 +0000 Received: from localhost ([127.0.0.1]:43684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moVr6-0003jn-LJ for submit@debbugs.gnu.org; Sat, 20 Nov 2021 14:16:56 -0500 Received: from mail1447c50.megamailservers.eu ([91.136.14.47]:47798 helo=mail265c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moVr2-0003jQ-Rl for 52003@debbugs.gnu.org; Sat, 20 Nov 2021 14:16:55 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1637435805; bh=0mOrNWsI9hu2AeF4E2HLc+YkoeYQ2AHrMVtTsXGoIJg=; h=From:Subject:Date:Cc:To:From; b=g4jmpe7ckHjykcdpLqY7jXS55sghYZ9bknY8ogsYYN/N+IPj7JoPLoK3y769lWVkl MhWuhKZqGlf/cX6FswUZzsXfwII2JrfhQITl+XZLNBOdgGJEUOVnLPx+ARLpPSGQXD MUPlSnnQyW2Suom9fP39wzwznRldrugunZK5/Xlg= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.tele2.se [188.150.171.71]) (authenticated bits=0) by mail265c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 1AKJGh3v004702; Sat, 20 Nov 2021 19:16:45 +0000 From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: bug#52003: Unexpected advising behavior due to recursive implementation Message-Id: <43094E20-7F74-4CE0-ABE7-4348ADFFFCE0@acm.org> Date: Sat, 20 Nov 2021 20:16:43 +0100 To: Daniel Sausner X-Mailer: Apple Mail (2.3445.104.21) X-CTCH-RefID: str=0001.0A742F15.6199499D.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.4 cv=MIcDJOVl c=1 sm=1 tr=0 ts=6199499d a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=y9_8w6m7_nBXPDs2BXMA:9 a=CjuIK1q_8ugA:10 X-Origin-Country: SE X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Thanks for the report, and yes, it's true that the way interactive use is managed makes advice hacks more interesting. Do remember that you are always on your own when using advice; Emacs cannot reaso [...] Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.4 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-Debbugs-Envelope-To: 52003 Cc: 52003@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Thanks for the report, and yes, it's true that the way interactive use = is managed makes advice hacks more interesting. Do remember that you are = always on your own when using advice; Emacs cannot reasonably promise = any compatibility on that level. That said, it would be straightforward to straighten out the control = flow by extracting the bulk of the code to a new (internal) function = which is called with or without `condition-case`. It would be slightly = slower since it entails an extra function call in the non-interactive = case, and forward-sexp and its ilk are workhorses in many language = modes. It may not matter much, of course. > I'm far from a lisp expert but my feeling is that the condition-case=20= > should only wrap the calls where things can actually go wrong. Oh, but in this case they can. Noninteractive calls expect the = scan-errors; interactive use does not. It is also possible for a a = forward-sexp-function to raise scan-error. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 21 06:08:54 2021 Received: (at 52003) by debbugs.gnu.org; 21 Nov 2021 11:08:54 +0000 Received: from localhost ([127.0.0.1]:44323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mokiL-0003lI-N7 for submit@debbugs.gnu.org; Sun, 21 Nov 2021 06:08:53 -0500 Received: from mail1467c50.megamailservers.eu ([91.136.14.67]:43408 helo=mail268c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mokiI-0003l1-HF for 52003@debbugs.gnu.org; Sun, 21 Nov 2021 06:08:51 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1637492923; bh=rXDPSHp8kZ7nKavabdhllPp7p/5m9yIl1TelVx3Sna4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=r6XzKI1tOYShvvOg1QP1mGDpXiz5lwz2/tQAwgLyV9y+6qxw7jhgonvCfJYp0K6J1 mrVzvwfTxgSWI3Mij52GsWldoc631hCXBAxSRuLcuy1fe8Zhsdz2zMj/lmWrMh1W+d EdDjeBVba8c9rHBfqG4VRVxr9gjU8yV10H+v7Pys= Feedback-ID: mattiase@acm.or Received: from [192.168.0.4] (c188-150-171-71.bredband.tele2.se [188.150.171.71]) (authenticated bits=0) by mail268c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 1ALB8efB025026; Sun, 21 Nov 2021 11:08:42 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: bug#52003: Unexpected advising behavior due to recursive implementation From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: Date: Sun, 21 Nov 2021 12:08:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43094E20-7F74-4CE0-ABE7-4348ADFFFCE0@acm.org> To: Daniel Sausner X-Mailer: Apple Mail (2.3445.104.21) X-CTCH-RefID: str=0001.0A742F1C.619A28BA.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.4 cv=B8LabMhM c=1 sm=1 tr=0 ts=619a28bb a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=zZOMBPAxS-NNN_PNjq0A:9 a=CjuIK1q_8ugA:10 X-Origin-Country: SE X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 21 nov. 2021 kl. 10.32 skrev Daniel Sausner : > I see. I somehow assumed that functions at that level would aim to be compliant to the max. Yes but what would that mean? The best we can do is to promise that a function F, when called in a manner consistent with the documentation, behaves accordingly. We cannot guarantee the absence of cal [...] Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.4 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS X-Debbugs-Envelope-To: 52003 Cc: 52003@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 21 nov. 2021 kl. 10.32 skrev Daniel Sausner : > I see. I somehow assumed that functions at that level would aim to be = compliant to the max. Yes but what would that mean? The best we can do is to promise that a = function F, when called in a manner consistent with the documentation, = behaves accordingly. We cannot guarantee the absence of calls to F, can = we? But unless I'm mistaken, that's what you are unhappy about: = `forward-sexp` may call itself when you call it. A lot of other code = calls that function as part of their implementation. Don't they cause = trouble, or is it just the recursive call? > Well, I'd say that in that case the non-interactive performance = outweighs this particular corner case of advising these core functions, = which I came to understand is a hot iron. The cost of that extra function call is probably going to be lost in the = noise. I'm not looking for excuses to avoid work here but would like to = know what problem rearranging the code would actually solve.=20 > Therefore I'd say this bug report can be closed from my point of view. = I guess I still have to use advising as I currently see no other = feasible way out, but I can make it sensitive to `interactive` as well. What are you trying to do? Can't you define a mode-specific = forward-sexp-function? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 21 12:17:53 2021 Received: (at 52003) by debbugs.gnu.org; 21 Nov 2021 17:17:53 +0000 Received: from localhost ([127.0.0.1]:45891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moqTQ-0001Bq-Up for submit@debbugs.gnu.org; Sun, 21 Nov 2021 12:17:53 -0500 Received: from mout01.posteo.de ([185.67.36.65]:58649) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mojDP-0001FJ-Qp for 52003@debbugs.gnu.org; Sun, 21 Nov 2021 04:32:53 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 04D14240029 for <52003@debbugs.gnu.org>; Sun, 21 Nov 2021 10:32:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1637487165; bh=sDJ6bHaIdt+hUmQgcAJCNAkq5pYfyUCQ9kILcUacDqs=; h=Subject:To:Cc:From:Date:From; b=od2J9438yPq6vet/mL/8JxHnhxAPd78YT/Aini5XRBhZBi7jyWWr70tnRw9JemBZF O9DtB29DzGbYLTj5KCz13sQNu2qh5VJN3otUKHtF92kfLBd85MTepO2JLMnbrpRJpr VVFATCd+Aa6fov7FC/iyx4NRA3x2YyubVzT2/IqYaNeYTfuCN3bHX1mMZ8UGM4I9d1 9FBNvKdEyieadC4taCnXLdSFTk2Gk6Q0zbxqU5xGaL2xhSND4b6AwyZZhMLj4eZ4JG Vuh/VaU0WCoeGRY+wPRgwVeQ8SHh4D2lX+F3paMoJIcuiVJze1Fbi+Haf0vYrNjeNe 1VHyE1C1r1mlA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4HxlYm0rSMz6tny; Sun, 21 Nov 2021 10:32:43 +0100 (CET) Subject: Re: bug#52003: Unexpected advising behavior due to recursive implementation To: =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= References: <43094E20-7F74-4CE0-ABE7-4348ADFFFCE0@acm.org> From: Daniel Sausner Message-ID: Date: Sun, 21 Nov 2021 09:32:43 +0000 MIME-Version: 1.0 In-Reply-To: <43094E20-7F74-4CE0-ABE7-4348ADFFFCE0@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-DE X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52003 X-Mailman-Approved-At: Sun, 21 Nov 2021 12:17:52 -0500 Cc: 52003@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Do remember that you are always on your own when using advice; Emacs > cannot reasonably promise any compatibility on that level. I see. I somehow assumed that functions at that level would aim to be compliant to the max. > That said, it would be straightforward to straighten out the control flow by extracting the bulk of the code to a new (internal) function which is called with or without `condition-case`. It would be slightly slower since it entails an extra function call in the non-interactive case, and forward-sexp and its ilk are workhorses in many language modes. It may not matter much, of course. Well, I'd say that in that case the non-interactive performance outweighs this particular corner case of advising these core functions, which I came to understand is a hot iron. Therefore I'd say this bug report can be closed from my point of view. I guess I still have to use advising as I currently see no other feasible way out, but I can make it sensitive to `interactive` as well. Thanks for the helpful input! From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 21 12:29:47 2021 Received: (at 52003) by debbugs.gnu.org; 21 Nov 2021 17:29:48 +0000 Received: from localhost ([127.0.0.1]:45914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moqex-0001Uv-Lc for submit@debbugs.gnu.org; Sun, 21 Nov 2021 12:29:47 -0500 Received: from mout02.posteo.de ([185.67.36.66]:45255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moqeu-0001Uf-TN for 52003@debbugs.gnu.org; Sun, 21 Nov 2021 12:29:46 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 5AD51240104 for <52003@debbugs.gnu.org>; Sun, 21 Nov 2021 18:29:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1637515778; bh=zPhQaY6QulJo2Rq9rz2irX66H8VdIHYogeRgfzLQ1BE=; h=Subject:To:Cc:From:Date:From; b=OiBaPsACViStcjcBPVb0xRnX9nniv+xWvV2DsJ+EB/kA35r9pqC5URGnLNuTN5Kbx +69Oaqe4fxaEZ8JyglWOiQIuoRw7Nf+Da3kWaJQo/6z1oNdGmf39QTXLpymK2pNl5e DrufVYUzdqwkdhAB7GES6T4/t80k8T1AIdEnJrDwsKPU74NUrJAbFSxAEQO2N3yWOI zh7IYiWEgDbdWIG1hP0yjNVFYxODiH06av+xor05MoV3vVRPuHxa8BBRB2esUP5dIi 02WArybJStdQng307fSxe3MBJ4mGn+oaRdzwlLWc+PwkZGG0s52K0DMUkihxMd0W0v P/9bvTig1PxRA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Hxy812Z21z9rxG; Sun, 21 Nov 2021 18:29:37 +0100 (CET) Subject: Re: bug#52003: Unexpected advising behavior due to recursive implementation To: =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= References: <43094E20-7F74-4CE0-ABE7-4348ADFFFCE0@acm.org> From: Daniel Sausner Message-ID: <18a2668d-746e-24e7-06fd-f87904a3e7ca@posteo.de> Date: Sun, 21 Nov 2021 17:29:36 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-DE X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52003 Cc: 52003@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Yes but what would that mean? The best we can do is to promise that a function F, when called in a manner consistent with the documentation, behaves accordingly. We cannot guarantee the absence of calls to F, can we? > > But unless I'm mistaken, that's what you are unhappy about: `forward-sexp` may call itself when you call it. A lot of other code calls that function as part of their implementation. Don't they cause trouble, or is it just the recursive call? Well, my initial concern was the (new) recursive call, which adds another layer of complexity for advising. I now see too that an advice on such a deep rooted function is kind of madness anyway. In fact I would need to make a distinction between the interactive modes both ways. > What are you trying to do? Can't you define a mode-specific forward-sexp-function? The problem I'm trying to solve is, that the cursor in evil normal state is not between chars but _on_ a char. Moving to the end of a sexp in lisp I would expect the cursor to be on the closing paren instead of behind it. There was already an advice planted on `elisp--precedent-sexp` to achieve this effect for `eval-last-sexp`. It basically only moves the point one char forward if in normal mode before eval-last-sexp, hence the sexp including the paren on which the cursor rests will be evaluated instead of the thing before the cursor/paren. I wanted to transport this behaviour to the motion-sexp commands and initially I was naive enough to think that this is a low hanging fruit, because I could take the same advice function and add it to backward/forward-sexp. In essence I would like to move the visible cursor by a single char in one or the other direction before and after one or more `forward-sexp`-based commands are executed. But I'm not sure anymore if this is really worth the effort :-) From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 22 04:21:09 2021 Received: (at 52003-done) by debbugs.gnu.org; 22 Nov 2021 09:21:09 +0000 Received: from localhost ([127.0.0.1]:46895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp5Vc-0007RT-7B for submit@debbugs.gnu.org; Mon, 22 Nov 2021 04:21:09 -0500 Received: from mail18c50.megamailservers.eu ([91.136.10.28]:49488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp5VW-0007QZ-84 for 52003-done@debbugs.gnu.org; Mon, 22 Nov 2021 04:21:06 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1637572859; bh=bvjUGRBcrVEgD0mlS1WFteoi3H9sgCjw1QE77PD65Sk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=c8Ny7g/z3xYO8324plGGEBu8eyDksa8h5Z+i8mC9nzIQaofCvje5w4GUPeYEMtnn9 kl2YkZnMKSB2s9vpZO5oFy02YFZa+ofyX+H1tNW4dcfiTnIjPQd/iDQqt8Q8sPgvBF tOpsUQdO4NEFws1gmqFtR81n45ZYKQbMOCm985ZM= Feedback-ID: mattiase@acm.or Received: from stanniol.lan (c-b952e353.032-75-73746f71.bbcust.telenor.se [83.227.82.185]) (authenticated bits=0) by mail18c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 1AM9KvkP023761; Mon, 22 Nov 2021 09:20:58 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: bug#52003: Unexpected advising behavior due to recursive implementation From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <18a2668d-746e-24e7-06fd-f87904a3e7ca@posteo.de> Date: Mon, 22 Nov 2021 10:20:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43094E20-7F74-4CE0-ABE7-4348ADFFFCE0@acm.org> <18a2668d-746e-24e7-06fd-f87904a3e7ca@posteo.de> To: Daniel Sausner X-Mailer: Apple Mail (2.3445.104.21) X-CTCH-RefID: str=0001.0A742F22.619B60FB.0070, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.4 cv=GKNrrsBK c=1 sm=1 tr=0 ts=619b60fb a=von4qPfY+hyqc0zmWf0tYQ==:117 a=von4qPfY+hyqc0zmWf0tYQ==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=M_j1DYGIt9Gg4M8JyOEA:9 a=CjuIK1q_8ugA:10 X-Origin-Country: SE X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 52003-done Cc: 52003-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 21 nov. 2021 kl. 18.29 skrev Daniel Sausner : > The problem I'm trying to solve is, that the cursor in evil normal = state is not between chars but _on_ a char. Moving to the end of a sexp = in lisp I would expect the cursor to be on the closing paren instead of = behind it. > In essence I would like to move the visible cursor by a single char in = one or the other direction before and after one or more = `forward-sexp`-based commands are executed. But I'm not sure anymore if = this is really worth the effort :-) Thanks for the explanation. Sounds fiddly. Best of luck! I'm closing = this bug then. From unknown Mon Jun 16 16:06:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 20 Dec 2021 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator