2 bugs conected to(?) folding.el

[Richard Jelinek <rj@petamem.com>]

[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]

Hi,

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
behaviour described]

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
   saved.

   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
   sh-iso-* files.

   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. :-)


-- 
best regards,

     Dipl.-Inf. Richard Jelinek

     - The PetaMem Group - Prague/Nuremberg - www.petamem.com -
		       -= 3394928 Mind Units =-

[-- Attachment #2: sh-isout8.tbz2 --]
[-- Type: application/octet-stream, Size: 337 bytes --]

[-- Attachment #3: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs