Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

>     Display show-paren-context-when-offscreen in child frame

This leads to:

In show-paren--context-child-frame-redirect-focus:
paren.el:279:18: Warning: reference to free variable `corfu--frame'

Leftover debugging code?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>>     Display show-paren-context-when-offscreen in child frame
>
> This leads to:
>
> In show-paren--context-child-frame-redirect-focus:
> paren.el:279:18: Warning: reference to free variable `corfu--frame'
>
> Leftover debugging code?

That code was probably copied from Corfu, another package that uses
child frames.

But I gave it a try, and I don't know why the header line, or perhaps an
overlay, can't be used for that job instead: child frames are slow on
some systems, and very slow on the PGTK port.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

>>>     Display show-paren-context-when-offscreen in child frame
>>
>> This leads to:
>>
>> In show-paren--context-child-frame-redirect-focus:
>> paren.el:279:18: Warning: reference to free variable `corfu--frame'
>>
>> Leftover debugging code?
>
> That code was probably copied from Corfu, another package that uses
> child frames.

Indeed, now fixed.

> But I gave it a try, and I don't know why the header line, or perhaps
> an overlay, can't be used for that job instead:

Daniel Martín said that he might want to give a header-line approach a
try.  The problem with that is that the context to be displayed could be
more than a line.

But you are right that an overlay could do the job, too.  I'll give that
a try.

> child frames are slow on some systems, and very slow on the PGTK port.

I'm actually using pgtk on a 7 years old laptop and it doesn't feel
slow.  The reason why I started with the child-frame approach is that
the child-frame can be positioned precisely at the top-left of the
current window.  Since emacs now supports pixel-wise scrolling, it can
happen that only the lower half of the line at `window-start' is
visible which would be bad if an overlay was placed there.  Is there a
way to test if some position is completely visible?

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Arash Esbati]

Tassilo Horn <tsdh@gnu.org> writes:

> But you are right that an overlay could do the job, too.  I'll give that
> a try.

Many thanks for implementing this feature -- I was looking for this for
a long time :-)

In case you need some inspiration for an implementation with overlays,
you can have a look here:

https://with-emacs.com/posts/ui-hacks/show-matching-lines-when-parentheses-go-off-screen/

Best, Arash

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

Hi all,

>> But you are right that an overlay could do the job, too.  I'll give
>> that a try.
>
> Many thanks for implementing this feature -- I was looking for this
> for a long time :-)

Thanks!

> In case you need some inspiration for an implementation with overlays,
> you can have a look here:

Too late, I'm already done. :-)

Here's a patch which implements both showing the context in an overlay
and in the header-line in addition to the already pushed child-frame
approach (just set show-paren-context-when-offscreen to either
'child-frame, 'overlay, or 'header-line for comparison).

In the overlay and header-line cases, I replace newlines in the context
string with spaces so that the context always only takes one line.
(Note to self: probably that should be cut to window-width, too, so that
you don't get continuation lines which would cause the buffer text to
"bounce down and back up again".)

The overlay approach has the problem that the context text isn't
outstanding visually.  With the child-frame approach, one can customize
the child-frame-border face's :background to get a nice and outstanding
look.  Is there a way to make the context text a bit more outstanding?
Since it's a buffer-substring, it's usually font-locked already and that
should be kept, of course.

The header-line approach has the problem that the text "bounces" because
usually there is no header-line, so its toggled on and off again.  But
at least, the context text is immediately distinguishable.

So all in all, I still like the child-frame approach best but have no
problem with offering the other options as well.

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

Tassilo Horn <tsdh@gnu.org> writes:

> Here's a patch

As always, I've forgotten to attach the patch.  So here it is.

> which implements both showing the context in an overlay and in the
> header-line in addition to the already pushed child-frame approach
> (just set show-paren-context-when-offscreen to either 'child-frame,
> 'overlay, or 'header-line for comparison).
>
> In the overlay and header-line cases, I replace newlines in the context
> string with spaces so that the context always only takes one line.
> (Note to self: probably that should be cut to window-width, too, so that
> you don't get continuation lines which would cause the buffer text to
> "bounce down and back up again".)
>
> The overlay approach has the problem that the context text isn't
> outstanding visually.  With the child-frame approach, one can customize
> the child-frame-border face's :background to get a nice and outstanding
> look.  Is there a way to make the context text a bit more outstanding?
> Since it's a buffer-substring, it's usually font-locked already and that
> should be kept, of course.
>
> The header-line approach has the problem that the text "bounces" because
> usually there is no header-line, so its toggled on and off again.  But
> at least, the context text is immediately distinguishable.
>
> So all in all, I still like the child-frame approach best but have no
> problem with offering the other options as well.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Show-show-paren-context-in-overlay-or-header-line.patch --]
[-- Type: text/x-patch, Size: 4332 bytes --]

