From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.bugs Subject: bug#5410: Parenthesis Matching Bug!! Date: Wed, 10 Aug 2016 23:57:36 -0400 Message-ID: References: <1263817237.2894.15.camel@matrix-laptop> <871t25fdkb.fsf@web.de> <87shukuryr.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1470887901 13015 195.159.176.226 (11 Aug 2016 03:58:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 11 Aug 2016 03:58:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) Cc: 5410@debbugs.gnu.org, Matrix To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 11 05:58:17 2016 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 1bXh8K-0003AR-9K for geb-bug-gnu-emacs@m.gmane.org; Thu, 11 Aug 2016 05:58:16 +0200 Original-Received: from localhost ([::1]:45312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXh8G-00013g-DC for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Aug 2016 23:58:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXh8A-0000zT-Ld for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2016 23:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXh86-00045w-Cc for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2016 23:58:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXh86-00045o-8J for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2016 23:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bXh85-0008FT-SE for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2016 23:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrew Hyatt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Aug 2016 03:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5410-submit@debbugs.gnu.org id=B5410.147088786731667 (code B ref 5410); Thu, 11 Aug 2016 03:58:01 +0000 Original-Received: (at 5410) by debbugs.gnu.org; 11 Aug 2016 03:57:47 +0000 Original-Received: from localhost ([127.0.0.1]:52817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bXh7r-0008Eh-MG for submit@debbugs.gnu.org; Wed, 10 Aug 2016 23:57:47 -0400 Original-Received: from mail-qk0-f173.google.com ([209.85.220.173]:32810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bXh7q-0008EU-5M for 5410@debbugs.gnu.org; Wed, 10 Aug 2016 23:57:46 -0400 Original-Received: by mail-qk0-f173.google.com with SMTP id t7so63548826qkh.0 for <5410@debbugs.gnu.org>; Wed, 10 Aug 2016 20:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=ZJQ7ukzUdpHIpZHX14FwYLr/Bn4KTsdgsNLrJRIr2bk=; b=bAsvdfuP3M17p7btdPs+byHRVRTpJiaMdeUmsOEILI57vS8IUxo+siDACY8uiSNeYn qf2ctN9liZkb4GUyFYziTjLADFzY5lCmmIsdkP8zetCIc/AeFtYlKS/DvgZ2tO/GH2zA KxFwf81nYv59ufo+YfhHqjK7xyAgxyZU/jDGNKSSzK28OA42vUDgueabOd2bwseuyW9R ePqCR5TDzV45wj6TIpfFzYSaYLcVbiJyBuGyeN919b4eRthGQ4mDKMBMf9AFUQceDyUU EZYux38LBwkNsycSuw4ioazNRrvmLa4XwSzjON0KPW848wFhxSzowF2cD/Eph2tZxyA8 uaNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=ZJQ7ukzUdpHIpZHX14FwYLr/Bn4KTsdgsNLrJRIr2bk=; b=MjGZweO3IXxbpe/mzN3f7T2ekuWvqx4lNirHnKrpbJJsfsi5R/OGbBWKr4BqzfkIyp NeyHM8yIZY1/a94OI7BJYtKX8Av2SpOBPsHKqUByxqmRSgA3lJdwPmn8pFXu/Q8H70th SYo+sA//Wz+n5JD71NjApwlygZ9pr6HRJY7PhwzueucSCzJWP8CWfGszwZybeiTJtohq +r44KCMqZUhqeTLMC3oPT2r0TsVLSfD2Mfyr4tumTsgEVkC4sOdcU06rkkDIWPAshv5U x0p22RI/k/lhiV5osswoy3BoSPqOO8Ut4SVZDuOW4Xnku1FXWWjaZ81FbltO8aDfpyo/ i2XQ== X-Gm-Message-State: AEkoouvbOudPRDacvpJA0Ly8zc23PIF+1TqxW44yit8uaxyrHU3nmwJ7vRYVpF2neySZwA== X-Received: by 10.55.155.140 with SMTP id d134mr8840963qke.145.1470887860594; Wed, 10 Aug 2016 20:57:40 -0700 (PDT) Original-Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id u44sm421695qtc.27.2016.08.10.20.57.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Aug 2016 20:57:37 -0700 (PDT) In-Reply-To: <87shukuryr.fsf@web.de> (Michael Heerdegen's message of "Thu, 04 Aug 2016 23:47:24 +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:122054 Archived-At: Michael Heerdegen writes: > Andrew Hyatt writes: > >> It'd be nice, I guess, if you could just turn it to nil when in a >> comment. > > Yes, I think we could bind `parse-sexp-ignore-comments' to nil around > the calls to `scan-sexps' in `show-paren--default' when point is inside > a comment. But I must admit that I don't understand the terse doc of > `parse-sexp-ignore-comments': > > | Non-nil means `forward-sexp', etc., should treat comments as > | whitespace. > > But what does nil mean, exactly? It seems that comments are then > treated as if they were indistinguishable from code. When I set > `parse-sexp-ignore-comments' to nil in emacs-lisp-mode, and have such a > file: > > ;; ( > ) > > then show-paren-mode indicates the parens as matching, though one is > inside in a comment, and the other is not. `scan-sexps' behaves > accordingly. That would mean we would need to assure that the matching > paren position that `scan-sexps' has found is still inside the current > comment. Interesting point. The more I hear, the more this sounds like a wishlist item - we just don't seem to have a way to treat paren matching in comments separately yet with multiline capabilities. I'm going to mark it as wishlist for now. > > > Michael.