(112/212) 311 - #if 0 directive

> 2) the previous rejection noted that this is CPP processing, which is true,
> but I'm not sure I see the point.

Let me rephrase the point.
(See this link to patch #2023939 for "the previous rejection"):
https://sourceforge.net/support/tracker.php?aid=2023939

I don't think it is a good idea to support only "#if 0" because it gives
false impression that jEdit is evaluating the CPP conditions. In fact,
jEdit syntax engine will hardly be able to evaluate CPP conditions.
For example, "#if SIZE < LIMIT", "#if \!defined(SOME_CONFIG)", ...

With such false impression, users will likely feel odd finding many
other conditions which are obviously known to be false \*in their minds\*
are not colored in jEdit as they think.
For example, "#if FALSE", "#if 1 ... #else" (between #else and #endif),
"#ifdef __GNUC__" (for VC++ users), "#ifdef _MSC_VER" (for gcc users),
...
I think this is bad.

Other issues, for nested conditionals or two blanks, are not for the
idea itself. I know that it is possible to implement the both only in
the mode file.

> Why? because this is a very standard manner of blocking out large chunks
> of C code.

Personally, I don't think so. If you are using a version control tool
(I believe this is a \*standard\* of modern C programs), you should simply
remove them.


FYI:
VC++ does color conditional blocks only for compiled sources. This is a
best solution in IDE, but not in the scope of a text editor.
Emacs have cpp-highlight-buffer that seems not to have the above concern
since all configurations are explicitly supplied from user for each
expression. This will be a possible solution.

Let me rephrase my point.

stating that by supporting the single pre-processor directive #if 0 would give a false impression that jedit would then support all pre-processor directives is absurd.

to state that "personally" you think for C programmers using #if 0 is not a standard way of blocking out large chunks of code merely means you are not a typical C programmer, and again, your comment is absurd.

it's a shame that someone who doesn't understand the issue properly is the same person to decide whether or not this feature request is implemented or rejected.

like i said, i'll just use gedit where it is standard functionality.

what a shame, such a nice program coupled with such absurd comments and observations from those "in power."

Actually, using #if 0 is not only a common practice, it is a recommended practice. See the Mozilla C++ Portability Guide: https://developer.mozilla.org/en/C___Portability_Guide

How about posting the question on the jEdit users mailing list to get an idea of what people would prefer? If this request is doable in a mode file, how about posting the mode file on the community site so those users that want it can install it themselves? I don't see the point of annoying users when giving them the choice doesn't seem to be particularly difficult. This starting to feel a lot like the problem the Pidgin developers created when they wouldn't allow the text entry box to be resizable.

No one is "in power" about jEdit. It's a open source software and
dicisions are made in collaborative manner. For example, please think
about why I didn't just close this request as rejected while putting a
negative comment.

I may accept another patch if it comes with a comment which shows me a
reasonable solution or justification for my concern. Another developer
may accept it without such comment if it shows enough selling points.

As for your choice of the editor, it seems best for you to use jEdit
with a patched c.xml in your local no matter how this request goes in
the future.

For a person who has come here likely as a big fan of "#if 0", here are
some links telling why it shouldn't be so often.
http://www.markhneedham.com/blog/2009/01/17/the-danger-of-commenting-out-code/
http://www.google.com/search?q=%22comment+out%22+code+%22version+control%22

The Mozilla C++ Portability Guide, which is already given as saying
"#if 0" is a recommended practice, also says:
> Of course, this kind of thing should always be a temporary thing, ...

you are mixing apples and oranges. the recommendation of \*not\* using #if 0 to which you refer in your last comment refers to permanent code that is intended for release (and, it must be noted, for ultimate portability).

in other words, the domain of released code that is intended to be portable is not the same as the domain of a source code editor. in that, it is a very bad idea to leave code around forever that is commented out. and it is a very good idea to be able to comment out large blocks of code during the development life cycle.

in my very first comment, i tried to get you to think about this differently, namely that:
1) functionality of any given program should follow common user usage, not the other way around.

in other words, an application that dictates how the world should behave is an application that will not fully satisfy the user's needs. think microsoft.

but you disregard this manner of thinking, which is made obvious by the fact that you are now coming up with completely specious arguments to maintain your position.

like i said, a shame.

and you have failed to address one of my points: why did the developers of gedit feel that including this functionality was a good idea and ultimately do so?

and i would really like to hear from someone else on this subject that contributes to jedit. is there a single C programmer contributing to jedit you can't discuss this with more directly instead of trying to convince me of what common C programming practices are? how old are you, by the way? i have been programming and providing applications to users for more than 25 years and know very well of what i speak. but this depth of experience seems to be of zero consequence to you.

really, instead of trying to convince me any further, find someone else within the jedit team to discuss this with. i'm done.

>> jEdit already satisfies the needs to color the block in "#if 0" if an
>> user believe that it's good for himself, by allowing customization of
>> the mode file. And a casual patch is available. I think this is enough
>> easy at least for now. (I recommended this for you.)

perhaps we've been talking about two different things. i just want the functionality, and i don't really care how it's implemented. if i am able to do this myself as a one-time configuration option that then works for me, i'm happy.

that it must be some sort of "default" implemntation for all of jedit and all users i really have no opinion, whatsoever.

i'm a little confused why it wasn't made more clear that i already had the ability to implement this is a bit confusing, but nevermind. i am a casual user of jedit (meaning, i just want it to "work"), not one who has the time to delve into the myriad of configuration possibilities within jedit to (maybe) find what i'm looking for.

i will look to customizing the mode file. as i said, i just want a solution, and i don't really care how.

thanks.