Author Topic: #if 0 commenting  (Read 40211 times)

schmave

  • Community Member
  • Posts: 8
  • Hero Points: 0
#if 0 commenting
« on: July 20, 2006, 03:09:51 PM »
Is there a way to get SlickEdit to highlight #if 0/#endif blocks in C/C++ as comments?

mlcomment doesn't seem to support spaces in a comment delimiter...

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: #if 0 commenting
« Reply #1 on: July 21, 2006, 06:09:50 AM »
I afraid that multiline comments doesn't support that. I also asked for that time ago.
I think color coding doesn't make use of the reg-exp engine due to performance reasons.
But nevertheless at least #if 0 support would be absolutly great.
@SlickTeam: Is there a chance for that ?
HS2

jbezem

  • Community Member
  • Posts: 87
  • Hero Points: 8
Re: #if 0 commenting
« Reply #2 on: July 21, 2006, 08:05:56 AM »
Make that a request for '#if<configurable setting>' since I tend to use '#ifdef COMMENTED_OUT' for better readability...

But only if I have three wishes free, I really can live without it ;-)

Johan

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: #if 0 commenting
« Reply #3 on: July 21, 2006, 08:59:45 AM »
Well, I assumed that the color coder uses fixed tokens.
Therefore I asked for the fixed '#if 0'.
In addition it's always clearly defined and may not interfere with pre-processing ...
Maybe I re-issue this goodie-request, but I can live w/o it too.
HS2

Dennis

  • Senior Community Member
  • Posts: 3954
  • Hero Points: 515
Re: #if 0 commenting
« Reply #4 on: July 21, 2006, 12:48:47 PM »
This is a common request, and, trust me, we have researched it.
Allow me to elaborate on some of the issues:

1) #else and #if 1 ... #else ...:  How should these be colored?  Example:

   1  #if 0
   2  H1
   3  #else
   4  H2
   5  #endif

   Should just line 2 be colored as a comment?  Or lines 1,2,and 3?  Or just lines 1 and 2?

2) The slippery slope.  If we forced color coding to special case #if 0,
    then within two days, someone would invariably ask us to support:

    #ifdef NOT_DEFINED
    ...
    #endif

3) The sledgehammer:  Treating a #if 0 block like a comment is something of a sledgehammer.
    SlickEdit's most powerful features like tagging and smart paste, get really dumb if they
    think you are in plain text (that is, within a comment).  The right solution is requires a
    more powerful mechanism to highlight the inactive region without losing it's color properties.

The alternative:  The current solution is to use selective display of preprocessing to
hide all your inactive #if regions.   View > Selective Display..., Preprocessing.

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: #if 0 commenting
« Reply #5 on: July 21, 2006, 01:13:03 PM »
Oh yes - you are right.
I was aware of 2) but even 1) is non-trivial to decide.
Fiinally 3) shows, that I would loose more power than getting a real benefit.
I should use the selective display more often. It's much more powerful than every other 'code-folding' support I've seen.
Thanks - HS2

Ding Zhaojie

  • Senior Community Member
  • Posts: 194
  • Hero Points: 37
Re: #if 0 commenting
« Reply #6 on: July 21, 2006, 04:48:48 PM »
This is a common request, and, trust me, we have researched it.
Allow me to elaborate on some of the issues:

1) #else and #if 1 ... #else ...:  How should these be colored?  Example:

   1  #if 0
   2  H1
   3  #else
   4  H2
   5  #endif

   Should just line 2 be colored as a comment?  Or lines 1,2,and 3?  Or just lines 1 and 2?

2) The slippery slope.  If we forced color coding to special case #if 0,
    then within two days, someone would invariably ask us to support:

    #ifdef NOT_DEFINED
    ...
    #endif

3) The sledgehammer:  Treating a #if 0 block like a comment is something of a sledgehammer.
    SlickEdit's most powerful features like tagging and smart paste, get really dumb if they
    think you are in plain text (that is, within a comment).  The right solution is requires a
    more powerful mechanism to highlight the inactive region without losing it's color properties.

