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

[Alan Mackenzie]

Hello, Stefan.

On Thu, Oct 16, 2014 at 01:40:22PM -0400, Stefan Monnier wrote:
> > I've been trying this out the past few days, and it seems having a
> > closing paren at EOL shown when point is in LH periphery is quite useful.

> I think for

>   (defun foo
>   <1>  blabla
>   <2>  blilbi)
>   <3>

> I'd prefer we highlight the matching parens when we're at <3> than when
> we're at <2>.  Would that be "about as useful", you think?

More complicated to implement.  Up to now, the "here" paren is always on
the same line as point.  I personally would find it less useful if point
at <2> didn't trigger the paren at EOL.  My main use case is in long
rambling defuns (such as are common in CC Mode), being able to match
parens which are far apart, e.g. 60 lines apart, just by C-n'ing and
C-p'ing in the left periphery.  If this wasn't triggered for an isolated
line which _had_ a ) or (, this would be irritating.

> Otherwise it seems way too weird/ad-hoc to hardcode it, so make
> it dependent on a config var.

I think that our marginal utility will drop off very sharply, the more
complicated our configurability becomes.

> Another option is to highlight the "nearest surrounding parens", in
> which case we'd highlight the parens above both in cases <1> and <2>
> (plus various others), but this is probably too intrusive.

I don't think I'd like this, but haven't tried it.

> > What is still there is an open paren direcly left of point flashing just
> > after you've typed it (e.g. with M-:).  This irritates somewhat, and
> > maybe this should come out, too.

> Let's keep it for now.

OK.

> >> And of course, it gets you an ambiguity for
> >> (defun foo ()
> >> (bar))
> >> ^
> >> |
> >> point
> > The nearest eligible paren to point currently takes priority.

> Define "nearest".  Can the user mentally compute this "nearest" as well
> (e.g. does it depend on "invisible" trailing whitespace, or does it
> depend on "invisible" differences between spaces and tabs)?

Since point is on the same line as the paren, and is in the WS at either
BOL or EOL, and the (at most) two eligible parameters are on the edge of
the "core", point can't be between the two candidates.  The nearest one
is clear, surely.

If we extend the functionality along the lines you suggested a bit
earlier, "nearest" becomes less clear.

> I think giving precedence always in the same direction (when there are
> separating spaces on both sides) is a simpler choice for the user.

> > As I said above, currently I've got that for point in RH periphery, but
> > not LH periphery.

> OK (tho please make it conditional on some config variable: doesn't have
> to be a defcustom for now, and you can use whichever default you like).

Whoops, sorry, this got left out when I committed.

[ ... ]

> > A question: show-paren--default returns a list containe here-beg,
> > here-end, there-beg, and there-end, four positions.  Couldn't we just
> > return two of these t?here-beg (renamed just to t?here), saving a bit of
> > messing around, or are there circumstances where here-end might not be
> > (1+ here-beg)?

> show-paren--default will never return something else, but other
> functions can, such as SMIE's when matching paired keywords like "begin
> ... end".

OK, that's a very good answer.  :-)

[ ... ]

> > +  "If non-nil, show parens when point is in the line's periphery.
> > +The periphery is at the beginning or end of a line or in any
> > +whitespace there."
> > +  :type 'boolean
> > +  :group 'paren-showing
> > +  :version "25.1")

> ":group 'paren-showing" is redundant.

Hmm.  The :prefix keyword for `defgroup' is not mentioned in the doc
string for `defcustom' (which is where `defgroup' points you for details
of keywords).  I haven't checked the elisp manual, though.  This seems
like a little bug.

I've removed all the instances of :group.

> Add a ":type 'boolean".

Done.

> Functions that end in "-p" should only return a boolean (i.e. the return
> value doesn't have to be "t or nil" but the non-nil value should have no
> other meaning than being non-nil and the callers shouldn't rely on it
> being anything in particular other than "non-nil").

> I know we sadly don't always follow this principle (e.g. `framep'), but
> let's try not to make things worse.

By incorporating the pertinent function into s-p--categorize-paren, the
issue has resolved itself.

> > +     ;; Point is immediately inside a paren.
> > +     ((show-paren--unescaped-p before))
> > +     ((show-paren--unescaped-p after))

> This should be controlled by a config var since it's new behavior.
> AFAIK we can (re)use show-paren-when-point-in-periphery just fine.

I invented a fresh defconfig for that.

> BTW, maybe the "unescaped" check could be folded into
> show-paren--categorize-paren.

Done.  (More precisely, a function to do the check is called directly
from s-p--categorize-p).

> > -Where HERE-BEG..HERE-END is expected to be around point.")
> > +Where HERE-BEG..HERE-END is expected to be around the paren.")

> I think "near point" is closer to the original intention than "around
> the paren", especially since it might not be a parenthesis.  Also since
> we shouldn't expect it to be around point, the additional patch below is
> probably needed.

"near point" it is.  I've put in the change below.  This is presumably
needed for when point is inside a keyword like "begin" when the smie-mode
function is in use.

> Other than that, feel free to install it,

Done.

I'll start reworking the page "Matching" of programs.texi.  It looks like
the page could be becoming uncomfortably big.  Some of paren.el's config
variables will need documenting, but not all of them, some of them being
somewhat arcane (e.g. the 0.125s delay).

>         Stefan


> === modified file 'lisp/paren.el'
> --- lisp/paren.el     2014-02-10 01:34:22 +0000
> +++ lisp/paren.el     2014-10-16 17:36:28 +0000
> @@ -216,6 +216,7 @@
>          (if (or (not here-beg)
>                  (and (not show-paren-highlight-openparen)
>                       (> here-end (point))
> +                     (<= here-beg (point))
>                       (integerp there-beg)))
>              (delete-overlay show-paren--overlay-1)
>            (move-overlay show-paren--overlay-1

-- 
Alan Mackenzie (Nuremberg, Germany).