From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Proposed extension of show-paren-mode: Highlight parens when point is in L or R margin. Date: Thu, 16 Oct 2014 09:53:26 +0000 Message-ID: <20141016095326.GC3421@acm.acm> 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; charset=us-ascii X-Trace: ger.gmane.org 1413453591 26661 80.91.229.3 (16 Oct 2014 09:59:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2014 09:59:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 16 11:59:41 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 1XehqO-0000en-Cv for ged-emacs-devel@m.gmane.org; Thu, 16 Oct 2014 11:59:40 +0200 Original-Received: from localhost ([::1]:49509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XehqO-0006NJ-2D for ged-emacs-devel@m.gmane.org; Thu, 16 Oct 2014 05:59:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xehq1-0006MD-8n for emacs-devel@gnu.org; Thu, 16 Oct 2014 05:59:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xehpt-0002Su-PN for emacs-devel@gnu.org; Thu, 16 Oct 2014 05:59:17 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:27887 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xehpt-0002S8-F3 for emacs-devel@gnu.org; Thu, 16 Oct 2014 05:59:09 -0400 Original-Received: (qmail 72399 invoked by uid 3782); 16 Oct 2014 09:59:07 -0000 Original-Received: from acm.muc.de (pD9518029.dip0.t-ipconnect.de [217.81.128.41]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 16 Oct 2014 11:59:06 +0200 Original-Received: (qmail 3693 invoked by uid 1000); 16 Oct 2014 09:53:26 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 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:175449 Archived-At: Hello, Stefan. On Wed, Oct 15, 2014 at 10:43:21PM -0400, Stefan Monnier wrote: > > 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). The parens inside the comment would still get shown as they do currently. I think my thinking was that some paren pair near point should be shown "most of the time", but this would get annoying when point is inside the core. But yes, I've not taken nested comments into account. Maybe it would be better just to count whitespace (not comments) as being in the periphery. If handling for nested comments were added, things would be beginning to get out of hand. How about the following model: foo = /* */ bar; /* comment */ PPPPPPPPPPPP P CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC ? [ ... ] > >> 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"? (defface show-paren-mismatch '((((class color)) (:foreground "white" :background "purple")) (t (:inverse-video t))) "Face used for a mismatching paren." :group 'paren-showing-faces) <-------- paren ^ | point > > 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 > } Yes. > ? If so, I guess we should also do it in cases such as: > foo(blabla); Hmmm. Maybe. But this whole idea was meant just to be a simple extension. > > 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. I'll make it a defcustom, then. > > 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. OK. So, to sum up, I'll remove comments from the definition of "periphery", and make that variable a defcustom. I don't think you need to see another amended patch. > Stefan -- Alan Mackenzie (Nuremberg, Germany).