all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <20141016095326.GC3421@acm.acm> (raw)
In-Reply-To: <jwvk340wxye.fsf-monnier+emacs@gnu.org>

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

>    <point>   }

Yes.

> ?  If so, I guess we should also do it in cases such as:

>    foo(blabla<point>);

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).



  reply	other threads:[~2014-10-16  9:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-11 13:43 Proposed extension of show-paren-mode: Highlight parens when point is in L or R margin Alan Mackenzie
2014-10-11 14:21 ` Eli Zaretskii
2014-10-12  8:39   ` Alan Mackenzie
2014-10-12  8:55     ` David Kastrup
2014-10-12  9:25       ` Alan Mackenzie
2014-10-12  9:01     ` Eli Zaretskii
2014-10-12 10:18       ` Alan Mackenzie
2014-10-12  4:12 ` Stefan Monnier
2014-10-12 10:04   ` Alan Mackenzie
2014-10-14 17:49     ` Stefan Monnier
2014-10-14 18:32       ` John Yates
2014-10-15  9:12       ` Alan Mackenzie
2014-10-15 22:38         ` Andy Moreton
2014-10-16  2:43         ` Stefan Monnier
2014-10-16  9:53           ` Alan Mackenzie [this message]
2014-10-16 12:59             ` Stefan Monnier
2014-10-16 13:31               ` Alan Mackenzie
2014-10-16 14:37                 ` Stefan Monnier
2014-10-16 15:46                   ` Alan Mackenzie
2014-10-16 17:40                     ` Stefan Monnier
2014-10-16 21:26                       ` Alan Mackenzie
2014-10-17  0:14                         ` Stefan Monnier
2014-10-14 21:50 ` João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141016095326.GC3421@acm.acm \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.