With this patch the editor will highlight (draw a red box aroud) all occurences in the current document of the selected text.
The feature is selectabel/deselectable throught the editor settings dialog.
screenshot attached
patch id: 002525.
[attachment deleted by admin]
I'm not quite happy yet because of two things:
1. it triggers from UpdateUI which means it adds a lot of overhead to typing and even moving the mouse
2. on a second thought, there's only one thing
Other than that: Great! Works nicely. I'll have a look if I find something better to hook it into.
Very nice feature !!
Is it possible to highlight only whole words with same case ?
Dje
very nice. I think once Thomas has found a better cpu relaxing idea, and the case issue is solved this is a very nice addition :-)
Bah... UpdateUI is the official event for selection changes, and there's nothing else. But it's possible to do a quick range test at the beginning, and return without searching through all the text, that should eleminate the overhead almost entirely. Just compiling.
Works fine. No measurable difference between with feature or without when editing and scrolling, and such.
It does eat some CPU while doing the highlighting (around 24-25% on my system, on files 200+ kB), but I guess it's obvious that this isn't free :)
Commit? :)
EDIT:Wait a second,...
Quotewhen the case issue is solved
I think that's an implementation feature, not an issue. But sure, it could be customized. I personally would like to be able to highlight multiple words too, for example.
But... that's only tweaking on details... in principle, it works nicely :)
Quote from: thomas on July 23, 2008, 03:05:39 PM
Commit? :)
It'd be a nice feature addition. I'm going ahead with the commit. :)
Eh, how are you going ahead, if you don't have the code? :P
Quote from: thomas on July 23, 2008, 03:11:00 PM
Eh, how are you going ahead, if you don't have the code? :P
It's in Berlios. ;)
go ahead and commit 8)
Quote from: killerbot on July 23, 2008, 03:22:04 PM
go ahead and commit 8)
Already done and working nice over here... Cool stuff! 8)
I am glad that you like it.
I dont' believe that the patch to reduce CPU consumption works yet!
If you select old_a the highlight occurences feature only marks the compare operation but no assignment to old_a.
With other words: the static variables old_a and old_b have to get assigned the "current" value of a and b which will be "old" in the next run!
regards daniel
You're right, one line got lost on the merge... committing that one. Thanks :)
Hi,
Dje asked to highlight only words with same case.
I use cb for c++ and vhdl development. VHDL is not not case sensitive, c++ is case sensitive.
Would it not be nice to store some info about the language together with the lexer configuration?
Example for c/c++ configuration:
<LanguageAttributes
LineComment="//"
StreamCommentStart="/*"
StreamCommentEnd="*/"
BoxCommentStart="/* "
BoxCommentMid=" * "
BoxCommentEnd=" */"
CaseSensitive="1"/>And define an interface (like the colorset) to get these information during runtime.
(something like Manager::Get()->GetEditorManager()->GetLanguageAttributeSet()->GetCommentToken(lang) )
So we have not to change main.cpp from cb for every new language and the plugins/app can also get these information:
- Occurrence highlighting likes to know if the language is case sensitive or not
- Code Statistics only collects these infos about file comments in its config dialog
- For the todo plugin it should be relatively easy to generate a dynamic line parser (boost::spirit) to find the todos not only in c/c++ files
- Other things we don't know yet.
What do you think?
regards daniel
Hi !
I think it depends more on the user preferences, needs and context than on programming language.
That's why I think there should be check boxes in the editor configuration panel to set behaviour and store the options in default.conf.
I would also add that editors/IDE I used that had this feature used generally whole words and case sensitivity.
Dje
This is a nice feature. I have one very minor (maybe even petty) issue as illustrated by the following sequence:
(1) Select a word -> Occurrences are highlighted
(2) Deselect the word -> Highlights are turned off
(3) Select the same word again - with no intervening selections -> Nothing happens
At step (3) it would seem that the Occurrences should be highlighted again, but to do this you must first select something else and then return to the original word.
Thanks for a nice feature!
Hi
Which revision do you have tested?
regards daniel
Quote from: danselmi on July 25, 2008, 05:34:26 PM
Which revision do you have tested?
SVN 5162 on Windows XP.
I just added a patch to svn that should fix this issue.
For me it only occured if a word was reselected with a double-click.
Quote from: jens on July 25, 2008, 09:37:58 PM
I just added a patch to svn that should fix this issue.
Yep. It works fine. Thanks.
Anyone knows where I can found the source code for this plugin?
This is not a plugin. It is in the main source of C::B
Quote from: oBFusCATed on December 21, 2010, 11:19:54 AM
This is not a plugin. It is in the main source of C::B
But it was a plugin sometime (long time) ago, isn't it? Because I have a plugin version... :-p
Anyway, thx!
Sorry, my bad, I am looking for the "Occurence HighlightER" plugin from danselmi, which make highlights permanent for selected words...
I have no public repository for this small plugin. Sources are attached.
Quote from: danselmi on December 21, 2010, 12:55:14 PM
I have no public repository for this small plugin. Sources are attached.
Thank you very much... I find it really useful !!!!
I'm sneaking what the "competition" does and I've found one feature which could be really useful.
See the video: http://www.youtube.com/watch?feature=player_embedded&v=fndDT2GK-KU
The feature they've added is keyboard shortcuts for going to the next/prev occurrence of the highlighted text.
How hard would it be for this to be implemented?
I'm afraid that finding references is a lot more complicated than finding syntax-agnostic substrings. Though it would be immensely cool (especially since non-patched occurrence highlighting doesn't do 1-character and 2-character selections, such as variable names like i, or pt, or it).
What would be even more helpful would be a feature to select all references, rather than highlighting them. Code::Blocks already supports non-standard selections and typing into all of them simultaneously. Now, for intuitive, quick-and-failsafe renaming, all one needs is "select all references".
Quote from: thomas on November 13, 2012, 03:58:21 PMCode::Blocks already supports non-standard selections and typing into all of them simultaneously.
I didn't know about this, where is this option? I have been looking around in menus and context menus, but I can't make multiple selections (let alone typing in multiple places).
Quote from: carra on November 13, 2012, 04:12:32 PM
Quote from: thomas on November 13, 2012, 03:58:21 PMCode::Blocks already supports non-standard selections and typing into all of them simultaneously.
I didn't know about this, where is this option? I have been looking around in menus and context menus, but I can't make multiple selections (let alone typing in multiple places).
Look into "Settings -> Editor... -> Margins and caret -> Selections" .
Interesting :)
However, I see that sometimes it can get very difficult to see what you have selected, precisely because of the highlight of occurrences.
See this as an example:
int main()
{
// try to select these Foos:
if( SomeBool ) Foo( 1 );
else Foo( 2 );
// but not this one:
return Foo( 0 );
}
The selection color should get painted over the highlights, and not under it. As it is now, I can't see which ocurrences I have selected and which ones not. Another option could be to mix colors or use some transparency.
(http://imageshack.us/scaled/landing/831/cb2p.png)
Don't undstand your problem. The first one is highlighted, the other two are highligted and selected. Typing will replace into the lower two.
Quote from: thomas on November 13, 2012, 03:58:21 PM
(especially since non-patched occurrence highlighting doesn't do 1-character and 2-character selections, such as variable names like i, or pt, or it).
Thomas, this is possible if you use the "Incremental Search" plugin. Just enable the IS Toolbar from the menu, then enter even single character "words" into the search field and press "highlight". I find this really useful very often.
Ok, I'll try to post a screenshot when I get home so that you see what I mean.
I also think the highlighting and selection is confusing... see screenshot: I just double-clicked on the the first "cb_unused", but it's hard to tell which one is really selected...
[attachment deleted by admin]
Thanks daniloz, you saved me the work :) I think in that screenshot the first one is selected and the rest aren't, but one has to really focus to see it...
And by the way, the problem also happens for single selection. It is just less of a problem (it is easy to remember what you selected if it's only one thing ;) )
Quote from: MortenMacFly on November 13, 2012, 05:42:33 PM
Quote from: thomas on November 13, 2012, 03:58:21 PM
(especially since non-patched occurrence highlighting doesn't do 1-character and 2-character selections, such as variable names like i, or pt, or it).
Thomas, this is possible if you use the "Incremental Search" plugin. Just enable the IS Toolbar from the menu, then enter even single character "words" into the search field and press "highlight". I find this really useful very often.
I've just patched the code to
if(selection.Length() > 0) (therefore me referring to "unpatched"), which always works nicely, and doesn't ignore whitespace (used to trim whitespace, but it's even better without). Whitespace helps finding for example all occurrences of
i without highlighting the one in
while. Unluckily, it doesn't work nearly as well for
for(Blah::iterator it = blah.begin; ...) f(*it); because it won't find the
*it --- this is why finding (syntax aware)
references would be so interesting.
Try and rename a single-letter variable (say,
i) in a function that has more than 5 lines. It's a nightmare, and actually you should better stay away from it alltogether. When you are doing that kind of thing for a shadow warning, you spend 15-20 minutes on those 5 lines just to be sure you've not forgotten one, as that would modify the wrong variable in the wrong scope. And even then you feel bad about it afterwards. What's worst, the compiler won't even be able to warn you when it happens...
(Lesson to learn: don't use single-letter variables if you can help it. At least not in non-trivial code with several nested blocks.)
Quote from: thomas on November 13, 2012, 05:57:53 PMTry and rename a single-letter variable (say, i) in a function that has more than 5 lines.
Technically its possible: Scintilla offers multiple selections (not necessarily bound together) an also writing to multiple selections. CC could offer the interface to local variables, bringing both together allows what you want.
I find I get by pretty well with "match case + whole word" or regexp replaces. Something more interactive might be nice, but it might also be a lot of work for small result. Slightly offtopic, but, IMO, it would also be useful to be able to perform operations on the items in the find in files results list.
Quote from: dmoore on November 13, 2012, 08:40:57 PM
I find I get by pretty well with "match case + whole word" or regexp replaces. Something more interactive might be nice, but it might also be a lot of work for small result.
I have to disagree with you here. I do agree that from a developer perspective
"match case + whole word" or regexp replaces is just fine and the work for implementing something more interactive is not worth...
However, IMHO, from a
typical user perspective, I think that would be a very nice feature because:
1- the user maybe is not acquainted with regexp
2- the user may feel more safe if there's something interactive to do the replaces, i.e. he may fell that he's not missing something
I'm fine with the actual
"match case + whole word" or regexp replaces, but wanted to leave my 2 cents here....
Replace with "match regex" is not very usable. First, I've often seen it fail when it should work, especially when the regex contains properly escaped special characters such as ( or * or \ (incidentially this seems to work right now that I've mentioned it, but I've seen it fail with expressions that were 100% correct before), and second, merely having to bring up the dialog and writing the expression is a lot of work, which makes it less competitive.
Selecting a variable is a matter of holding down shift and pressing the arrow key (possibly 3-4 times), or doing a double-click with the mouse.