From: The Jackster
Subject: emacs Lisp String Output
Date: 
Message-ID: <1140138894.651477.27270@z14g2000cwz.googlegroups.com>
I've searched through just about every emacs Lisp "Hello world."
example in this list, and most don't work. I get various errors...

Can someone help by posting code for a "Hello world." program for emacs
Lisp?

I haven't found any emacs Lisp tutorials that show how to send text to
standard output... Does anyone know of a resource for handling text?
All I want to do is send text to standard out. If I had a kingdom to
give, I would graciously give it for the secrets of sending text to
standard out. Thanks!

From: Alexander Schmolck
Subject: Re: emacs Lisp String Output
Date: 
Message-ID: <yfsr762sntb.fsf@oc.ex.ac.uk>
"The Jackster" <··············@yahoo.com> writes:

> I've searched through just about every emacs Lisp "Hello world."
> example in this list, and most don't work. I get various errors...
> 
> Can someone help by posting code for a "Hello world." program for emacs
> Lisp?
> 
> I haven't found any emacs Lisp tutorials that show how to send text to
> standard output... Does anyone know of a resource for handling text?
> All I want to do is send text to standard out. If I had a kingdom to
> give, I would graciously give it for the secrets of sending text to
> standard out. Thanks!

Easy:

 (print "Hello World!")

'as
From: The Jackster
Subject: Re: emacs Lisp String Output
Date: 
Message-ID: <1140146040.220283.11200@g14g2000cwa.googlegroups.com>
Thanks! Why does my output look like:

^J"Hello World!"^J"Hello World!"

There are two instances of "Hello World!" prefaced with "^J". Any idea
why?
From: funkyj
Subject: Re: emacs Lisp String Output
Date: 
Message-ID: <1140149858.056996.314770@g43g2000cwa.googlegroups.com>
how are you executing your commands?  Are you using ielm?

perhaps you are typing C-x C-e in the *scratch* buffer.  In this case
try evaluating this in the scratch buffer:

   (- 100 31)

There is no print statement at all yet I see "69" in the echo area when
I evaluate that expression.

The *scratch* buffer is not the best way to play with emacs lisp.  I
recommend using ielm:

    M-x ielm

you can also try

  (message "hello world")

in both the scratch buffer and in ielm.  You might want to pickup the
'GNU Emacs Lisp Reference Manual' and also 'An Introduction to
Programming in Emacs Lisp'.  You should be able to find them on the
internet by googling, or if you are lucky by typing

  C-h i

 in emacs.

Cheers,
  --jfc


Cheers,
  --jfc
From: senator
Subject: Re: emacs Lisp String Output
Date: 
Message-ID: <1140162930.757843.269950@g43g2000cwa.googlegroups.com>
jfc:  Oh man! ielm? Where is _that_ documented? All this time, I've
been using scratch... I think this is a serious oversight in the Elisp
manual. If not for you, there would've been no way in I would know
about this..... should I be happy or angry?

Jackster:  In case you aren't sure, comp.lang.lisp is about Common
Lisp, which is related to, but different from Emacs Lisp.
From: Pascal Bourguignon
Subject: Re: emacs Lisp String Output
Date: 
Message-ID: <87pslmjofn.fsf@thalassa.informatimago.com>
"senator" <···············@gmail.com> writes:

> jfc:  Oh man! ielm? Where is _that_ documented? All this time, I've
> been using scratch... I think this is a serious oversight in the Elisp
> manual. If not for you, there would've been no way in I would know
> about this..... should I be happy or angry?

Really!  Here in CL, we have a fine team of hackers working hard to
allow us to use a *slime-scratch* buffer instead of the REPL, and you
having  already *scratch* in emacs for emacs-lisp, you want ielm?



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
From: senator
Subject: How do you use scratch? (Was "emacs Lisp String Output")
Date: 
Message-ID: <1140324262.239996.196960@g43g2000cwa.googlegroups.com>
> "senator" <···············@gmail.com> writes:
> > jfc:  Oh man! ielm? Where is _that_ documented? All this time, I've
> > been using scratch... I think this is a serious oversight in the Elisp
> > manual. If not for you, there would've been no way in I would know
> > about this..... should I be happy or angry?
>
> Really!  Here in CL, we have a fine team of hackers working hard to
> allow us to use a *slime-scratch* buffer instead of the REPL, and you
> having  already *scratch* in emacs for emacs-lisp, you want ielm?

> __Pascal Bourguignon__                     http://www.informatimago.com/

Err, you're saying the scratch is better than the REPL (or that you
don't need the REPL)? Assuming you're not joking, how do seasoned
hackers use scratch or the REPL? This is similar to a "What is your
work-flow pattern like" question.

I use scratch (either slime or elisp ones) for multi-line quick
drafts, and this is convenient for some tests. However, I also use the
REPL a lot! I come from a dos/unix-shell, Matlab, Mathematica, or
python background, so that's my idea of what the Lisp REPL does(but
with added steroids). Is that right?

In the REPL, I get information about the current package (I get
confused about my current package when using Slime, it seems each
file has eval-last-sexp's happening in its own package).

The REPL is great for 1 liners. This way, I also get to use
<M-p>/<M-n> to navigate the history of commands to rerun them.  All
previous interactions and answers stay in that REPL buffer, so I can
scroll back up to refer to them (gives context).  I find myself using
the REPL even for some multi-line commands, since it's easy to
retrieve using M-p anyway.

In contrast, when working from scratch, I only get to use C-x C-e
(slime-)eval-last-sexp (or slime-eval-print-last-sexp for inserting
the answer back into the same buffer). What then? I can continue
evaluating defuns or whatever, but when it comes time to run them, the
REPL is still king (for me). If I evaluate them in scratch, I can get
1 answer, but repeated evaluation of similar commands (I do that a
lot) is not convenient. I either lose the answer (eval last sexp ->
minibuffer) or get clogged up (eval print -> below the sexp, repeated
evaluation causes printed answers to build up), so there's extra
effort to clean up (delete) previous answers.

In short, for me, the scratch buffer is extremely useful for
evaluating drafts of my functions and some commands, but cannot beat
the REPL for interactivity, context, and speed. If I am mistaken, what
can I do to improve my experience with scratch (emphasis on Slime,
forget about Emacs scratch)?

After I have written all this, you better not say you were only joking
(Grrr.... Vvshows fangsvV)

Cheers, pointers appreciated. I hope this is not seen as a frivolous
question -> anything to help them sore wrists would be good.
From: Pascal Bourguignon
Subject: Re: How do you use scratch?
Date: 
Message-ID: <878xs7zzg5.fsf@thalassa.informatimago.com>
"senator" <···············@gmail.com> writes:

>> "senator" <···············@gmail.com> writes:
>> > jfc:  Oh man! ielm? Where is _that_ documented? All this time, I've
>> > been using scratch... I think this is a serious oversight in the Elisp
>> > manual. If not for you, there would've been no way in I would know
>> > about this..... should I be happy or angry?
>>
>> Really!  Here in CL, we have a fine team of hackers working hard to
>> allow us to use a *slime-scratch* buffer instead of the REPL, and you
>> having  already *scratch* in emacs for emacs-lisp, you want ielm?
>
> Err, you're saying the scratch is better than the REPL (or that you
> don't need the REPL)? Assuming you're not joking, how do seasoned
> hackers use scratch or the REPL? This is similar to a "What is your
> work-flow pattern like" question.

Well, actually I rarely use the buffer *scratch* itself, I edit
directly lisp source files, and evaluate from them.  Definitions stay
and become source;  then I encapsulate the test expressions in a
(defun test () ...) for an instant unit test.


> I use scratch (either slime or elisp ones) for multi-line quick
> drafts, and this is convenient for some tests. However, I also use the
> REPL a lot! I come from a dos/unix-shell, Matlab, Mathematica, or
> python background, so that's my idea of what the Lisp REPL does(but
> with added steroids). Is that right?

I must confess I use the REPL too, but it's more inconvenient because
you have to copy/paste between the REPL and the source files.  It
would be easier with some environment utility to keep the source in
the image, etc.


> [...]

All right, we alternate between source & REPL interaction.   

I more often use directly inferior-lisp, so I split the frame in two,
with the source above and the REPL below, and type C-x C-e in the
source, and get the log in the REPL: best of both worlds :-)

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"This statement is false."            In Lisp: (defun Q () (eq nil (Q)))
From: Geoffrey Summerhayes
Subject: Re: emacs Lisp String Output
Date: 
Message-ID: <kbcJf.43186$T35.712718@news20.bellglobal.com>
"The Jackster" <··············@yahoo.com> wrote in message ····························@g14g2000cwa.googlegroups.com...
> Thanks! Why does my output look like:
>
> ^J"Hello World!"^J"Hello World!"
>
> There are two instances of "Hello World!" prefaced with "^J". Any idea
> why?

The first instance of "Hello World!" is due
to what print does, the second instance is
from what print returns.

As for the ^J, it's a linefeed character, but it
looks like the buffer wanted a CR or CR-LF pair,
what platform and version are you running and
how are you interacting with elisp?

--
Geoff
From: Thomas A. Russ
Subject: Re: emacs Lisp String Output
Date: 
Message-ID: <ymi1wxweh0m.fsf@sevak.isi.edu>
"The Jackster" <··············@yahoo.com> writes:

> Thanks! Why does my output look like:
> 
> ^J"Hello World!"^J"Hello World!"
> 
> There are two instances of "Hello World!" prefaced with "^J". Any idea
> why?

Well, without seeing the code that produced the output, it's really hard
to say with any certainty.

Nevertheless, I suspect that what you are seeing is the printed output
produced by your output function, followed by the read-eval-print loop
printing the returned value (which for many standard print routines is
the argument that was just printed.

This, of course, got me thinking about why this would be useful.  I
concluded it can be used to insert print statements into chains
returning values in lieu of more general tracing, during debugging:

   (f x y (g (h z)))
   (f x y (g (print (h z))))


-- 
Thomas A. Russ,  USC/Information Sciences Institute