mcedit bug
murban
murban at cs.uni-magdeburg.de
Sun Dec 9 15:06:54 UTC 2001
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?
More information about the mc-devel
mailing list