From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Markus Triska Newsgroups: gmane.emacs.bugs Subject: bug#21526: 24.5; prolog-mode: broken indentation for if-then-else construct Date: Wed, 21 Oct 2015 01:47:22 +0200 Message-ID: References: <8737xwbeo0.fsf@metalevel.at> <87a8rw27vh.fsf@metalevel.at> <87egh8rlnn.fsf@metalevel.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445387522 5606 80.91.229.3 (21 Oct 2015 00:32:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Oct 2015 00:32:02 +0000 (UTC) Cc: 21526@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 21 02:31:51 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 1ZohJb-0007Io-DA for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Oct 2015 02:31:39 +0200 Original-Received: from localhost ([::1]:48585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZohJa-0000Ky-Lp for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Oct 2015 20:31:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZogdR-0004dM-Rz for bug-gnu-emacs@gnu.org; Tue, 20 Oct 2015 19:48:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZogdO-0007oc-LF for bug-gnu-emacs@gnu.org; Tue, 20 Oct 2015 19:48:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZogdO-0007oI-H5 for bug-gnu-emacs@gnu.org; Tue, 20 Oct 2015 19:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZogdO-0003oc-DR for bug-gnu-emacs@gnu.org; Tue, 20 Oct 2015 19:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Oct 2015 23:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21526-submit@debbugs.gnu.org id=B21526.144538485114625 (code B ref 21526); Tue, 20 Oct 2015 23:48:02 +0000 Original-Received: (at 21526) by debbugs.gnu.org; 20 Oct 2015 23:47:31 +0000 Original-Received: from localhost ([127.0.0.1]:58515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zogct-0003np-37 for submit@debbugs.gnu.org; Tue, 20 Oct 2015 19:47:31 -0400 Original-Received: from static.59.150.47.78.clients.your-server.de ([78.47.150.59]:51715 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zogcp-0003nf-PG for 21526@debbugs.gnu.org; Tue, 20 Oct 2015 19:47:28 -0400 Original-Received: from dawn.meta (dawn.metalevel.at [127.0.0.1]) by metalevel.at (Postfix) with ESMTP id 505BAEC103; Wed, 21 Oct 2015 01:47:26 +0200 (CEST) Original-Received: by dawn.meta (Postfix, from userid 501) id D14BA16BB25F; Wed, 21 Oct 2015 01:47:22 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Tue, 06 Oct 2015 16:09:44 -0400") 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:107793 Archived-At: Stefan Monnier writes: > But indeed, in the present case it's worse because the comment actually > does contain a complete "sexp", it's just that with infix operators, we > have to find the "previous" in order to decide that we've seen the > end. Another regression, which may also be affected by how the mode currently finds the end of terms, also affects indentation outside comments. When writing Prolog code, situations like the following are common: Suppose I am in the middle of defining a predicate, with point at "HERE": serious_predicate :- goal_1, goal_2, something_complicated, HERE at this point, we decide that we better define something_complicated/0 right now, before even bothering with the rest of the clause at hand. So we leave the current rule unfinished and instead add: serious_predicate :- goal_1, goal_2, something_complicated, something_complicated :-HERE When we now press RET, we get: serious_predicate :- goal_1, goal_2, something_complicated, something_complicated :- HERE That's OK, and Stefan Bruda's mode does that too. But now the point: We now need a way to tell the mode to not bother (for now) with anything prior to the new rule at hand. I.e., we now want to focus on the definition of something_complicated/0, and need a way to tell the mode to not bother with the still incomplete definition of serious_predicate/0. In Stefan Bruda's mode, there is a straight-forward and intuitive way to do this at this point: C-p C-a M-\ C-n TAB which gives us, with Stefan Bruda's original mode: serious_predicate :- goal_1, goal_2, something_complicated, something_complicated :- HERE and we are ready to complete the definition of something_complicated/0. Indentation will work as expected at this point, not taking into account the prior, intentionally still unfinished clause of serious_predicate/0: serious_predicate :- goal_1, goal_2, something_complicated, something_complicated :- goal_3, goal_4. In contrast, we get with the current git version, as a result of the above key sequence in the exact same situation: serious_predicate :- goal_1, goal_2, something_complicated, something_complicated :- HERE which is indenting too far in this specific situation. Moreover, when we now insert the exact same goals, we get: serious_predicate :- goal_1, goal_2, something_complicated, something_complicated :- goal_3, goal_4. >From what I understand, the current git version parses this as if it meant: serious_predicate :- goal_1, goal_2, something_complicated, something_complicated :- goal_3, goal_4. But this is not valid Prolog syntax, because: ?- current_op(X, Y, (:-)). X = 1200, Y = fx ; X = 1200, Y = xfx. This means that any arguments of the infix operator (:-)/2 must be of *smaller precedence* than (:-)/2 itself (i.e., 1200). Therefore, the above program is not syntactically valid, and it should be treated for what it actually is: Two independent rules, with one of them still unfinished, and only the second one mattering for indentation in this situation, which previously also worked exactly this way. If possible, please also take this situation into account. Thank you and all the best, Markus