Hi Steef, first, thanks for your quick answer. And you are right; C style comments can be quite problematic. But using conditional preprocessor directives can cause quite similar problems; just imagine there is a single #if or #ifdef inside the block you want to hide! By the way, only C++ style comments really seem to be completely problem-free :-(
But that wasn't quite the problem I had. Do you really mean that it's the better way to hard-code moving the cursor to the beginning of the line than to leave this decision to the user? You wrote: > Of course, the #if/#endifs should always start at a new line, which may > be difficult to implement. I don't think that this is a problem. I would (and have :-) implement it like this: --- + f \.h$ | f \.c$ | f \.cc$ | f \.C$ | f \.H$ | f \.cpp$ 6 #if 0 ... #endif TEMPFILE="$(dirname %b)/cooledit.temp" echo -e "\n#if 0" > $TEMPFILE cat %b >> $TEMPFILE cat $TEMPFILE > %b echo -e "\n#endif" >> %b --- For the user (or the programmer of the editor user menu ;-) it is always possible to insert a newline (as you can see above); it stays an option. But if it's hard-coded (as it is in the moment), it's no more an option; for the user there is NO way to suppress it. I really think that there are a lot of use cases where this is a problem. Here is another example (something I'm gonna use more and more): Imagine you're editing a text and you want to highlight a sentence or more containing something very important (maybe copyrights ;-) by turning it to uppercase. The user menu command may look like this (common section): --- u turn to uppercase TEMPFILE="$(dirname %b)/cooledit.temp" LOWER="abcdefghijklmnopqrstuvwxyzäöü" UPPER="ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜ" sed -e "y/$LOWER/$UPPER/" %b > $TEMPFILE cat $TEMPFILE > %b --- And you can imagine that not all sentences you want to highlight start at the beginning of a line. Example: Applying the `turn to uppercase' command to the second sentence of the following text --- To determine the scope of a declaration, it is some- times convenient to refer to the potential scope of a declaration. The scope of a declaration is the same as its potential scope unless the potential scope contains another declaration of the same name. In that case, the potential scope of the declaration in the ... --- results in the following: --- To determine the scope of a declaration, it is some- times convenient to refer to the potential scope of THE SCOPE OF A DECLARATION IS THE SAME AS ITS POTENTIAL SCOPE UNLESS THE POTENTIAL SCOPE CONTAINS ANOTHER DECLARATION OF THE SAME NAME.a declaration. In that case, the potential scope of the declaration in the ... --- This is entirely unacceptable, isn't it? It should (and does exactly with the changes in `edit.c') look like this: --- To determine the scope of a declaration, it is some- times convenient to refer to the potential scope of a declaration. THE SCOPE OF A DECLARATION IS THE SAME AS ITS POTENTIAL SCOPE UNLESS THE POTENTIAL SCOPE CONTAINS ANOTHER DECLARATION OF THE SAME NAME. In that case, the potential scope of the declaration in the ... --- Ok, that's all (and `CRTL-o' within the editor is divine :-))) Matthias PS: Is `word completion' within the editor a subject for you at all? _______________________________________________ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel