help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A couple rudimentary elisp questions


From: Pascal Bourguignon
Subject: Re: A couple rudimentary elisp questions
Date: 01 Mar 2004 03:17:55 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

exits funnel <exitsfunnel@yahoo.com> writes:

> Hello,
> 
> I'm pretty new to emacs and I've decided it's time to
> take a crack at some simple lisp.  I have a couple
> silly questions:
> 
> 1) Is there no way to specify multi-line comments?  I
> read the 'comments' section in the 'Emacs Lisp
> Reference Manual' and it seems to indicate not, but it
> seems kind of hard to believe.  I'm trying to write a
> custom c-style and it would be helpful if I could
> comment/uncomment large chunks of my .emacs file and
> reload it so I could try to figure out what's going
> on.  If there really are no multi line comments is
> there any tricks for kludging it?

In emacs lisp there's no multiline comment. You can use
comment-region / uncomment-region to comment several lines at once.

Otherwise you can use this trick: use a multi-line string as a
comment, like you do for documentation strings:

(defun my-fun ()
    " This
is the documentation
string of the function
my-fun that appears 
when you ask for the 
function documentation
with (describe-function 'my-fun)
or C-h C-f my-fun RET
"
    (do-something)
    " Here is a ''comment''
      spread on several
      lines.
      Actually, it's not a 
      comment, it's a string
      that is ''evaluated''
      in the course of this
      function, but since
      we don't do anything
      with it, it's finally
      ignored. "
    (do-something-else)
    (get-result))

Of course, since the strings are syntactically significant, you must
take care where you put them. You can't put them inside function
argument lists, or inside other data lists.  They eventually get
ignored only in statement lists, inside progn and equivalent (and not
in a result position!).

Perhaps a cleaner way to do it would be to defined a comment macro:

    (defmacro rem (&rest args))

    (defun my-fun ()
    " This
is the documentation
string of the function
my-fun that appears 
when you ask for the 
function documentation
with (describe-function 'my-fun)
or C-h C-f my-fun RET
"
    (do-something)
    (rem Here we have a "comment"
         but it is still scanned
         and tokenized.
         "So we may still use strings
          and use any kind of invalid
          token such as . . . :-)
          But note that you must still
          escape double-quotes such as: \"
        ")
    (do-something-else)
    (get-result))

You get two advantages with this rem macro:

    1- a code walker can find your comments if you need to process them.

    2- since the macro generates nothing, the comment/strings don't
       eventually appear in compiled code, and the execution  of
       compiled code is strictly equivalent with or without the (rem ...)
       (that could be not the case without the macro).

 
> 2)  I see alot of lists of the form (foo . bar).  What
> does the dot specify?  

It's the notation for a cons cell:

    (cons 'foo 'bar) == (foo . bar)

Lists are built on cons cells, starting from the empty list ():

    (cons 'foo ())             == (foo . ())          == (foo)

    (cons 'bar (cons 'foo ())) == (bar . (foo . ()))  == (bar foo)

    (cons 'baz
      (cons 'bar
         (cons 'foo ()))) == (baz . (bar . (foo . ()))) == (baz bar foo)


The value assigned to the symbol nil is (), the empty list, which is
actually a special atom. 
The empty list () is NOT a cons: (consp ()) == nil, (atom ()) == t.

 

-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]