Odd behavior when highlight-symbol-prev/next bound to keys

[bstiles]

If I bind highlight-symbol-next/prev to keys (C-c . and C-c ,), then jumping via these keystrokes can break in certain situations whereas jumping via M-x highlight-symbol-next/prev will not. I don't have all the necessary conditions identified, but I've at least identified that highlight-symbol-mode-post-command affects the problem.

This issues started for me as of upgrading to 24.3.1. The behavior did not seem to change between highlight-symbol 1.1 and 1.2.

I have created a video showing the behavior in hopes that that is the easiest way to communicate. It is linked here (if the format doesn't work for you, let me know what format will work, and I'll try to re-encode it):

https://s3.amazonaws.com/www.bstiles.net/highlight-symbol-issue.mp4

The sequence demonstrating the problem is roughly as follows:

1. Put the point on a symbol.
2. C-c , to highlight-symbol-prev.
3. C-c . to highlight-symbol-next.

At this point, we should have jumped back to the original location, but instead the window does not scroll back to the original position, and we see two cursors --- one flashing at a seemingly arbitrary position at the top of the window and the other not flashing at the symbol location we are trying to jump away from.

If I disable the first condition in highlight-symbol-mode-post-command and retry the steps above, things work as expected. Similarly, if I wrap the calls to highlight-symbol-prev/next in an interactive function that calls keyboard-quit right after highlight-symbol-prev/next, I don't experience the stuck cursor.

Please let me know if there is any further information you need. I can help debug the issue if you can give me some tips what might be going on in the highlight-symbol-mode-post-command function. I don't know your code very well, but I can probably figure it out.

Thanks!

[bstiles]

There may be some sort of a timing issue here. I have modified highlight-symbol-mode-post-command never to enter the first branch as a workaround, and sometimes when jumping via keybindings, I'll see the cursor jump to the top of the window briefly as in the error case shown in the video, but it only remains there for a split second before jumping to the expected location.

[nschum]

So far, I'm not able to reproduce the problem with Emacs 24.3.1 (on Mac OS 10.8.3).

Which values have you set the highlight-symbol-* variables to? Is highlight-symbol-mode enabled? Can you reproduce it when starting Emacs with -Q?

[bstiles]

Customizations: '(highlight-symbol-idle-delay 0.5) '(highlight-symbol-on-navigation-p t) '(highlight-symbol-face ((((class color) (background dark)) (:background "#992000"))))

highlight-symbol-mode is enabled

I can't reproduce it if I start with a plain Text buffer and enable highlight-symbol-mode.

There are some other inconsistencies I've noticed:

The problem may not occur on the first try.

The problem doesn't seem to occur if the symbol jumping doesn't cause the window to scroll.

[bstiles]

Here are the enabled minor modes in the buffer used in the video: Auto-Composition Auto-Compression Auto-Encryption Blink-Cursor Column-Number Diff-Auto-Refine Fci File-Name-Shadow Font-Lock Global-Font-Lock Global-Hl-Line Highlight-80+ Highlight-Symbol Hl-Sexp Line-Number Menu-Bar Mouse-Wheel Paredit Shell-Dirtrack Show-Paren Tool-Bar Tooltip Transient-Mark

[nschum]

Sounds like a conflict with another package's post-command-hook. Could you try to find a minimal configuration that triggers the problem?

[bstiles]

Sure.

[bstiles]

Disabling just fci-mode from my standard configuration causes the problem to go away.

[nschum]

Sorry, still no luck reproducing it, even with fci-mode enabled.

[bstiles]

I've worked with fci-mode disabled quite a bit since my last message, and highlight-symbol has been working just fine. I also noticed that as of 24.3.1, fci-mode causes some funky behavior showing the cursor in column 2 when point is in column one, in certain circumstances. So, it sure looks like the problem is there, not in highlight-symbol.

I appreciate you taking a look at this.

As an aside, I just tried highlight-symbol 1.2 when investigating this, and ran into an issue (feature request for you, really) with hl-sexp. Using faces to highlight the symbol means that overlays used by hl-sexp cover the background contributed by the face. I had forgotten about this, but I had long ago overwritten hi-lock-set-pattern to use overlays instead of faces so that symbol highlighting worked within the highlighted sexp. I'm not sure when I'll have time, but I'll probably try at some point to implement overlays on 1.2 and submit a patch if you think overlays would be worthwhile (and if my solution is reasonable).

Thanks for the library. Symbol highlighting and jumping next/previous has been tremendously useful to me.

[nschum]

Ok, closing this then for the time being.

Could you open an issue for your request. I'll take a look at it when I have the time. I think it might work without a rewrite.