Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only highlighting in comments #42

Closed
seagle0128 opened this issue May 7, 2019 · 4 comments
Closed

Only highlighting in comments #42

seagle0128 opened this issue May 7, 2019 · 4 comments

Comments

@seagle0128
Copy link

Hi, hl-todo is very useful and I love it. I have some ideas and requests here.

  1. In prog-mode, the keywords are just in comments usually. So is it possible to just highlight keywords in comments, while not strings and codes? That's annoying.
  2. It seems hl-todo uses font-lock. Maybe overlay is a better solution? like symol-overlay.
@tarsius
Copy link
Owner

tarsius commented May 7, 2019

  1. While working on a feature branch, I often have doc-strings like "TODO". That's useful.

    But I have tried to do what you are suggesting before but without success. I have just tried again and think I now why it didn't work properly; it was a special case of the bug fixed with cdc2266.

    Please give the face-limit branch a try. I could also use some help thinking of a better option name and doc-string.

  2. Why? There has to be a very compelling reason for me to rip out the core of this package and replace it with a new implementation and then deal with the regressions.

    Regarding symbol-overlay: While I use symbol-overlay I considered its use of overlay to be a mistake for a long time, though wolray/symbol-overlay@ccf7913 fixed the issue I was having.

@seagle0128
Copy link
Author

  1. It does make sense. Some people like add "TODO" in doc-strings. Ad option is a good idea here.
  2. font-lock is slow for the large files. overlay has better performance?

@tarsius
Copy link
Owner

tarsius commented May 8, 2019

font-lock is slow for the large files. overlay has better performance?

We already do #29 for performance reasons. I don't think abandoning font-lock completely and hoping for the best would do much good.

@seagle0128
Copy link
Author

I am fine if the performance issue was addressed. I am closing it. Thanks!

tarsius added a commit that referenced this issue Dec 12, 2019
This was in response to #42.
I probably won't merge this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants