unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: skeleton.el machinery eats newlines.
Date: Sun, 19 Jan 2003 22:25:43 -0600 (CST)	[thread overview]
Message-ID: <200301200425.WAA16034@eel.dms.auburn.edu> (raw)
In-Reply-To: <200301120222.UAA28562@eel.dms.auburn.edu> (message from Luc Teirlinck on Sat, 11 Jan 2003 20:22:03 -0600 (CST))

I did not realize that the subject I initiated in another thread
(sh-script.el and magic numbers) had already been discussed before.
It was not my intention to rediscuss issues on which a decision had
already been made.  That decision was that sh-script.el should not
rely on shell scripts starting with any kind of comment, magic or
other.  It seems to me that the very fact that the subject seems
controversial indicates that this decision was correct, since we are
in the business of helping people write in whichever style they
choose, not in the business of prescribing programming styles (except,
of course, for stuff submitted for inclusion in Emacs).

Given that, however, we have at least one problem.  (I now believe
that the other two problems I referred to, but did not elaborate on,
can both be solved, by the user, by giving sh-shell-file a file local
value, so I will not go into these.)

This leaves the "Beginning of buffer" problem.  Trying sh-case
(normally bound to C-c C-c) at the very beginning of the buffer pretty
soon aborts with this error.  Nothing wrong with sh-case or skeletons,
`sh-get-indent-info' is to blame, as I reported earlier in this thread.
(I really should have made a separate thread out of this, it has
nothing to do with skeleton.el.)  I could repost my bug reports from
more than a week ago if this would seem useful.

The problem is, as I explained earlier, that sh-get-indent-info does a
(forward-char -1) at the beginning of the buffer.  I first (naively)
tried (unless (bobp) (forward-char -1)), but this was not good
enough.  For a correct return value (and hence for correct
indentation, in particular of the case form) point really needs to be
at position 0, just before the beginning of the buffer.

One obvious (but probably contorted and inelegant) way in which the
problem can be solved is to add a newline at the beginning of the
buffer at the start of sh-get-indent-info, erase it at the end of that
function and then replace the resulting (t NUMBER) by (t (1- NUMBER)).

A more elegant solution seems to require a good understanding of the
entire sh-script.el indentation mechanism.  At present, I do not have
the time to start studying that mechanism.  I have the impression that
anybody familiar with that mechanism could come up with a much more
elegant solution than the one described above.  However, I could
implement that solution if it would be considered acceptable and
nobody would come up with a better one.  (I believe that the only
problem with that solution is its stylistic inelegance.)

Sincerely,

Luc.

  reply	other threads:[~2003-01-20  4:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08  4:29 skeleton.el machinery eats newlines Luc Teirlinck
2003-01-10  4:36 ` 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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=200301200425.WAA16034@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).