From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#33301: 27.0.50; broken elisp indentation for non-definition symbols starting with "def.." Date: Fri, 09 Nov 2018 00:41:53 +0000 Message-ID: <87a7mjqdym.fsf@gmail.com> References: <87zhukh1ri.fsf@gmail.com> <87tvksv21u.fsf@web.de> <87efbvrj4c.fsf@gmail.com> <8736sbumzj.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1541724072 5910 195.159.176.226 (9 Nov 2018 00:41:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Nov 2018 00:41:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33301@debbugs.gnu.org, Noam Postavsky To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 09 01:41:07 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 1gKurC-0001NQ-O9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Nov 2018 01:41:06 +0100 Original-Received: from localhost ([::1]:59658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKutJ-0001uR-3m for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Nov 2018 19:43:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKutC-0001ir-5H for bug-gnu-emacs@gnu.org; Thu, 08 Nov 2018 19:43:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKut6-0001oe-84 for bug-gnu-emacs@gnu.org; Thu, 08 Nov 2018 19:43:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37783) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gKut4-0001mg-8k for bug-gnu-emacs@gnu.org; Thu, 08 Nov 2018 19:43:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gKut4-0007Jv-3w for bug-gnu-emacs@gnu.org; Thu, 08 Nov 2018 19:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Nov 2018 00:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33301 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 33301-submit@debbugs.gnu.org id=B33301.154172412628075 (code B ref 33301); Fri, 09 Nov 2018 00:43:02 +0000 Original-Received: (at 33301) by debbugs.gnu.org; 9 Nov 2018 00:42:06 +0000 Original-Received: from localhost ([127.0.0.1]:42041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gKusA-0007Il-GQ for submit@debbugs.gnu.org; Thu, 08 Nov 2018 19:42:06 -0500 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:46339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gKus8-0007IG-H5 for 33301@debbugs.gnu.org; Thu, 08 Nov 2018 19:42:04 -0500 Original-Received: by mail-wr1-f47.google.com with SMTP id 74-v6so107566wrb.13 for <33301@debbugs.gnu.org>; Thu, 08 Nov 2018 16:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=8lAtZ31TdZi+ZLvCYLc3ufS+98v22j/dDkfQzeKWrb0=; b=FLe9fFs1Yz5FQzydqg2ScMNeJXFQB3dOd2UTCYZ65t1rXiRgmQUmgNtrQAseE/MSSE UVkCQMOV7iso7O5TLTHK7xf9Pyuc/8JLui7Bt/zNBnICl2n3yjrjloQ4asfDmZ3IuSWG Pt04m5YJ5O7lrZSISCS6hvy8ozr8d0wQ1R1P7GX2Y9qMd/YacE5eDsTCV+VVC/woztzr kK3z6h5KzZJs9ymvbe/tqS1eKSw2kO6S5qkna/42tyG+3HXwVR3eq6XV0Q3f/Xe1pFLy ipUp9E7NbJvxtBRKLvGSdoQfLRH3ktIPKZEVQ9172n3g/t94s0FX8qJBpdow8jDe7V3Y duZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=8lAtZ31TdZi+ZLvCYLc3ufS+98v22j/dDkfQzeKWrb0=; b=UGWDiLV45wWM2vItcbNYkE55xoXN4XxXa4rFHVOK5lt5pEC1KIhrV7FCXYil+aIAbN gH9g6OmLHZpvpXaNH6bIAqhOZ/mchD/Ie28VVH0PWEXTTyb+SZqMpiWylb7oUFhY5zXb /l2jpA8zZE5wG3vlDf8z/CvsDFb7EwdM/fFvv1SG2maj/pQtFpOD0Rs0mr+uifxuvXTP PuEkLjGAXewnvYOfNoWNKTJeoFOsddqAvV9VexrdohwUOlCxm6eEOjEQnu2vPLWtFcfc tzLl7NIhmZQ3Zw0aVlorw78YO8puKZijm1zSNbeYSn3mfTF3YgC4B3jfhzGCPIjW/J6/ 6ztg== X-Gm-Message-State: AGRZ1gIwQ4uNAHKn4TXOxsUVgrPeLK9hqzAA8qMDm243Xe+youqvzt56 hG3aKDm8eZgWLYEL+ojSvbqJjIEK X-Google-Smtp-Source: AJdET5dvGXE+8NOOECwY9sWTu1I736OBeEGG7heH/ucsuRDP3peuBNQ5XnEaZvFCkwSijwKoGydNIQ== X-Received: by 2002:adf:f589:: with SMTP id f9-v6mr6142549wro.281.1541724118296; Thu, 08 Nov 2018 16:41:58 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id r198-v6sm403336wmg.0.2018.11.08.16.41.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Nov 2018 16:41:57 -0800 (PST) In-Reply-To: <8736sbumzj.fsf@web.de> (Michael Heerdegen's message of "Fri, 09 Nov 2018 01:13:20 +0100") 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:152188 Archived-At: Michael Heerdegen writes: > Jo=C3=A3o T=C3=A1vora writes: > >> Ah, that's unfortunate. Still, coundn't we improve the heuristic by >> asking if the "function" has a macro definition? Isn't that closer to >> the intended behaviour? >> >> diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el >> index afb7cbd1dd..e7373ece85 100644 >> --- a/lisp/emacs-lisp/lisp-mode.el >> +++ b/lisp/emacs-lisp/lisp-mode.el >> @@ -1104,7 +1104,8 @@ lisp-indent-function >> (cond ((or (eq method 'defun) >> (and (null method) >> (> (length function) 3) >> - (string-match "\\`def" function))) >> + (string-match "\\`def" function) >> + (macrop (intern function)))) >> (lisp-indent-defform state indent-point)) >> ((integerp method) >> (lisp-indent-specform method state > > If that macro is defined, shouldn't it already be indented correctly > without heuristics? I don't think so, not without an explicit indent declaration spec in the macro definition. This may explain the string-match hack in the first place. I don't know the exact motivation of the hack, but it's been there since the initial 2001 revision of the file. Possibly before declare/indent existed? If you're suggesting removing it entirely, I don't oppose it. There's the downside that indentation relying on it would start to fail, but diffs normally spot that and this would encourage users to add proper indent (and edebug) specs to their macros. Otherwise, I think my macrop tweak does a slightly better job at avoiding false positives. Jo=C3=A3o