Re: Re: mcedit bug

[murban <murban cs uni-magdeburg de>]

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?