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

[Stefan Monnier]

> How about the following model:

>             foo = /* */ bar; /* comment */
> PPPPPPPPPPPP                              P
>             CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

> ?

Sounds fine, yes.  

               foo = /* */ bar; /* comment */
   PPPPPPPPPPPP                P             P
               CCCCCCCCCCCCCCCC CCCCCCCCCCCCC

would be OK as well, I think.

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

Ah, so now your periphery extends to the next line.  That means you get
an ambiguity for

  (defun foo ()
    (do one thing)
    (do another)
  ^
  |
  point

where both the close paren on the previous line and the open paren on
the same line could be chosen.

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

OK, sounds good.  There have already been requests for that kind of feature.

> But this whole idea was meant just to be a simple extension.

It's actually simpler to make it apply "everywhere" than only in a few
particular cases.

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

To tell you the truth, I didn't like much the last show-paren--default
you showed me.  I think this new feature should be
"completely" external and mostly keep the old code untouched.


        Stefan