From e92a8d062cca54152bd816bdf88dad0bade87120 Mon Sep 17 00:00:00 2001
From: Tassilo Horn <tsdh@gnu.org>
Date: Mon, 7 Feb 2022 15:05:14 +0100
Subject: [PATCH] Show show-paren context in overlay or header-line

---
 lisp/paren.el | 66 ++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 60 insertions(+), 6 deletions(-)

diff --git a/lisp/paren.el b/lisp/paren.el
index 6de4364b4f..e0a8d6fc24 100644
--- a/lisp/paren.el
+++ b/lisp/paren.el
@@ -368,6 +368,51 @@ show-paren--show-context-in-child-frame
       (add-hook 'post-command-hook
                 #'show-paren--delete-context-child-frame))))
 
+(defvar-local show-paren--context-overlay nil)
+
+(defun show-paren--delete-context-overlay ()
+  (when show-paren--context-overlay
+    (delete-overlay show-paren--context-overlay)
+    (setq show-paren--context-overlay nil))
+  (remove-hook 'post-command-hook #'show-paren--delete-overlays
+               'local))
+
+(defun show-paren--show-context-in-overlay (text)
+  "Show TEXT in an overlay at the top-left of the current window."
+  ;; FIXME: This works pretty well but the overlay text is not
+  ;; outstanding at all.  It's good that it's the font-locked string
+  ;; but it would be good if we could place a :box or :background face
+  ;; attribute, too.
+  (setq text (replace-regexp-in-string "\n" " " text))
+  (show-paren--delete-context-overlay)
+  (let* ((beg (window-start))
+         (end (save-excursion
+                (goto-char beg)
+                (line-end-position))))
+    (setq show-paren--context-overlay (make-overlay beg end)))
+  (overlay-put show-paren--context-overlay 'display text)
+  (add-hook 'post-command-hook #'show-paren--delete-context-overlay
+            nil 'local))
+
+(defvar-local show-paren--orig-header-line-format nil)
+
+(defun show-paren--restore-orig-header-line-format ()
+  (setq header-line-format show-paren--orig-header-line-format)
+  (remove-hook 'post-command-hook
+               #'show-paren--restore-orig-header-line-format
+               'local))
+
+(defun show-paren--show-context-in-header-line (text)
+  "Show TEXT in the header-line."
+  ;; FIXME: This bounces the buffer one line down which is a bit
+  ;; annoying.  Can we do anything about it?
+  (setq text (replace-regexp-in-string "\n" " " text))
+  (setq show-paren--orig-header-line-format header-line-format)
+  (setq header-line-format text)
+  (add-hook 'post-command-hook
+            #'show-paren--restore-orig-header-line-format
+            nil 'local))
+
 (defun show-paren-function ()
   "Highlight the parentheses until the next input arrives."
   (let ((data (and show-paren-mode (funcall show-paren-data-function))))
@@ -438,12 +483,21 @@ show-paren-function
                 (let ((open-paren-line-string
                        (blink-paren-open-paren-line-string openparen))
                       (message-log-max nil))
-                  (if (and (eq show-paren-context-when-offscreen
-                               'child-frame)
-                           (display-graphic-p))
-                      (show-paren--show-context-in-child-frame
-                       open-paren-line-string)
-                    (minibuffer-message "Matches %s" open-paren-line-string)))))
+                  (cond ((and (eq show-paren-context-when-offscreen
+                                  'child-frame)
+                              (display-graphic-p))
+                         (show-paren--show-context-in-child-frame
+                          open-paren-line-string))
+                        ((eq show-paren-context-when-offscreen
+                             'overlay)
+                         (show-paren--show-context-in-overlay
+                          open-paren-line-string))
+                        ((eq show-paren-context-when-offscreen
+                             'header-line)
+                         (show-paren--show-context-in-header-line
+                          open-paren-line-string))
+                        (show-paren-context-when-offscreen
+                         (minibuffer-message "Matches %s" open-paren-line-string))))))
           ;; Always set the overlay face, since it varies.
           (overlay-put show-paren--overlay 'priority show-paren-priority)
           (overlay-put show-paren--overlay 'face face))))))
-- 
2.35.1

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Arash Esbati]

Tassilo Horn <tsdh@gnu.org> writes:

> Here's a patch which implements both showing the context in an overlay
> and in the header-line in addition to the already pushed child-frame
> approach (just set show-paren-context-when-offscreen to either
> 'child-frame, 'overlay, or 'header-line for comparison).

I didn't try the patch in your other mail, but I presume you know that a
tweak to `show-paren-context-when-offscreen' is missing in order to
allow the new options.

> With the child-frame approach, one can customize the
> child-frame-border face's :background to get a nice and outstanding
> look.

Indeed, the usual customize options are missing, but I think that is
still to come (and I would have asked for it :-)

> So all in all, I still like the child-frame approach best but have no
> problem with offering the other options as well.

I'm using it on Windows and until now, I can't see any slowdowns.

Best, Arash

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

>> Here's a patch which implements both showing the context in an
>> overlay and in the header-line in addition to the already pushed
>> child-frame approach (just set show-paren-context-when-offscreen to
>> either 'child-frame, 'overlay, or 'header-line for comparison).
>
> I didn't try the patch in your other mail, but I presume you know that
> a tweak to `show-paren-context-when-offscreen' is missing in order to
> allow the new options.

Yes, I know.  I'll add the other options if those are to be add.d

>> With the child-frame approach, one can customize the
>> child-frame-border face's :background to get a nice and outstanding
>> look.
>
> Indeed, the usual customize options are missing, but I think that is
> still to come (and I would have asked for it :-)

What do you mean with that?

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

Tassilo Horn <tsdh@gnu.org> writes:

> I'm actually using pgtk on a 7 years old laptop and it doesn't feel
> slow.  The reason why I started with the child-frame approach is that
> the child-frame can be positioned precisely at the top-left of the
> current window.  Since emacs now supports pixel-wise scrolling, it can
> happen that only the lower half of the line at `window-start' is
> visible which would be bad if an overlay was placed there.  Is there a
> way to test if some position is completely visible?

Try `pos-visible-in-window-p'.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

Tassilo Horn <tsdh@gnu.org> writes:

> I'm actually using pgtk on a 7 years old laptop and it doesn't feel
> slow.  The reason why I started with the child-frame approach is that
> the child-frame can be positioned precisely at the top-left of the
> current window.

BTW, I think there are at least two open bug reports about slow child
frames on PGTK, one from after it was merged, and one from before.

I can't find the latter, so someone should find and merge those.
Thanks in advance.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

> BTW, I think there are at least two open bug reports about slow child
> frames on PGTK, one from after it was merged, and one from before.
>
> I can't find the latter, so someone should find and merge those.
> Thanks in advance.

I've tried but only found this one:

  bug#52677: 29.0.50; make-frame-visible/invisible too slow when use --with-pgtk

Anyhow, I think being able to toggle a frame's visibility state on/off
only ten times a second isn't so horrible slow.  Of course, it depends
on use-case.  But for show-paren where there's `show-paren-delay' anyhow
it doesn't really matter from my POV.

FWIW, I don't have posframe installed but tried this benchmark which is
quite similar:

  (benchmark 10
             '(show-paren--show-context-in-child-frame "foobar"))
  ;Elapsed time: 1.178163s (0.047553s in 3 GCs)

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Arash Esbati]

Tassilo Horn <tsdh@gnu.org> writes:

> Arash Esbati <arash@gnu.org> writes:
>
>> Indeed, the usual customize options are missing, but I think that is
>> still to come (and I would have asked for it :-)
>
> What do you mean with that?

I meant that I missed the docstring telling me to customize the
`child-frame-border' face :-[

I think I have found a bug, I will send a report to bug-gnu-emacs.

Best, Arash

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

>>> Indeed, the usual customize options are missing, but I think that is
>>> still to come (and I would have asked for it :-)
>>
>> What do you mean with that?
>
> I meant that I missed the docstring telling me to customize the
> `child-frame-border' face :-[

:-)

> I think I have found a bug, I will send a report to bug-gnu-emacs.

Please Cc me directly if possible.

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[martin rudalics]

 > I've tried but only found this one:
 >
 >    bug#52677: 29.0.50; make-frame-visible/invisible too slow when use --with-pgtk
 >
 > Anyhow, I think being able to toggle a frame's visibility state on/off
 > only ten times a second isn't so horrible slow.

 From my experience, it's usually very hard to get more information from
tumashu so I won't try.  But we'd first of all have to know (1) whether
this slowness happens on Wayland only and (2) whether normal (non-child)
frames are affected too.

 > Of course, it depends
 > on use-case.  But for show-paren where there's `show-paren-delay' anyhow
 > it doesn't really matter from my POV.
 >
 > FWIW, I don't have posframe installed but tried this benchmark which is
 > quite similar:
 >
 >    (benchmark 10
 >               '(show-paren--show-context-in-child-frame "foobar"))
 >    ;Elapsed time: 1.178163s (0.047553s in 3 GCs)

Does that make the child frame invisible in between?  If not, you're
comparing apples and oranges

martin

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

> But we'd first of all have to know (1) whether this slowness happens
> on Wayland only and (2) whether normal (non-child) frames are affected
> too.

On PGTK, child frames don't actually have a window.  They only have a
widget that's attached to the EmacsFixed widget of the parent frame.

Normal frames are not affected by the slowdown, at least on Wayland.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

martin rudalics <rudalics@gmx.at> writes:

>> Of course, it depends on use-case.  But for show-paren where there's
>> `show-paren-delay' anyhow it doesn't really matter from my POV.
>>
>> FWIW, I don't have posframe installed but tried this benchmark which is
>> quite similar:
>>
>>    (benchmark 10
>>               '(show-paren--show-context-in-child-frame "foobar"))
>>    ;Elapsed time: 1.178163s (0.047553s in 3 GCs)
>
> Does that make the child frame invisible in between?  If not, you're
> comparing apples and oranges

It creates the child-frame invisibly, then eventually calls
`make-frame-visible'.

But I can also use this recipe and get pretty much the same times.

  (setq frame (make-frame `((parent-frame . ,(window-frame)))))
  (benchmark 10
             (lambda ()
	       (make-frame-invisible frame)
	       (make-frame-visible frame)))

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

>> I'm actually using pgtk on a 7 years old laptop and it doesn't feel
>> slow.  The reason why I started with the child-frame approach is that
>> the child-frame can be positioned precisely at the top-left of the
>> current window.  Since emacs now supports pixel-wise scrolling, it
>> can happen that only the lower half of the line at `window-start' is
>> visible which would be bad if an overlay was placed there.  Is there
>> a way to test if some position is completely visible?
>
> Try `pos-visible-in-window-p'.

Ah, so if (pos-visible-in-window-p (window-start) nil t) returns a
6-element list, then (window-start) is not completely visible.

My idea was to display the context overlay in the second line in such
cases but I don't think that's worthwhile to bother with.  It seems that
so many basic commands (next-line, previous-line, move-end-of-line) get
me out of this "half line visible state" that it can be neglected.

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Arash Esbati <arash@gnu.org> writes:

> I think I have found a bug, I will send a report to bug-gnu-emacs.

BTW, in the meantime I've pushed the overlay version which is pretty
much the same UI-wise but doesn't hit bug bug#53871.

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

Tassilo Horn <tsdh@gnu.org> writes:

> Arash Esbati <arash@gnu.org> writes:
>
>> I think I have found a bug, I will send a report to bug-gnu-emacs.
>
> BTW, in the meantime I've pushed the overlay version which is pretty
> much the same UI-wise but doesn't hit bug bug#53871.

Another advantage of using an overlay is that it wraps correctly and
doesn't overwrite the scrollbar or a wrapped tool bar on the no-toolkit
build.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

>>> I think I have found a bug, I will send a report to bug-gnu-emacs.
>>
>> BTW, in the meantime I've pushed the overlay version which is pretty
>> much the same UI-wise but doesn't hit bug bug#53871.
>
> Another advantage of using an overlay is that it wraps correctly and
> doesn't overwrite the scrollbar or a wrapped tool bar on the
> no-toolkit build.

Yes, each version has its pros and cons.  The child-frame version has
the benefit of not occupying a complete line if the context string is
shorter.  Another hypothetical benefit is that, in a future
grammar-aware emacs buffer (tree-sitter), the context string could be
tweaked to be "semantically sensible", e.g., with

  if (foobar
      && quux % 2 == 0)
    {
      ...
    }<== point here!

it could show the complete multi-line if+condition rather than only
"&& quux % 2 == 0)...{".

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

Tassilo Horn <tsdh@gnu.org> writes:

> Yes, each version has its pros and cons.  The child-frame version has
> the benefit of not occupying a complete line if the context string is
> shorter.

How could it be shorter than a complete line?

>   if (foobar
>       && quux % 2 == 0)
>     {
>       ...
>     }<== point here!

BTW, if I press C-g while the overlay is displayed, it flickers but
doesn't disappear.

That should probably be fixed.

Thanks.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Po Lu <luangruo@yahoo.com> writes:

>> Yes, each version has its pros and cons.  The child-frame version has
>> the benefit of not occupying a complete line if the context string is
>> shorter.
>
> How could it be shorter than a complete line?

I mean the actual line at window-start is longer than the context
string and so the child-frame's width doesn't cover all of your first
visible line.  Tha happens quite freqently when the open paren starts a
let, a progn, etc.

See attached screenshot.

[-- Attachment #2: Screenshot-2022-02-09_144450.png --]
[-- Type: image/png, Size: 138678 bytes --]

[-- Attachment #3: Type: text/plain, Size: 791 bytes --]


>>   if (foobar
>>       && quux % 2 == 0)
>>     {
>>       ...
>>     }<== point here!
>
> BTW, if I press C-g while the overlay is displayed, it flickers but
> doesn't disappear.

Hm, indeed, but it's the same for child-frame and also for "print in the
echo area".  C-g-ing will also run `post-command-hook' which removes the
frame/overlay or prints Quit, but after `show-paren-delay' the
`show-paren--idle-timer' will trigger `show-paren-function' again
resulting in another overlay/frame/message.

I'm not sure if that can be considered a bug but I can see that one
wants to be able to C-g away the overlay/child-frame, though.  I guess
`show-paren-function' should track the current position of point and not
show context info if that has already been shown previously?

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Arash Esbati]

Tassilo Horn <tsdh@gnu.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>>> I think I have found a bug, I will send a report to bug-gnu-emacs.
>>>
>>> BTW, in the meantime I've pushed the overlay version which is pretty
>>> much the same UI-wise but doesn't hit bug bug#53871.

Thanks Tassilo, I just updated my build and will play with it.

>> Another advantage of using an overlay is that it wraps correctly and
>> doesn't overwrite the scrollbar or a wrapped tool bar on the
>> no-toolkit build.
>
> Yes, each version has its pros and cons.  The child-frame version has
> the benefit of not occupying a complete line if the context string is
> shorter.

I like the child-frame version more, exactly for the reasons mentioned
by Po Lu above (which are not advantages for me): I find it less
distracting when the context is outside the actual code, and overwriting
scroll bar or the tab-line (which I use) for a short period of time
isn't a big deal.  But that's a matter I taste, I think.

Best, Arash

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

>> BTW, if I press C-g while the overlay is displayed, it flickers but
>> doesn't disappear.
>
> Hm, indeed, but it's the same for child-frame and also for "print in
> the echo area".  C-g-ing will also run `post-command-hook' which
> removes the frame/overlay or prints Quit, but after `show-paren-delay'
> the `show-paren--idle-timer' will trigger `show-paren-function' again
> resulting in another overlay/frame/message.
>
> I'm not sure if that can be considered a bug but I can see that one
> wants to be able to C-g away the overlay/child-frame, though.  I guess
> `show-paren-function' should track the current position of point and
> not show context info if that has already been shown previously?

I did that just now and it seems to work fine.  Give it a try.

Bye,
Tassilo

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[martin rudalics]

 > Another advantage of using an overlay is that it wraps correctly and
 > doesn't overwrite the scrollbar or a wrapped tool bar on the no-toolkit
 > build.

You can always put a child frame at exactly the same position as an
overlay, give it the same extent or wrap its text in the same manner.

The same doesn't hold in the opposite direction: You can make a child
frame "overlay" an arbitrary rectangle within the "parent window".  On
many platforms you can make the child frame transparent.  And, using
'window-lines-pixel-dimensions', you can have Emacs find a rectangle
where to put your child frame in a way that doesn't obscure any buffer
text at all.

martin

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

Tassilo Horn <tsdh@gnu.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>>> BTW, if I press C-g while the overlay is displayed, it flickers but
>>> doesn't disappear.
>>
>> Hm, indeed, but it's the same for child-frame and also for "print in
>> the echo area".  C-g-ing will also run `post-command-hook' which
>> removes the frame/overlay or prints Quit, but after `show-paren-delay'
>> the `show-paren--idle-timer' will trigger `show-paren-function' again
>> resulting in another overlay/frame/message.
>>
>> I'm not sure if that can be considered a bug but I can see that one
>> wants to be able to C-g away the overlay/child-frame, though.  I guess
>> `show-paren-function' should track the current position of point and
>> not show context info if that has already been shown previously?
>
> I did that just now and it seems to work fine.  Give it a try.
>
> Bye,
> Tassilo

Thanks, it seems to work nicely.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Po Lu]

Tassilo Horn <tsdh@gnu.org> writes:

> I did that just now and it seems to work fine.  Give it a try.

I found a problem: when I click so that point is moved onto the
parentheses being highlighted, the context overlay flickers and then
disappears.

Any ideas?  Thanks in advance.

Re: master 6e5d79c048: Display show-paren-context-when-offscreen in child frame

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

> I found a problem: when I click so that point is moved onto the
> parentheses being highlighted, the context overlay flickers and then
> disappears.
>
> Any ideas?

Yes, after some poking, it seems that you get the intended behavior when
your mouse click is short, i.e., in that case, the behavior is the same
as if you've moved point to the closing paren with some non-mouse means.

However, when you press and hold the mouse button just a tiny bit
longer, I get the behavior you describe.

I guess the difference here is that in the first case, emacs handles
some "mouse button clicked" event whereas in the second case handles one
"mouse button pressed" and one "mouse button released" event.  "clicked"
and "pressed" seem to set point and will trigger the show-paren context
info but the "released" event then also runs `post-command-hook' which
will remove the context overlay/child-frame again.  And since we've
already shown the context info for the current position of point, we're
not gonna show it again.

I'm not sure how to fix that or even if it deserves a fix.

Bye,
Tassilo