Menu
▾
▴
[ jEdit-devel ] [ jedit-Feature Requests-2868804 ] #if 0 directive
|
From: SourceForge.net <no...@so...> - 2009-10-30 09:44:22
|
Feature Requests item #2868804, was opened at 2009-09-28 14:21 Message generated for change (Comment added) made by richard-boaz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2868804&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: richard boaz (richard-boaz) Assigned to: Nobody/Anonymous (nobody) Summary: #if 0 directive Initial Comment: As previously requested, it would be nice if jedit would automatically recognize the "#if 0" CPP directive used to comment out large blocks of C-code. This was previously requested under Artifact ID # 2023939, but was rejected for various reasons. I am re-requesting this because: 1) this functionality is readily available in gedit; if there, why not in jedit? 2) the previous rejection noted that this is CPP processing, which is true, but I'm not sure I see the point. It is a CPP directive that means "code does not exist", much like the comment directive /*...*/ means to the compiler that "code does not exist". Why is there a perceived difference between what the first pass and the second pass of the compiler does when the effect is the same, code has been commented out and the editor should tag it as such and draw accordingly. 3) that there can be embedded #if statements is also true, and? count the #if and corresponding #endif's and comment out everything between #if 0 and its corresponding #endif. Why? because this is a very standard manner of blocking out large chunks of C code. That jedit does not recognize this is a shame and a shortcome of its C-code syntax highlighting functionality. And, because gedit does have this, I really don't see why it wouldn't be handled just because the functionality comes with "issues" ('#if 0' with two blanks, e.g.). Please re-consider this request, and when doing so, recall that an application's functionality follows standard usage, not the other way around. thanks, and thanks for a great program! richard boaz ---------------------------------------------------------------------- >Comment By: richard boaz (richard-boaz) Date: 2009-10-30 10:44 Message: 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." ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-09-28 21:31 Message: > 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2868804&group_id=588 |