bug#10275: speedbar highlights first selected item in speedbar-highlight-face

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[Juanma Barranquero]

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

Package: emacs
Severity: minor

emacs -Q -f speedbar
;; then select any source file in speedbar, click to unfold it, and
click over any variable or function.

What happens:
- The file is highlighted in the Speedbar frame, with `speedbar-highlight-face'.
- The file is loaded into a buffer and displayed in a window.
- The selected variable or function is shown, and also highlighted
with `speedbar-highlight-face'.

Clicking into another subitem (or even the same one) of the same file
does not bring back the highlighting. But clicking it into another
file's subitem does. It happens every time a new file is selected,
even if previously selected.

I'm not sure this is a bug, because the behavior already happens in
22.1, but certainly is unexpected, and the docstring of
`speedbar-highlight-face' talks only about buttons, not the source
file.

[-- Attachment #2: bug.png --]
[-- Type: image/png, Size: 131872 bytes --]

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[martin rudalics]

 > emacs -Q -f speedbar
 > ;; then select any source file in speedbar, click to unfold it, and
 > click over any variable or function.
 >
 > What happens:
 > - The file is highlighted in the Speedbar frame, with `speedbar-highlight-face'.
 > - The file is loaded into a buffer and displayed in a window.
 > - The selected variable or function is shown, and also highlighted
 > with `speedbar-highlight-face'.
 >
 > Clicking into another subitem (or even the same one) of the same file
 > does not bring back the highlighting. But clicking it into another
 > file's subitem does. It happens every time a new file is selected,
 > even if previously selected.
 >
 > I'm not sure this is a bug, because the behavior already happens in
 > 22.1, but certainly is unexpected, and the docstring of
 > `speedbar-highlight-face' talks only about buttons, not the source
 > file.

What happens is that after the mouse click speedbar does highlight the
line via `speedbar-highlight-one-tag-line' which installs in
`pre-command-hook' the function `speedbar-unhighlight-one-tag-line'.
Next comes a switch-frame event to select the frame of the buffer where
the highlight is and executing the corresponding `handle-switch-frame'
command triggers the `pre-command-hook' which swallows the highlight
immediately.

An easy work-around is

(defun speedbar-unhighlight-one-tag-line ()
   "Unhighlight the currently highlighted line."
   (when (and speedbar-highlight-one-tag-line
	     (not (eq this-command 'handle-switch-frame)))
     (speedbar-delete-overlay speedbar-highlight-one-tag-line)
     (setq speedbar-highlight-one-tag-line nil)
     (remove-hook 'pre-command-hook 'speedbar-unhighlight-one-tag-line)))

but I have no idea what Eric intended to accomplish in the first place
and delving into the code of speedbar or dframe is no fun at all.

martin

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[Juanma Barranquero]

On Wed, Dec 14, 2011 at 18:23, martin rudalics <rudalics@gmx.at> wrote:

> What happens is that after the mouse click speedbar does highlight the
> line via `speedbar-highlight-one-tag-line' which installs in
> `pre-command-hook' the function `speedbar-unhighlight-one-tag-line'.
> Next comes a switch-frame event to select the frame of the buffer where
> the highlight is and executing the corresponding `handle-switch-frame'
> command triggers the `pre-command-hook' which swallows the highlight
> immediately.

IOW, the bug is in removing the highlight when selecting subsequent items.

> but I have no idea what Eric intended to accomplish in the first place

I'm Cc:ing him.

Thanks,

    Juanma

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[martin rudalics]

 > IOW, the bug is in removing the highlight when selecting subsequent items.

Not really.  FWIW the bug happens because `handle-switch-frame' runs
`pre-command-hook', something Eric probably didn't expect.  Switching
the frame is needed because the mouse click selects the speedbar frame
and we immediately want to return to the frame where the source file is
shown.  But I don't understand why de-highlighting doesn't occur when
hitting RET in the speedbar or switching to another buffer with the
mouse.

martin

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[Eric M. Ludlam]

On 12/14/2011 01:20 PM, martin rudalics wrote:
>  > IOW, the bug is in removing the highlight when selecting subsequent
> items.
>
> Not really. FWIW the bug happens because `handle-switch-frame' runs
> `pre-command-hook', something Eric probably didn't expect. Switching
> the frame is needed because the mouse click selects the speedbar frame
> and we immediately want to return to the frame where the source file is
> shown. But I don't understand why de-highlighting doesn't occur when
> hitting RET in the speedbar or switching to another buffer with the
> mouse.

I wrote that bit of code a long time ago.  The idea is to just show the 
line of interest in an easy to identify way, but have the highlight go 
away on the next keypress.

It seems like all the frame switching running the hook is defeating the 
mechanism it was using.

It could be that in speedbar-tag-find just swapping the last two lines 
is sufficient to move the post-command-hook execution to the right time.

Such a patch should be sent to the Emacs maintainers, as I haven't been 
maintaining speedbar directly lately.

Eric

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[Juanma Barranquero]

On Thu, Dec 15, 2011 at 00:06, Eric M. Ludlam <ericludlam@gmail.com> wrote:

> I wrote that bit of code a long time ago.  The idea is to just show the line
> of interest in an easy to identify way, but have the highlight go away on
> the next keypress.

Aha. I was a bit confused because the highlighting is done with
speedbar-highlight-face, but the face's docstring does not suggest
that.

> It seems like all the frame switching running the hook is defeating the
> mechanism it was using.

So it seems, yes.

> Such a patch should be sent to the Emacs maintainers, as I haven't been
> maintaining speedbar directly lately.

OK. Thanks for your help.

    Juanma

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[Martin Rudalics]

> It could be that in speedbar-tag-find just swapping the last two lines
> is sufficient to move the post-command-hook execution to the right time.

Doesn't work here.

martin

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

bug#10275: speedbar highlights first selected item in speedbar-highlight-face

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> An easy work-around is
>
> (defun speedbar-unhighlight-one-tag-line ()
>   "Unhighlight the currently highlighted line."
>   (when (and speedbar-highlight-one-tag-line
> 	     (not (eq this-command 'handle-switch-frame)))
>     (speedbar-delete-overlay speedbar-highlight-one-tag-line)
>     (setq speedbar-highlight-one-tag-line nil)
>     (remove-hook 'pre-command-hook 'speedbar-unhighlight-one-tag-line)))

Since no one else has proposed anything better, I've committed this into
trunk for you.