From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Proposed extension of show-paren-mode: Highlight parens when point is in L or R margin. Date: Wed, 15 Oct 2014 22:43:21 -0400 Message-ID: References: <20141011134312.GA4148@acm.acm> <20141012100416.GC3148@acm.acm> <20141015091208.GA3093@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413427447 11932 80.91.229.3 (16 Oct 2014 02:44:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2014 02:44:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 16 04:44:00 2014 Return-path: Envelope-to: ged-emacs-devel@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 1Xeb2k-0006Nz-Cr for ged-emacs-devel@m.gmane.org; Thu, 16 Oct 2014 04:43:58 +0200 Original-Received: from localhost ([::1]:47728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xeb2k-0002cY-1B for ged-emacs-devel@m.gmane.org; Wed, 15 Oct 2014 22:43:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xeb2P-0002cD-EL for emacs-devel@gnu.org; Wed, 15 Oct 2014 22:43:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xeb2A-0002TU-OK for emacs-devel@gnu.org; Wed, 15 Oct 2014 22:43:37 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:36985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xeb2A-0002Sz-L5 for emacs-devel@gnu.org; Wed, 15 Oct 2014 22:43:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFxKjo/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kModSCNIZF456B4Q4BKkZgWqBcYFbIQ X-IPAS-Result: ArUGAIDvNVNFxKjo/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kModSCNIZF456B4Q4BKkZgWqBcYFbIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="94313179" Original-Received: from 69-196-168-232.dsl.teksavvy.com (HELO pastel.home) ([69.196.168.232]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Oct 2014 22:43:22 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C6E9F7CFF; Wed, 15 Oct 2014 22:43:21 -0400 (EDT) In-Reply-To: <20141015091208.GA3093@acm.acm> (Alan Mackenzie's message of "Wed, 15 Oct 2014 09:12:09 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175438 Archived-At: > foo = /* */ bar; /* comment */ > PPPPPPPPPPPP PPPPPPPPPPPPPP > CCCCCCCCCCCCCCCC I don't understand why you'd want to consider the inside of the /* comment */ as part of the periphery. This increases ambiguity/complexity of the behavior since there might be parentheses inside the comment (and then there's the case of nested comments). [ > OK. I've just reconfigured my bzr to use unified. It seems that unified > has "won" over context over the last decade. Previously, context was the > Emacs project standard. Richard is a "context" guy, that's why. I occasionally switch to context style for complex diffs where the interleaving of unified makes the code unreadable, but in most cases I find unified to be easier to read. ] >> > + (eol-pos (save-excursion (end-of-line) >> > + (let ((s (syntax-ppss))) >> > + (if (nth 4 s) >> > + (goto-char (max (nth 8 s) >> > + (point-min)))) >> I don't think we need this `max' thingy. > I think we do, but it should be (line-beginning-position), not > (point-min). In that cases, indeed it's needed. For point-min it shouldn't be (since (goto-char -10) will happily move to point-min). >> This would make it clear that the behavior is unchanged when >> show-paren-when-point-in-periphery is nil, and also makes it clear what >> is the effect of setting show-paren-when-point-in-periphery to non-nil. > That's neat. But it wouldn't be quite the same. It would be a quite > restricted version of what I'm proposing: e.g. point in the LH periphery > wouldn't then trigger a paren at "end of core", I don't understand which case you're referring to. Can you give an example of such a "point in the LH periphery; paren at end of core"? > nor even a close paren at "beginning of core" (which happens a little > in lisp, a lot in C). So you also want to highlight the matching opening paren in the case } ? If so, I guess we should also do it in cases such as: foo(blabla); > Incidentally, I think `show-paren-highlight-openparen', which is a defvar > really ought to be a customisable variable. That's probably a leftover/oversight from before defcustom existed. > Maybe `show-paren-data-function' should be, too. Why? It was introduced for the benefit of smie.el, so it's typically set buffer-locally by major-modes, which makes it a poor fit for a defcustom. Stefan