From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: skeleton.el machinery eats newlines. Date: Tue, 7 Jan 2003 22:29:11 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301080429.WAA23098@eel.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1042011028 12710 80.91.224.249 (8 Jan 2003 07:30:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2003 07:30:28 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18WAfP-0003Ic-00 for ; Wed, 08 Jan 2003 08:30:23 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18WAkK-0001A9-00 for ; Wed, 08 Jan 2003 08:35:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18W9qO-0006rS-00 for emacs-devel@quimby.gnus.org; Wed, 08 Jan 2003 01:37:40 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18W9i3-00055s-00 for emacs-devel@gnu.org; Wed, 08 Jan 2003 01:29:03 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18W7pa-0007h2-00 for emacs-devel@gnu.org; Tue, 07 Jan 2003 23:29:13 -0500 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18W7pZ-0007gU-00 for emacs-devel@gnu.org; Tue, 07 Jan 2003 23:28:41 -0500 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id WAA14091 for ; Tue, 7 Jan 2003 22:28:40 -0600 (CST) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id WAA23098; Tue, 7 Jan 2003 22:29:11 -0600 (CST) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10568 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10568 Would it be possible for somebody more familiar with the skeleton.el machinery than I am to take a look at the following? Something in the skeleton.el machinery seems to "eat newlines". The actual manifestations of the problem (at least the ones known to me) occur in the sh-mode commands sh-for and sh-case, but I believe that some bug in skeleton.el is the actual underlying cause. The commands sh-for and sh-case malfunction in the current CVS Emacs and have apparently been malfunctioning for some time. I used them in Emacs20.7, but somehow I have not been using those commands again until very recently. The problem becomes immediately apparent by putting a buffer in sh-mode for bash (other shells probably give similar problems, but bash is what I use and what I looked at) and then using C-c TAB and C-c C-c, answering, say "aa" , or whatever, to all minibuffer questions. Do this first in Emacs20.7 and then in current CVS emacs. Results: Emacs20.7: if [ aa ]; then elif [ aa ]; then elif [ aa ]; then elif [ aa ]; then else fi case aa in aa) ;; aa) ;; aa) ;; aa) ;; aa) ;; aa) ;; *) esac Looks perfect (at least to me). Now today's CVS: if [ aa ]; then elif [ aa ]; then elif [ aa ]; then elif [ aa ]; then elif [ aa ]; then else fi case aa in aa) ;; aa) ;;aa) ;;aa) ;;aa) ;;*) esac Problem: Some obvious newlines are missing. So, at first we guess that there are newlines missing in the define-skeleton 's for those commands. But no, all necessary newlines seem to be there. It is actually perfectly possible to revert to the Emacs20.7 behavior by adding extra newlines anyway. The elif forms require two newlines in the buffer. There are two newlines in the define-skeleton, but we need three in there to get two in the buffer. For the case we need three, there are three newlines in the define-skeleton but four are needed to get three in the buffer. Can somebody familiar with skeleton.el tell me whether for some reason this is actually expected behavior? If it is, then the bug is in the two define-skeleton's and is trivial to correct. If not, the bug is in skeleton.el and might be more complex. A potential candidate for the trouble spot might be changes made by Stefan, more than 7 months ago, in skeleton-internal-1, involving quite some games with newlines. I am absolutely not certain those changes are the culprit, however. I believe it would be a lot easier for somebody really familiar with skeleton.el to get to the bottom of this than it would be for me. Sincerely, Luc.