Closed xvadim closed 9 years ago
If this patch were merged, users would think that
g:cursorword_blacklist
Accepting this patch will bother me how to realize these increasing number of desires and would make me regret merging.
I'm not saying that I dislike the idea of excluding some specific words (that users can switch based on the filetype). Can you suggest any better way?
Unfortunately, I can't suggest any other way. For your first question we can answer, that user can use any global blacklist and extend by it the local one:
let b:cursorword_blacklist = [...] extend(b:cursorword_blacklist, g:cursorword_blacklist)
But for the other your questions I don't have answers.
I'm sorry but I close this issue. I'll consider implementing this feature when I get another feature request.
@itchyny would it be an option to create a configuation for a minimum number of characters a word must have to trigger the highlight? By this many simple sequences can be ignored, which sucks so far. Most of the time variable/function/... names have longer names (cause they should be meaningful) and I guess this is the main demand for most people. Per default it could leave to be zero, so it behaves as now.
@weilbith I'm not sure, in statistical manner, minimum length option is useful for most people or not, but I will not use it because I'd like the looping indices be matched as well. I think I'm very conservative for adding an option to this plugin, in order to keep the performance, I will not implement an option that I don't use. But this plugin is open sourced. Feel free to create your fork.
Showing matching parentheses can be done by Vim itself or what do u mean?
Anyway. I already forked it and implement this feature by myself. To be honest I just wanted to make sure if a PR could be accepted or not.
In fact this feature does save more performance than it costs. Cause it have to call the match for highlighting less and the procedure can be quit earlier. And this is quite often (depending on the configured number). The simple if statement for the words length shouldn't be an issue in any case. It's static and are translated to ~2 CPU instructions.
But I'm just arguing. I accept ur answer that this plugin is in first place for urself. 👍
@itchyny would u mind if I call my fork vim-cursorword-extended
? I would point out where are the differences and that people which don't mind my extra features (min word length, blacklist per filetype, ..?) should tend to us urs. Of cause I will keep performance in mind for my implementations.
@weilbith Okay, go a head.
The simple if statement for the words length shouldn't be an issue in any case. It's static and are translated to ~2 CPU instructions.
If so I would happy accepting any patches. Maybe you can look into eval.c to see how Vim script is executed. It has no internal byte code instruction and parses the script all the way even in loops...
Puh. It's exhaustive to search in the Vim code base.
In the end it looks like I should use strlen
instead of len
, cause it's directly converted to C's strlen
. The rest of my single line is the if request with less than a variable bound to this script. I stopped reading this unlimited mass of code. In the end the statement of 2 instructions was hyperbolic. Cause this should also work for NeoVim I think a correct research is not the effort worth. In the end its the experience of the user, if his application is quite slow or if the resource usage increase.
But it was a nice idea. I think I learned something by that. Or at least I should. ^^
First of all, thanks for this nice plugin. In general I agree with your opinion about heavy configurability. But I think the black list options will be very useful because I don't want to underline, for example, program language's keywords. That's why I've written this request.