all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Subject: skeleton.el machinery eats newlines.
Date: Tue, 7 Jan 2003 22:29:11 -0600 (CST)	[thread overview]
Message-ID: <200301080429.WAA23098@eel.dms.auburn.edu> (raw)

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.

             reply	other threads:[~2003-01-08  4:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08  4:29 Luc Teirlinck [this message]
2003-01-10  4:36 ` skeleton.el machinery eats newlines Luc Teirlinck
2003-01-10  6:24   ` Luc Teirlinck
2003-01-10 15:33     ` Luc Teirlinck
2003-01-11  0:21     ` Richard Stallman
2003-01-11  2:35       ` Luc Teirlinck
2003-01-11 19:27       ` Stefan Monnier
2003-01-12 17:10         ` Luc Teirlinck
2003-01-12 19:05           ` Luc Teirlinck
2003-01-11 21:44   ` Luc Teirlinck
2003-01-11 21:49     ` Luc Teirlinck
2003-01-11 22:27     ` Luc Teirlinck
2003-01-11 23:45     ` Glenn Morris
2003-01-11 23:49       ` Luc Teirlinck
2003-01-12  0:34         ` Luc Teirlinck
2003-01-12  1:20           ` Luc Teirlinck
2003-01-12  2:22             ` Luc Teirlinck
2003-01-20  4:25               ` Luc Teirlinck
2003-01-11 19:43 ` Stefan Monnier
2003-01-11 21:29   ` Luc Teirlinck
2003-01-12  5:23   ` Luc Teirlinck
2003-01-12  6:14   ` Luc Teirlinck
2003-01-17 20:37 ` Stefan Monnier
2003-01-18  1:43   ` Luc Teirlinck
2003-01-18 20:41 ` Stefan Monnier
2003-01-19  1:02   ` Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200301080429.WAA23098@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.