From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Nicolas Goaziou Newsgroups: gmane.emacs.bugs Subject: bug#31361: 25.3; Issue when advising `indent-line-function' Date: Sat, 05 May 2018 16:26:27 +0200 Message-ID: <87o9huci6b.fsf@nicolasgoaziou.fr> References: <87sh78phj1.fsf@nicolasgoaziou.fr> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1525530310 32056 195.159.176.226 (5 May 2018 14:25:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 May 2018 14:25:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cc: Stefan Monnier To: 31361@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 05 16:25:06 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fEy7S-0008Ag-PW for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 May 2018 16:25:02 +0200 Original-Received: from localhost ([::1]:39014 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fEy9Z-0006lu-HK for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 May 2018 10:27:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fEy9S-0006lX-9T for bug-gnu-emacs@gnu.org; Sat, 05 May 2018 10:27:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fEy9O-0000ve-TK for bug-gnu-emacs@gnu.org; Sat, 05 May 2018 10:27:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42870) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fEy9O-0000vL-Ou for bug-gnu-emacs@gnu.org; Sat, 05 May 2018 10:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fEy9O-0000gQ-Fs for bug-gnu-emacs@gnu.org; Sat, 05 May 2018 10:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nicolas Goaziou Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 May 2018 14:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31361 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31361-submit@debbugs.gnu.org id=B31361.15255303952586 (code B ref 31361); Sat, 05 May 2018 14:27:02 +0000 Original-Received: (at 31361) by debbugs.gnu.org; 5 May 2018 14:26:35 +0000 Original-Received: from localhost ([127.0.0.1]:50767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fEy8x-0000fd-43 for submit@debbugs.gnu.org; Sat, 05 May 2018 10:26:35 -0400 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:50155) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fEy8u-0000fT-VN for 31361@debbugs.gnu.org; Sat, 05 May 2018 10:26:33 -0400 X-Originating-IP: 185.131.40.67 Original-Received: from saiph (40-67.ipv4.commingeshautdebit.fr [185.131.40.67]) (Authenticated sender: admin@nicolasgoaziou.fr) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 03CAF1BF204; Sat, 5 May 2018 16:26:35 +0200 (CEST) Original-Received: from ngz by saiph with local (Exim 4.89) (envelope-from ) id 1fEy8p-0007Ri-FX; Sat, 05 May 2018 16:26:27 +0200 In-Reply-To: <87sh78phj1.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Thu, 03 May 2018 23:15:46 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:146034 Archived-At: Nicolas Goaziou writes: > When `indent-line-function' is advised, using `add-function', and the > variable contains `indent-relative', `indent-according-to-mode' has an > erratic behavior. > > In the following code, from `indent-according-to-mode', > > (if (memq indent-line-function > '(indent-relative indent-relative-maybe)) > ... > ;; The normal case. > (funcall indent-line-function)) > > the if branch is no longer executed because `indent-line-function' is no > longer `indent-relative' but a closure around it. Thinking more about the problem, I think I can describe it differently. When `indent-line-function' is set to `indent-relative' -- or `indent-relative-maybe' -- the function `indent-relative' is not meant to be actually called to handle the indentation. Instead, some ad-hoc indentation is hard-coded into `indent-according-to-mode', which see. However, when `indent-line-function' is advised, according to my previous report, `indent-relative' is actually called for indentation, which is not the intent, per above. So basically, any call to `indent-according-to-mode', e.g., with `reindent-then-newline-and-indent' or through Electric Indent mode, is broken whenever `indent-relative' is advised. One idea, suggested by Stefan, would be to write `indent-according-to-mode' like the following: (if (memq (advice--cd*r indent-line-function) '(indent-relative indent-relative-maybe)) ... ;; The normal case. (funcall indent-line-function)) i.e., strip advices so that the ad-hoc code is executed, as intended, instead of ultimately calling `indent-relative'. Unfortunately, this is insufficient because the advices are not applied, which is also wrong. If this stripping is done, it should also ensure that advices are applied on the ad-hoc indentation code there. FWIW, my gut feeling is that `indent-relative' -- and `indent-relative-maybe' -- ought to be normalized to behave like a normal indentation function, i.e., a function actually called from `indent-according-to-mode'. This was the case before commit a17b712b4d812d28086ae9af02f9043b36cf3e19 (Oct 30 2001). Currently, `indent-relative' is two-sided. Therefore, the previous suggestion might entail to split `indent-relative' into two parts, one meant to be used as a value for `indent-line-function' -- maybe named `indent-relative-function' -- and the other one to be used like current `indent-relative', i.e., jumping from one indent point to the other.