From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Jelinek Newsgroups: gmane.emacs.bugs Subject: 2 bugs conected to(?) folding.el Date: Thu, 5 Aug 2004 12:20:00 +0200 Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <20040805122000.A12054@petamem.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" X-Trace: sea.gmane.org 1091701238 7859 80.91.224.253 (5 Aug 2004 10:20:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Aug 2004 10:20:38 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 05 12:20:23 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BsfME-0003hD-00 for ; Thu, 05 Aug 2004 12:20:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BsfPl-0003vC-W0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Aug 2004 06:24:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BsfPc-0003qw-1L for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2004 06:23:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BsfPY-0003qI-IU for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2004 06:23:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BsfPY-0003q8-DK for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2004 06:23:48 -0400 Original-Received: from [80.188.114.168] (helo=arkab.petamem.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BsfLu-0000pa-Pa for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2004 06:20:03 -0400 Original-Received: (from rj@localhost) by arkab.petamem.com (8.11.6/8.11.6/SuSE Linux 0.5) id i75AK0j12273 for bug-gnu-emacs@gnu.org; Thu, 5 Aug 2004 12:20:00 +0200 Original-To: bug-gnu-emacs@gnu.org Content-Disposition: inline User-Agent: Mutt/1.3.22.1i X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:8625 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:8625 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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 =- --UugvWAfsgieZRqgk Content-Type: application/octet-stream Content-Disposition: attachment; filename="sh-isout8.tbz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWRjePEwAAcp/1MQSABB4E//4AwAIAH/3nqoBCCwAAgEACDABmAAYaGgAAA0A AAAAYaGgAAA0AAAAAFVNIm1JmgJp6mUxPKD0m1GnqNtSPKep5m8zHU/JfKYlFhIls1d6Wsg7 9lSbAxCg0EEiZcZDOapapRFhQ4nE2m0wFZefA4FhwIMpWLyD0LTMk8o6lBuGAb2h6vOdyc5s 1aPYuMJrJFxL4n3IJnhMrPKCsgQfVXCJaG2VG2I3GHswFRUUKz0spSDtQsQRKFdaqpChOrGU J8mFjMTebT9IIWrEy40krRqOJyMhMwHqNxaVEzkl4koMJ4DdL5aS1kan2JisPYzlh2CxR7nA ynzQfs0krx7oGszHaM5eYiC4xmw1mUoWl5Q6f1z7jQUSzkOhc5nQmo/x4n8Gw5iDul1IgynQ qB/xdyRThQkBjePEwA== --UugvWAfsgieZRqgk Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Bug-gnu-emacs mailing list Bug-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs --UugvWAfsgieZRqgk--