Hi Eran,
I would be very happy if you could revert this change in rev. 4397:
. When 'Display C++ scope' option is enabled, the scope is now placed at the 'line' header - because of this behavior, there could be multiple entries for the same file (each with different scope)
The output was much more compact before with the scope just placed before the match. With the new layout, I can't see enough results.
Of course this is only my opinion. But I was much more happy with the layout before. If reverting is no option, maybe you could add an option to select the layout (user choose the old or the new layout).
Thanks a lot.
Rev. 4397
-
- CodeLite Veteran
- Posts: 63
- Joined: Mon Apr 06, 2009 10:43 am
- Contact:
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
-
- CodeLite Veteran
- Posts: 63
- Joined: Mon Apr 06, 2009 10:43 am
- Contact:
Re: Rev. 4397
Hi Eran,
the layout of the results in rev. 4398 is ok for me. However, I find it diffcult to distinguish the colors now between the scope (ligth grey) and the match (black) - up to rev. 4396 it was much easier to tell the one from the other. Is there a way to make the color coding for scope/line number/ match user defined?
2 more issues while we are at this topic:
- is the "." (dot) in front of the line number for the matches within C++ comments needed?
- Could you add an option to show only one output line if multiple matches are within one line? So instead of
a)
Line x: [Scope] [startgreen]match[endgreen] = My_match; // match comment
Line x: [Scope] match = My_[startgreen]match[endgreen]; // match comment
[startCommentColor].Line x: [Scope] match = My_match; // [startgreen]match[endgreen] comment[endCommentColor]
have the output like this:
b)
Line x: [Scope] [startgreen]match[endgreen] = My_[startgreen]match[endgreen]; [startCommentColor]// [startgreen]match[endgreen] comment[endCommentColor]
For "Find Replace Candidates" of course, a) should be used.
Thanks.
the layout of the results in rev. 4398 is ok for me. However, I find it diffcult to distinguish the colors now between the scope (ligth grey) and the match (black) - up to rev. 4396 it was much easier to tell the one from the other. Is there a way to make the color coding for scope/line number/ match user defined?
2 more issues while we are at this topic:
- is the "." (dot) in front of the line number for the matches within C++ comments needed?
- Could you add an option to show only one output line if multiple matches are within one line? So instead of
a)
Line x: [Scope] [startgreen]match[endgreen] = My_match; // match comment
Line x: [Scope] match = My_[startgreen]match[endgreen]; // match comment
[startCommentColor].Line x: [Scope] match = My_match; // [startgreen]match[endgreen] comment[endCommentColor]
have the output like this:
b)
Line x: [Scope] [startgreen]match[endgreen] = My_[startgreen]match[endgreen]; [startCommentColor]// [startgreen]match[endgreen] comment[endCommentColor]
For "Find Replace Candidates" of course, a) should be used.
Thanks.
-
- CodeLite Veteran
- Posts: 63
- Joined: Mon Apr 06, 2009 10:43 am
- Contact:
Re: Rev. 4397
Hi Eran,
one more issue:
If "Use different colour for matches found in comments" is enabled, "File mask" is "*.*" and I have a match in an Assembler File -> CL will crash. If the option is off, search output is as expected. Win 7 with rev. 4398.
one more issue:
If "Use different colour for matches found in comments" is enabled, "File mask" is "*.*" and I have a match in an Assembler File -> CL will crash. If the option is off, search output is as expected. Win 7 with rev. 4398.
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Rev. 4397
Yes, otherwise the scintilla lexer used for the 'Find In Files' (simple lexer I wrote) can not tell the difference, scintilla coloring is based on content and can not accept 'external' inputDSP_Programmer wrote:s the "." (dot) in front of the line number for the matches within C++ comments needed?
I am aware of this issue, this is an old one and is not a regression. However, I wonder: so if I change the the behavior to the one you described (multiple matches inside a single line) - where is the user supposed to click when a match is found? exactly on matched string? I found the current behavior much more easier since you can click anywhere on the lineDSP_Programmer wrote:- Could you add an option to show only one output line if multiple matches are within one line? So instead of
a)
Line x: [Scope] [startgreen]match[endgreen] = My_match; // match comment
Line x: [Scope] match = My_[startgreen]match[endgreen]; // match comment
[startCommentColor].Line x: [Scope] match = My_match; // [startgreen]match[endgreen] comment[endCommentColor]
have the output like this:
b)
Line x: [Scope] [startgreen]match[endgreen] = My_[startgreen]match[endgreen]; [startCommentColor]// [startgreen]match[endgreen] comment[endCommentColor]
This sounds interesting, can you provide a sample assembler file? and what string to search?DSP_Programmer wrote:If "Use different colour for matches found in comments" is enabled, "File mask" is "*.*" and I have a match in an Assembler File -> CL will crash. If the option is off, search output is as expected. Win 7 with rev. 4398.
Make sure you have read the HOW TO POST thread
-
- CodeLite Veteran
- Posts: 63
- Joined: Mon Apr 06, 2009 10:43 am
- Contact:
Re: Rev. 4397
What about this (don't know about the implementation effort):eranif wrote: I am aware of this issue, this is an old one and is not a regression. However, I wonder: so if I change the the behavior to the one you described (multiple matches inside a single line) - where is the user supposed to click when a match is found? exactly on matched string? I found the current behavior much more easier since you can click anywhere on the line
a) if the user clicks on a matched string within the result window - go to this string
b) if the user clicks anywhere else on the line within the result window - go the the beginning of this line
Personally, I don't need a), b) would be enough.
I tried, but if I move the file or project where this happens to a different workspace then it works fine. I will have a look at this and try to isolate if possible.eranif wrote: This sounds interesting, can you provide a sample assembler file? and what string to search?