Re: Proposed extension of show-paren-mode: Highlight parens when point is in L or R margin.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>             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

   <point>   }

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

   foo(blabla<point>);

> 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