unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: debug declaration.
Date: Fri, 25 Mar 2005 10:14:38 -0500	[thread overview]
Message-ID: <m1is3fvkis.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87wtrwf0iq.fsf@xs4all.nl> (Lute Kamstra's message of "Fri, 25 Mar 2005 12:06:05 +0100")

>> Try (debug (sexp def-form def-form def-form form def-form [&optional stringp]))

> This does indeed work.  (The brackets are not necessary, are they?)

I find it good practice to always use the brackets, but you're right, it's
not necessary.

> The node "Specification List" in the lisp manual says that def-form
> can only be used after &define, however.  And when I do that, things
> seem to break.

Experience proves the doc is wrong.  What I found instead is that `form'
can't be used after &define.  I think the bug is not that things don't work
with `&define' but that edebug should burp on a spec that uses both &define
and `form' (or `body' for that matter).

>> Another option is to evaluate those arguments before you plug them in the
>> body of your major mode function, so they're only evaluated once, when
>> the major mode is defined, thus reproducing the "pre-macro" behavior.

> Considering backward compatibility, that's probably the right thing to do.

It also moves more work to macro-expansion time which is good.  But beware,
it can also break backward compatibility, because now evaluation can take
place at byte-compile time.

OTOH it's closer to what I meant by "turn it into a macro" (in the comment
that prompted you to look into this whole thing).
Ideally define-generic-mode should (just like define-derived-mode does)
generate stand-alone code which does not require generic.el.


        Stefan

  reply	other threads:[~2005-03-25 15:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-23 15:54 debug declaration Lute Kamstra
2005-03-23 18:18 ` Stefan Monnier
2005-03-25 11:06   ` Lute Kamstra
2005-03-25 15:14     ` Stefan Monnier [this message]
2005-03-27  3:52       ` Richard Stallman
2005-03-30  8:12       ` Lute Kamstra
2005-03-31 18:21         ` Richard Stallman

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=m1is3fvkis.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --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).