search

nschum / highlight-symbol.el

Emacs: automatic and manual symbol highlighting
http://nschum.de/src/emacs/highlight-symbol/
274 stars 41 forks source link

Highlight symbol marks are not visible? #35

Closed ReneFroger closed 9 years ago

ReneFroger commented 9 years ago

Thanks for sharing this package! However, after reorganizing my dot-emacs and upgrading highlight-symbol, highlight-symbol is not working anymore. I'm not sure what caused this.

For example

 foo
 bar
 foo
 bar

The cursor is on the first foo. Then I call highlight-symbol, I see in the minibuffer the message: 2 occurences in the buffer. But they don't get any visible marking. When I checked the face group, I see they have different colors than my colorscheme. And highlight-symbol-mode is enabled. Any idea in order to debug this?

waymondo commented 9 years ago

I'm also experiencing this. If i revert https://github.com/nschum/highlight-symbol.el/commit/6bd53abd72fd473290afaff023ea7f8592aa0b5a I see the highlight-symbol-face decoration once again.

mrkkrp commented 9 years ago

Yes, this doesn't work anymore... @tarsius, any idea why?

ReneFroger commented 9 years ago

@nschum, mabye it's a option to revert the commits?

nschum commented 9 years ago

What version of Emacs are all of you using?

mrkkrp commented 9 years ago

@nschum, Emacs trunk.

ReneFroger commented 9 years ago

@nschum GNU Emacs 25.0.50.1 (x86_64-w64-mingw32) of 2015-07-25 on KAEL.

tarsius commented 9 years ago

Related functions from v25.0.50 suffer from the same issue, so there is a bug in Emacs. But I still have to figure out whether the bug is that font-lock-ensure does not actually ensure that font-lock is up-to-date (which is what I assumed it would do), or whether that is intentional and we have to call redisplay ourselves after font-lock-ensure. (In which case my patch has a bug, but highlight-regexp and friends would have the same bug.)

tarsius commented 9 years ago

(In which case my patch has a bug, but highlight-regexp and friends would have the same bug.)

Hm, actually no that's not the case. So that's where I will have to look.

mrkkrp commented 9 years ago

As I understand something has been done recently again. Now it's extremely buggy. You can highlight something, but you cannot remove highlights via highlight-symbol-remove-all or via highlight-symbol when the point is on highlighted symbol. It seems to slow down Emacs now. Some occurrences are highlighted and some of them not. I don't know if my setup is somehow so unique that I'm alone experiencing these issues... Please revert these 2 last commits, so it's usable again.

nschum commented 9 years ago

@mrkkrp If I throw everything away that's unfinished, we wouldn't get anything new done. :) The goal is to get things fixed, even if it takes some time. If you need something reliable, please use released versions, not the work in progress.

@tarsius Looking at the Emacs source, it looks like font-lock-ensure just ensures that the initial fontification has happened (at least once). font-lock-flush looks like right function:

Declare the region BEG...END's fontification as out-of-date.

mrkkrp commented 9 years ago

@nschum, Well, this package is in MELPA, and many people expect things to work. You can create separate branch and do development there until it's usable. Then you can merge it with master.

nschum commented 9 years ago

What? MELPA just fetches master? That's crazy!

mrkkrp commented 9 years ago

MELPA stable uses tags, MELPA just fetches master. Every commit results in update of your package there:

https://github.com/milkypostman/melpa/blob/master/recipes/highlight-symbol

tarsius commented 9 years ago

@mrkkrp I am sorry that I have caused this breakage, but...

If you need something reliable, please use released versions, not the work in progress.

Well, this package is in MELPA, and many people expect things to work.

Their expectation is wrong. Melpa features development versions and sometimes things break during development. Sure there is not really a good alternative to Melpa right now, because too many packages are not featured on Melpa-Stable because to few maintainers tag releases. But it would be better to change that (you can do your part by bringing this to the attention of the maintainers of the packages you are using) than to tell us not to do any development on the development branch.

What? MELPA just fetches master? That's crazy!

Not really. Breakage happens but not that often actually. The problem is users who expect development snapshots to be as stable as releases.

mrkkrp commented 9 years ago

@tarsius, things do break when you're using bleeding edge version of package, this is normal, no complaints. Anyway, using of a separate branch is a good idea. I've just come here to tell that something is getting worse. I think this sort of feedback is a good thing too.

tarsius commented 9 years ago

I've just come here to tell that something is getting worse. I think this sort of feedback is a good thing too.

Yes, of course.

things do break when you're using bleeding edge version of package, this is normal, no complaints.

Ah, I thought you did.

For more complex risky things it's a good idea to use a feature branch. But for little "risk free" changes master is fine. Unfortunately it sometimes turns out that those risk free changes actually do break something :)

Only pushing to master shortly before a release (and using next or something for development) often isn't a good option. Melpa is supposed to contain the latest development (sans yet-to-be merged dedicated feature branches). In the past I have moved development to a branch different from the one the Melpa packages are built from, with the result that users asked me to not do that because they did want the bleeding edge version (which is only fair since that is what one is supposed to get from Melpa). (Never-the-less, I am actually considering to do this again for Magit, but also move to a much shorter release cycle at the same time.)

ReneFroger commented 9 years ago

I assume this issue is fixed now?

tarsius commented 9 years ago

I just pulled and for me it works, yes.

ReneFroger commented 9 years ago

No, not in my case. Higlight-symbol worked fine all the time, before the update broke things. I let highlight-symbol work together with expand-region, with Evil mode as minor mode. So it's setup as following:

(defun Ernst/Exit-highlight-symbol()
    (interactive)
    (highlight-symbol 0)
    )

(defun Ernst/Expand-region-and-highlight ()
    (interactive)
    (er/expand-region 1)
    (highlight-symbol-mode 1)
    )

I bounded these functions to the following keybindings:

(define-key evil-visual-state-map (kbd "v") 'Ernst/Expand-region-and-highlight)   
(add-hook 'evil-visual-state-exit-hook 'Ernst/Exit-highlight-symbol)

These functions toggle the highlight-symbol when the expand-region visually select a word with the v. Then I see automatically if there are other same symbols in the buffer.

After I updated the highlight-symbol package, everything is broken. The latest changes highlights the symbols again, but I still have a visual region after exiting the visual state, which comes from highlight-symbol.

So one thing may be fixed, the symbols are highlighted now, but the behavior is still broken.

ReneFroger commented 9 years ago

Nevermind. I just noticed I need to change the (highlight-symbol 0) to (highlight-symbol-mode 0).

Sorry for bothering everyone here. All the support is really appreciated. And @tarsius Jonas, I really like your support and maintaining the Magit package and the collection of orphaned packages and mirrored packages. It's awesome!

nschum commented 9 years ago

@mrkkrp Of course, feedback is very much appreciated. :) And you didn't do anything wrong. Reverting commits just shouldn't be the way to ensure the majority of users have working packages. (Especially when the package authors don't even know about it. :wink:)

I've opened an issue on melpa. Maybe more people see things that way. We'll see. Any further comments regarding that topic should go there.