The alternative:  The current solution is to use selective display of preprocessing to
hide all your inactive #if regions.   View > Selective Display..., Preprocessing.

I think you could implement a simple way just like the SourceInsight does (see the screenshots below):
If you can make sure a code block will not be compiled, highlight it as comments or sth. If not, just do nothing.
We often use "#if 0" or "#if 1 #else" to disable or switch code blocks while debugging. Trust me no one likes to use selective display when he was busy in debugging or fixing codes (it seems the selective display can not fold new codes automatically while typing). But to highlight the "#if 0" code blocks will make us easy to find which codes have been disabled and reduce mistakes.

Or, just provide a checkbox to let the user decide to turn this feature on/off. I think many people like it.
« Last Edit: July 21, 2006, 04:54:14 PM by Ding Zhaojie »

jszakmeister

  • Community Member
  • Posts: 12
  • Hero Points: 3
Re: #if 0 commenting
« Reply #7 on: February 01, 2007, 10:04:45 AM »
This is a common request, and, trust me, we have researched it.
Allow me to elaborate on some of the issues:

1) #else and #if 1 ... #else ...:  How should these be colored?  Example:

   1  #if 0
   2  H1
   3  #else
   4  H2
   5  #endif

   Should just line 2 be colored as a comment?  Or lines 1,2,and 3?  Or just lines 1 and 2?

Line 2.


2) The slippery slope.  If we forced color coding to special case #if 0,
    then within two days, someone would invariably ask us to support:

    #ifdef NOT_DEFINED
    ...
    #endif

I think that "#if 0" is common enough that 2 shouldn't even be a consideration for holding back implementing this feature.  Every other programming editor out there colors the block as a comment.  And, I for one, find it very helpful.


3) The sledgehammer:  Treating a #if 0 block like a comment is something of a sledgehammer.
    SlickEdit's most powerful features like tagging and smart paste, get really dumb if they
    think you are in plain text (that is, within a comment).  The right solution is requires a
    more powerful mechanism to highlight the inactive region without losing it's color properties.

FWIW, I don't mind if SE treats what's in between as plain text.  The use-case (at least at our place) is to comment out a large block of code while trying to debug an issue.  Because some the tools are old, we have to use C89 style comments, making #if 0 the only way to reliably comment out a code block.  And no, I can't use a different compiler.


The alternative:  The current solution is to use selective display of preprocessing to
hide all your inactive #if regions.   View > Selective Display..., Preprocessing.


Ew!  :)  If there was a way to do that easily via a shortcut, I'd consider it.

-John
« Last Edit: February 01, 2007, 10:11:33 AM by jszakmeister »

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: #if 0 commenting
« Reply #8 on: February 01, 2007, 11:01:47 AM »
You could try this ...
Code: [Select]
_command void  toggle_hide_if0( ) name_info (','VSARG2_READ_ONLY|VSARG2_REQUIRES_EDITORCTL)
{
   typeless p;
   if ( p_NofSelDispBitmaps > 0 )
   {
      _save_pos2( p )
      show_all ();
      _restore_pos2( p );
   }
   else
   {
      _save_pos2( p )
      hide_block_regions("#if 0", "#endif", "P");
      _restore_pos2( p );
   }
}

Have fun,

HS2

Wanderer

  • Senior Community Member
  • Posts: 557
  • Hero Points: 23
Re: #if 0 commenting
« Reply #9 on: February 01, 2007, 12:21:25 PM »
You could try this ...
Code: [Select]
  // snip

Have fun,

HS2

And that could be generalized:
Code: [Select]
_command void  toggle_hide_ifdef_DEBUG( ) name_info (','VSARG2_READ_ONLY|VSARG2_REQUIRES_EDITORCTL)
{
   toggle_hide_pound_if_block("#ifdef _DEBUG");
}

