[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
2 bugs conected to(?) folding.el
2 bugs conected to(?) folding.el
Thu, 5 Aug 2004 12:20:00 +0200
we're using gnu-emacs (GNU Emacs 21.3.1) for development, mostly in
the combination cperl-mode, folding-mode
As this "IDE" is standard for all our developers, certain problems
became more and more annoying when it comes to larger projects:
[I do not have enough knowledge of emacs internals, so when I speak of
"emacs" down there, I may mean the hilit behaviour, or some
mode. Actually I don't know exactly who/what is responsible for the
1) It seems, emacs does consider folded parts of source still as
visible, so if you have a x000-line sourcecode, nicely folded so
you se the structure and main elements/list of subroutines on one
page, editing becomes nearly impossible at the beginning of the
file, cursor-movement may take a second or more. The problem
vanishes the more you move the cursor to the end of the file.
My stab at this is, that hilit/indentation/whatever of the
cperl-mode, ignores the fact, that folded blocks are not visible
and so if you have a 3000-line source folded on your screen, all
these lines behind the cursor are updated with every cursor
movement/keypress you make.
IMHO, folded parts should be treated the same way as parts outside
the visible buffer. Because if I move the folded elements outside
the visible buffer (say via adding blank lines), and edit such a
file right at the start, there's no delay anymore.
2) A second problem is connected to folding and utf-8 (at least we
have seen this only on utf-8. This problem is not present, when the
file is in some iso-encoding.
I have mailed to the perl-porters list, but it seems the problem
would be on emacs' side, because bash also handles some
special (wrong) cases the same way. Ok - what is happening?
I've attached are 4 examples of simple bash-scripts (as tbz2-file -
to prevent some mistake in de/encoding when the files reach you)
sh-iso-fld.sh - bash script, ISO encoded, saved with folded
sh-iso-unf.sh - bash script, ISO encoded, saved with unfolded
sh-ut8-fld.sh - bash script, UTF-8 encoded, saved with folded
sh-ut8-unf.sh - bash script, UTF-8 encoded, saved with unfolded
Only the sh-ut8-fld.sh file has the behaviour, that it doesn't work
at execution. Same is true when we try to run some perl-programs
where the source is utf-8 and parts were folded when the source was
The content of the folded block is not seen by the interpreter,
evidently because <CR> is considered being part of the comment and
not as a line-break.
Interesting is, that the iso-encoded files don't show this
behaviour, actually I cannot see the difference between the two
What could be done to circumvent this behaviour when working with
utf-8 encoded files? Well - one workaround is to always unfold
whole buffer, then add and remove a char (so emacs takes this
buffer as modified) and then save it. A little bit clumsy isn't it?
You bet that developers often forget this and then the interpreters
start complaining about "undefined subroutines" and the like.
These problems became that annoying, that we decided to put a bounty
of 500US$ on their head. Payable either to the FSF or the individual
that provides a solution during 08/2004. Changing the IDE is not an
option for us as of now. :-)
Dipl.-Inf. Richard Jelinek
- The PetaMem Group - Prague/Nuremberg - www.petamem.com -
-= 3394928 Mind Units =-
Description: Binary data
- 2 bugs conected to(?) folding.el,
Richard Jelinek <=