From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs Subject: bug#21747: 25.0.50; while-no-input breaks kbd event handling when called from post-command-hook Date: Sun, 25 Oct 2015 10:25:10 +0100 Message-ID: <87k2qbpafd.fsf@gnu.org> References: <87bnboemqb.fsf@gnu.org> <838u6sy9s1.fsf@gnu.org> <877fmcejgn.fsf@gnu.org> <83ziz8wrun.fsf@gnu.org> <8737x0egvm.fsf@gnu.org> <83vb9wwnc6.fsf@gnu.org> <874mhg1n25.fsf@gnu.org> <83si50wi2m.fsf@gnu.org> <87fv109yxo.fsf@gnu.org> <83lhasweeh.fsf@gnu.org> <87si4zpg97.fsf@gnu.org> <87oafnpdvh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445765191 29643 80.91.229.3 (25 Oct 2015 09:26:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Oct 2015 09:26:31 +0000 (UTC) Cc: storm@cua.dk, monnier@iro.umontreal.ca, 21747@debbugs.gnu.org, bruce.connor.am@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 25 10:26:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZqHZ5-0001mN-Iz for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Oct 2015 10:26:11 +0100 Original-Received: from localhost ([::1]:47054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqHZ4-0005E5-Me for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Oct 2015 05:26:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqHYz-0005Dz-W2 for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2015 05:26:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqHYw-0000PH-PM for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2015 05:26:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqHYw-0000PD-LY for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2015 05:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZqHYw-0002ud-Eq for bug-gnu-emacs@gnu.org; Sun, 25 Oct 2015 05:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Oct 2015 09:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21747 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21747-submit@debbugs.gnu.org id=B21747.144576513611151 (code B ref 21747); Sun, 25 Oct 2015 09:26:02 +0000 Original-Received: (at 21747) by debbugs.gnu.org; 25 Oct 2015 09:25:36 +0000 Original-Received: from localhost ([127.0.0.1]:37441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZqHYU-0002tm-JG for submit@debbugs.gnu.org; Sun, 25 Oct 2015 05:25:35 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:49390) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZqHYA-0002tD-6y for 21747@debbugs.gnu.org; Sun, 25 Oct 2015 05:25:33 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 95B3A20676 for <21747@debbugs.gnu.org>; Sun, 25 Oct 2015 05:25:13 -0400 (EDT) Original-Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 25 Oct 2015 05:25:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=RfmiB3YxXlxACtf8ooGGamd/50A=; b=LvEwj Uu676SggfTS2aiHImw78KGVQ1WZtPrVt9q/ugTwJSeJ2UlGMSL2wO5T0He/WKlCu ihxxJ4DaQcg3mFoJ9ON5eqVye5QxUNOZbm6JZ6FWUEJIe70ynu/o8rIJnIDFdGsF K1/sAtG71QFDhJ+RBjyUSjmPZl9OceaM/2J3AA= X-Sasl-enc: DUDIWg8RHxF4zmnZBpD7MsbFvTjOS6zu7ywzu1zQ6PqD 1445765113 Original-Received: from thinkpad-t440p (unknown [2.160.223.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 79FCB680109; Sun, 25 Oct 2015 05:25:12 -0400 (EDT) In-Reply-To: <87oafnpdvh.fsf@gnu.org> (Tassilo Horn's message of "Sun, 25 Oct 2015 09:10:42 +0100") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108014 Archived-At: Tassilo Horn writes: > By the way, I cannot reproduce an infloop in re-search-backward when > LIMIT is zero. Instead, with the current unchanged master code I also > have pretty much the same infloop on the SMIE lisp level as in the > previous mail where I patched the code in order not to run in LIMIT = > 0 cases: > > 1 -> (aggressive-indent--indent-if-changed) [snip] > | | | 4 -> (sh-smie-sh-forward-token) > | | | | 5 -> (sh-smie--newline-semi-p) > | | | | | 6 -> (sh-smie-sh-backward-token) > | | | | | | 7 -> (sh-smie--default-backward-token) > | | | | | | 7 <- sh-smie--default-backward-token: "if" > | | | | | | 7 -> (sh-smie--sh-keyword-p "if") > | | | | | | | 8 -> (sh-smie--keyword-p) > | | | | | | | | 9 -> (sh-smie-sh-backward-token) > | | | | | | | | | 10 -> (sh-smie--default-backward-token) > | | | | | | | | | 10 <- sh-smie--default-backward-token: "" > | | | | | | | | 9 <- sh-smie-sh-backward-token: "" > | | | | | | | 8 <- sh-smie--keyword-p: t > | | | | | | 7 <- sh-smie--sh-keyword-p: t > | | | | | 6 <- sh-smie-sh-backward-token: "if" > | | | | 5 <- sh-smie--newline-semi-p: nil > | | | 4 <- sh-smie-sh-forward-token: ";" Ok, that loop is caused by the call to `end-of-defun' in `aggressive-indent-indent-region-and-on': ;; And then we indent each following line until nothing happens. (forward-line 1) (skip-chars-forward "[:blank:]\n\r\xc") (let* ((eod (ignore-errors (save-excursion (end-of-defun) (point-marker)))) end-of-defun calls beginning-of-defun-raw which works/terminates, and then it calls end-of-defun-function which just does (forward-sexp 1) which calls forward-sexp-function being smie-forward-sexp-command which in turn calls smie-forward-sexp. Well, and that calls smie-next-sexp which loops because eventually the token returned by (funcall next-token) where next-token is a function which calls sh-smie-sh-forward-token returns ";". That adds (38 38) to toklevels and later to levels which is again popped somewhere below and then gets re-added, popped again, re-added... Hm, in one branch there's already a test if calling next-token actually moved point and if not, it throws 'return to terminate the loop. When I move that out of the branch, that seems to fix the issue. --8<---------------cut here---------------start------------->8--- diff --git a/lisp/emacs-lisp/smie.el b/lisp/emacs-lisp/smie.el index f305025..70ab6f3 100644 --- a/lisp/emacs-lisp/smie.el +++ b/lisp/emacs-lisp/smie.el @@ -706,6 +706,9 @@ smie-next-sexp (let* ((pos (point)) (token (funcall next-token)) (toklevels (cdr (assoc token smie-grammar)))) + (if (eq pos (point)) + ;; We did not move, so let's abort the loop. + (throw 'return (list t (point)))) (cond ((null toklevels) (when (zerop (length token)) @@ -719,10 +722,7 @@ smie-next-sexp (list t epos (buffer-substring-no-properties epos - (+ epos (if (< (point) epos) -1 1)))))))) - (if (eq pos (point)) - ;; We did not move, so let's abort the loop. - (throw 'return (list t (point)))))) + (+ epos (if (< (point) epos) -1 1)))))))))) ((not (numberp (funcall op-back toklevels))) ;; A token like a paren-close. (cl-assert (numberp ; Otherwise, why mention it in smie-grammar. --8<---------------cut here---------------end--------------->8--- But I'm really not sure if that's the right thing to do. Maybe it's better to fix sh-smie-sh-forward-token so that it doesn't return ";" when actually no movement did occur because we already started out at EOB. That would be this: --8<---------------cut here---------------start------------->8--- diff --git a/lisp/progmodes/sh-script.el b/lisp/progmodes/sh-script.el index fbb4a90..baed27b 100644 --- a/lisp/progmodes/sh-script.el +++ b/lisp/progmodes/sh-script.el @@ -1920,10 +1920,11 @@ sh-smie-sh-forward-token ;; Pretend the here-document is a "newline representing a ;; semi-colon", since the here-doc otherwise covers the newline(s). ";") - (let ((semi (sh-smie--newline-semi-p))) - (forward-line 1) - (if (or semi (eobp)) ";" - (sh-smie-sh-forward-token)))) + (unless (eobp) + (let ((semi (sh-smie--newline-semi-p))) + (forward-line 1) + (if (or semi (eobp)) ";" + (sh-smie-sh-forward-token))))) (forward-comment (point-max)) (cond ((looking-at "\\\\\n") (forward-line 1) (sh-smie-sh-forward-token)) --8<---------------cut here---------------end--------------->8--- I actually can't judge what's the right fix. I'd tend towards the more general change in smie.el because I had this delayed display/100% CPU issue also several times with clojure-mode though I haven't debugged it in detail there so cannot say if it has been the same issue there. Of course, the right fix might be something completely different, too. Bye, Tassilo