_command void toggle_hide_pound_if_block(_str firstToken="#if 0") name_info (','VSARG2_READ_ONLY|VSARG2_REQUIRES_EDITORCTL)
{
   typeless p;
   if ( p_NofSelDispBitmaps > 0 )
   {
      _save_pos2( p )
      show_all ();
      _restore_pos2( p );
   }
   else
   {
      _save_pos2( p )
      hide_block_regions(firstToken, "#endif", "P");
      _restore_pos2( p );
   }
}

Since I don't do much with macros, someone could probaby correct the errors I've made in my generalized implementation...

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: #if 0 commenting
« Reply #10 on: February 01, 2007, 12:44:01 PM »
Cool Wanderer !

So finally we get:
Code: [Select]
_command void  toggle_hide_ifdef_DEBUG( ) name_info (','VSARG2_READ_ONLY|VSARG2_REQUIRES_EDITORCTL)
{
   toggle_hide_pound_if_block("#ifdef _DEBUG");
}

_command void toggle_hide_pound_if_block(_str firstToken="#if 0") name_info (','VSARG2_READ_ONLY|VSARG2_REQUIRES_EDITORCTL)
{
   typeless p;
    _save_pos2( p )

   if ( p_NofSelDispBitmaps > 0 )
      show_all ();
   else
      hide_block_regions(firstToken, "#endif", "P");
 
   _restore_pos2( p );
}

HS2

mikesart

  • Community Member
  • Posts: 56
  • Hero Points: 11
Re: #if 0 commenting
« Reply #11 on: February 01, 2007, 10:18:21 PM »
I want to put in another vote for this feature in some way shape or form. I dislike having parts of my code hidden. And often times I ifdef out a block that isn't going to run, I don't care whether it's tagged or not, but it's there for reference. And I can't use multiline comments because it already has those in the block.

Would a possible cheap solution to add the ability to color any line with LEVEL_LF > 0 work? Then you could add set_level_lf_color() and expand_all() to their macro above? Or even the ability to add our own flag to a line (USER_COLOR_LF) and let me write the macros to set those bits with _lineflags() myself?

For what it's worth, I believe Visual Studio 2005 colors blocks of code it believes is unused as well, not just Source Insight.
Thanks,
 -Mike

Dennis

  • Senior Community Member
  • Posts: 3954
  • Hero Points: 515
Re: #if 0 commenting
« Reply #12 on: February 01, 2010, 07:41:30 PM »
Since this is one of the most read threads on the forum, I thought it would be useful to wrap things up by mentioning that this feature was added to SlickEdit back in 2009 and goes the whole nine yards, handling nesting, #if expressions, and looking up defines in the same way that the tagging engine does.  Document > C/C++ Options > Preprocessing...

LBCEi

  • Senior Community Member
  • Posts: 261
  • Hero Points: 21
Re: #if 0 commenting
« Reply #13 on: February 02, 2010, 12:33:40 AM »
Since this is one of the most read threads on the forum, I thought it would be useful to wrap things up by mentioning that this feature was added to SlickEdit back in 2009 and goes the whole nine yards, handling nesting, #if expressions, and looking up defines in the same way that the tagging engine does.  Document > C/C++ Options > Preprocessing...

Dennis

Are you trying to say that coloring as shown in the examples by Ding should work?  I sure don't see that (in 14.0.2 on WinXP with all hotfixes).

I see in Options > Appearance > Colors that there is a color definition for Inactive Code (under the Comments section).  A note near the top of this options page says "This color is used for code which is preprocessed out, such as #if 0 blocks."  I've never seen that work, though.

The options page you mentioned is quite confusing.  How can these options be used to achieve the desired behaviour?  The notes at the bottom don't help.

Thanks
Les

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: #if 0 commenting
« Reply #14 on: February 02, 2010, 01:21:56 AM »
The inactive code highlighting works consistently for me in C and C++ files.
I haven't tried it in other files.

Do you have symbol coloring enabled?
I believe that inactive code coloring is part of symbol coloring, so if symbol coloring is disabled then inactive code coloring will not be performed.

Can you share a small sample file where inactive code is not highlighted, and include screen shots of the various color coding option pages?