Cool and Useful LISP for the .emacs file

Cool and Useful LISP for the .emacs file

[Dan Anderson]

I was wondering what other people have in their .emacs file.  I would
like to challenge everyone to add at least one cool tip / trick to:

http://www.emacswiki.org/cgi-bin/wiki/DotEmacs

-Dan

Re: Cool and Useful LISP for the .emacs file

[Kevin Rodgers]

Dan Anderson wrote:

> I was wondering what other people have in their .emacs file.  I would
> like to challenge everyone to add at least one cool tip / trick to:

Sixteen is at least one.  :-)


-- 
Kevin Rodgers

Re: Cool and Useful LISP for the .emacs file

[Bruce Ingalls]

Dan Anderson wrote:
> I was wondering what other people have in their .emacs file.  I would
> like to challenge everyone to add at least one cool tip / trick to:
> 
> http://www.emacswiki.org/cgi-bin/wiki/DotEmacs

The better place is <url: http://www.dotemacs.de/ > the very 
(un)official .emacs home.

-Bruce, editor of http://emacro.sf.net/

Re: Cool and Useful LISP for the .emacs file

[roodwriter]

Dan Anderson wrote:

> I was wondering what other people have in their .emacs file.  I would
> like to challenge everyone to add at least one cool tip / trick to:
> 
> http://www.emacswiki.org/cgi-bin/wiki/DotEmacs
> 
> -Dan

As a non-Lisper I've wondered if anyone thinks it might be useful to open up 
a category to include macros. I realize the vast majority are probably too 
personalized to be useful to the next person but I have a few that might be 
handy for beginners as a small drop-in push-button feature.

One is a macro that reads the name of the file in your grep output and calls 
it up. Another will add groups of numbers and put the answer in your file. 
People that are much more technically adept than I am may have some macros 
that are almost magical.

The advantage from this is that someone could just cruise down the list and 
have something they've never thought of that's extremely useful.

This would probably have to be monitored by someone to insure that 
too-specialized macros wouldn't get on the list (say, requiring certain 
files or directories) or malicious macros deleting files from Dired.

There may be severe drawbacks I haven't considered but I'm just tossing it 
out as an idea.

--Rod

-- 
Author of "Linux for Non-Geeks--Clear-eyed Answered for Practical Consumers" 
and "Boring Stories from Uncle Rod." Both are available at 
http://www.rodwriterpublishing.com/index.html

To reply by e-mail, take the extra "o" out of the name.

Re: Cool and Useful LISP for the .emacs file

[Kevin Rodgers]

roodwriter@core.com wrote:

> One is a macro that reads the name of the file in your grep output and calls 
> it up. Another will add groups of numbers and put the answer in your file. 
> People that are much more technically adept than I am may have some macros 
> that are almost magical.

How does this differ from `M-x grep' followed by `C-x `'?

-- 
Kevin Rodgers

Re: Cool and Useful LISP for the .emacs file

[roodwriter]

Kevin Rodgers wrote:

> roodwriter@core.com wrote:
> 
>> One is a macro that reads the name of the file in your grep output and
>> calls it up. Another will add groups of numbers and put the answer in
>> your file. People that are much more technically adept than I am may have
>> some macros that are almost magical.
> 
> How does this differ from `M-x grep' followed by `C-x `'?
> 

It just doesn't work as well for me. This does. It might be some kind of 
charming eccentricity of my machine.

--Rod

-- 
Author of "Linux for Non-Geeks--Clear-eyed Answered for Practical Consumers" 
and "Boring Stories from Uncle Rod." Both are available at 
http://www.rodwriterpublishing.com/index.html

To reply by e-mail, take the extra "o" out of the name.

Re: Cool and Useful LISP for the .emacs file

[roodwriter]

roodwriter@core.com wrote:

> 
> There may be severe drawbacks I haven't considered but I'm just tossing it
> out as an idea.

I'm guessing from the lack of responses that it's a bad idea.

--Rod


-- 
Author of "Linux for Non-Geeks--Clear-eyed Answered for Practical Consumers" 
and "Boring Stories from Uncle Rod." Both are available at 
http://www.rodwriterpublishing.com/index.html

To reply by e-mail, take the extra "o" out of the name.

Re: Cool and Useful LISP for the .emacs file

[Oliver Scholz]

"roodwriter@core.com" <roodwriter@core.com> writes:

> roodwriter@core.com wrote:
>
>> 
>> There may be severe drawbacks I haven't considered but I'm just tossing it
>> out as an idea.
>
> I'm guessing from the lack of responses that it's a bad idea.

>From the lack of responses I'd rather guess that people *don't* think
that it is a bad idea. :-)

Personally I'd appreciate some extended stuff on keyboard macros. I
hardly ever use them, because I tend to write throw-away Lisp
functions for everything. But maybe it would be a good idea to use
them more often (or rather: use them at all), so I'd love to read your
stuff.

You probably should check whether there is already something on the
Emacswiki about keyboard macros, though.

    Oliver
-- 
21 Brumaire an 212 de la Révolution
Liberté, Egalité, Fraternité!

Re: Cool and Useful LISP for the .emacs file

[Gareth Rees]

Dan Anderson wrote:
> I was wondering what other people have in their .emacs file.  I would
> like to challenge everyone to add at least one cool tip / trick to:

Here's my cool tip:

   Delete your .emacs!

This means that you can go to a new machine, run Emacs on it, and it
works just the same as on your old machine!  No more confusion over
non-default keybindings, unusual settings for variables, bizarre mode
hooks, etc.  And when you find a problem you know it's really to do with
Emacs and not with some "cool" trick you copied out of someone else's
.emacs without understanding it.

-- 
Gareth Rees

Re: Cool and Useful LISP for the .emacs file

[Adam Hardy]

On 11/07/2003 12:27 PM Gareth Rees wrote:
> Here's my cool tip:
> 
>    Delete your .emacs!
> 
> This means that you can go to a new machine, run Emacs on it, and it
> works just the same as on your old machine!  No more confusion over
> non-default keybindings, unusual settings for variables, bizarre mode
> hooks, etc.  And when you find a problem you know it's really to do with
> Emacs and not with some "cool" trick you copied out of someone else's
> .emacs without understanding it.

Can you provide some lisp to put in my .emacs to do that? ;)


Adam
-- 
GNU Emacs 21.3.1 on Linux 2.4.20 RH9

Re: Cool and Useful LISP for the .emacs file

[David Kastrup]

Adam Hardy <emacs@cyberspaceroad.com> writes:

> On 11/07/2003 12:27 PM Gareth Rees wrote:
> > Here's my cool tip:
> >    Delete your .emacs!
> > This means that you can go to a new machine, run Emacs on it, and it
> > works just the same as on your old machine!  No more confusion over
> > non-default keybindings, unusual settings for variables, bizarre mode
> > hooks, etc.  And when you find a problem you know it's really to do with
> > Emacs and not with some "cool" trick you copied out of someone else's
> > .emacs without understanding it.
> 
> Can you provide some lisp to put in my .emacs to do that? ;)

(condition-case error
  (delete-file user-init-file)
 (error (message "While trying to delete .emacs:%s"
         error-message-string error)))

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Cool and Useful LISP for the .emacs file

[Dan Anderson]

> Here's my cool tip:
> 
>    Delete your .emacs!
> 
> This means that you can go to a new machine, run Emacs on it, and it
> works just the same as on your old machine!  No more confusion over
> non-default keybindings, unusual settings for variables, bizarre mode
> hooks, etc.  And when you find a problem you know it's really to do with
> Emacs and not with some "cool" trick you copied out of someone else's
> .emacs without understanding it.

	Start emacs with -q when you have a problem.  It sets it to default
mode.  If you can only reproduce the problem when using your .emacs you
can go about debugging your .emacs file.  

	Of course, some people are probably saying "but debugging LISP is
hard!"  Well, fear not.  Remove the last thing you inserted.  It's
probably what's causing the screw up.  (Or restore the backup you made
of your .emacs from the last time you edited it.  Didn't make one?  Try
loading ~/.emacs~)

	I'd also like to point out that many of us who use Emacs and customize
it until we couldn't think of another feature to code use Emacs for
coding.  Learning LISP is not hard and we are certainly qualified to
make changes to the .emacs

	I'd also like to point out that your site administrator probably has
created a site lisp file similar to the .emacs to customize emacs for
your company or organization.  That or you've never needed to install a
single .el file.  (Come on, not everything is stock).

	Plus, if you've ever changed anything in Emacs and hit the save button
you probably /have/ created machine generated in your .emacs to save
your settings.  

-Dan

Re: Cool and Useful LISP for the .emacs file

[Rob Thorpe]

gareth.rees@pobox.com (Gareth Rees) wrote in message news:<e867ce6d.0311070327.4cd5decc@posting.google.com>...
> Dan Anderson wrote:
> > I was wondering what other people have in their .emacs file.  I would
> > like to challenge everyone to add at least one cool tip / trick to:
> 
> Here's my cool tip:
> 
>    Delete your .emacs!
> 
> This means that you can go to a new machine, run Emacs on it, and it
> works just the same as on your old machine!  No more confusion over
> non-default keybindings, unusual settings for variables, bizarre mode
> hooks, etc.  And when you find a problem you know it's really to do with
> Emacs and not with some "cool" trick you copied out of someone else's
> .emacs without understanding it.

I'm not so extreme.
I would say:

- Never use lisp code you don't understand
- Customize as little as you can possibly bear with
- Don't customize things because its cool
- Examine your .emacs code every few weeks, remove what isn't used.
- Remember everything that's in it.

For all my good intentions my biggest .emacs file is 80 lines long.

Re: Cool and Useful LISP for the .emacs file

[Jody M. Klymak]

Hi Dan,

Dan Anderson <dan@mathjunkies.com> writes:

[snip much good advice...]

> Learning LISP is not hard...

Heh, heh.  Compared to what?  Assembly code?  

I personally find lisp quite difficult.  The opportunities to code in
it are few and far enough between, and the syntax so different from
any other modern language, that I have a one-day overhead just to
spool up to the point where I can do even the simplest thing.  And
thus the coding opportunities get even fewer and further between, and
the cycle spirals to the point where I am dependent on the good nature
of package maintainers to tweak what I want.

This must limit the base of emacs coders.

Despite this, of course, there are many wonderful packages written for
emacs.  It causes me to wonder if this is despite lisp or in some way
because of it.

Cheers,  Jody 

Re: Cool and Useful LISP for the .emacs file

[Kevin Rodgers]

Jody M. Klymak wrote:

> Hi Dan,
> 
> Dan Anderson <dan@mathjunkies.com> writes:
> 
> [snip much good advice...]
> 
> 
>>Learning LISP is not hard...
>>
> 
> Heh, heh.  Compared to what?  Assembly code?  


Compared to any imperative language where each statement has its own syntax.


> I personally find lisp quite difficult.  The opportunities to code in
> it are few and far enough between,


Hardly!  You can spend all day writing Emacs customizations and extensions.  :-)
My Franz and Common Lisp coding days were a decade ago.  :-(

> and the syntax so different from any other modern language,


I see this as a benefit: Java's syntax is tolerable, and I'm a fairly proficient
shell scripter, but I think C/C++ and Perl are unreadable and unwriteable.

> that I have a one-day overhead just to
> spool up to the point where I can do even the simplest thing.  And
> thus the coding opportunities get even fewer and further between, and
> the cycle spirals to the point where I am dependent on the good nature
> of package maintainers to tweak what I want.


Fortunately most of them are good natured, indeed.

The hard part about Emacs Lisp is not the Lisp core, but the Emacs features.
The Lisp control structures, data types, and the operators are similar to many
other languages.  But the Emacs objects like buffers, windows, frames, keymaps,
display tables, coding systems, processes, etc. are complex, and it can be hard
to learn how to program in a way to meet the conventions of its rich user 
interface.


> This must limit the base of emacs coders.


I haven't noticed.  :-)


> Despite this, of course, there are many wonderful packages written for
> emacs.  It causes me to wonder if this is despite lisp or in some way
> because of it.

I think it's obviously because of it.


Hang in there, it's a very rewarding way to program.

-- 
Kevin Rodgers

Re: Cool and Useful LISP for the .emacs file

[Dan Anderson]

> > Learning LISP is not hard...
> 
> Heh, heh.  Compared to what?  Assembly code?  

	You shouldn't cut and paste snippets which lose their meaning.  The
original paragraph said that many people who use Emacs use it to
program.  For most professional programmers learning LISP should not be
hard at all.  For people who have never done any programming or taken
computer science courses, I can understand how it might cause problems.

	Of course, sometimes one gets stuck in a rut or paradigm and forgets
how to leave.  This should not be confused with difficulty programming
in it, but trouble adapting to new habits.

-Dan

Re: Cool and Useful LISP for the .emacs file

[Thien-Thi Nguyen]

"Jody M. Klymak" <jklymak@coas.oregonstate.edu> writes:

> Heh, heh.  Compared to what?  Assembly code?  

  hard like a diamond, more precious than softest silk.
  shards, as you find them, but round-wound and finest-built.
  capriciously crafted, though the careless do bleed indeed.
  atomic-width knifepoint -- eval not the random seed!
  
  shift left shift right, lose the high bit: over{n,s}ight.
  store direct, load indexed, flush the cache if caught perplexed.
  pipe stall pipe stall pipe stall (is that *really* all?).
  write to set, write to clear, read as zero (i hope, i fear).
  
  betwixt the extremes the hapless human sits.
  quatrains befuddled and almost dropping to free verse.
  one generation drops its bombs on the next and forgets.
  children grow into machines and repeat the mistakes.
  
  what use is it to lovingly collect
  future junkpiles so easy to neglect?

  thi

Re: Cool and Useful LISP for the .emacs file

[Jody M. Klymak]

Hello Dan,

Dan Anderson <dan@mathjunkies.com> writes:

> 	Of course, sometimes one gets stuck in a rut or paradigm and
> forgets how to leave.  This should not be confused with difficulty
> programming in it, but trouble adapting to new habits.

My point was that the rut occupied by C, python, perl, etc is wide and
shallow compared to the rather narrow and deep rut occupied by lisp.
I'm not trying to say that lisp is a bad language, but, adapting to
new habits takes time.  Having to jump ruts is an obstacle to those of
us who do not choose to invest this time.

I wonder how many more developers there might be for emacs if it had a
more accessible programming language.  And I wonder if being wedded to
lisp will have an impact on emacs' future.  Certainly, for me, it
makes casual dilettante hacking for my own uses difficult, whereas I
can usually muddle by in a piece of perl code.  

But perhaps your sentiments are correct - maybe the litmus test of
having to learn lisp keeps out the riff-raff and leaves emacs to be
developed by the dedicated "professional programmers."  Maybe that is
why it has remained so successful and the quality of what is out
there so high.  I'm just trying to point out the point of view from a
longtime user in the trenches.  

Cheers,  Jody

Re: Cool and Useful LISP for the .emacs file

[Jesper Harder]

"Jody M. Klymak" <jklymak@coas.oregonstate.edu> writes:

> My point was that the rut occupied by C, python, perl, etc is wide
> and shallow compared to the rather narrow and deep rut occupied by
> lisp.  I'm not trying to say that lisp is a bad language, but,
> adapting to new habits takes time.

Well, languages like C or Java would be completely unsuitable as an
Emacs extension language because they're non-interactive and static.

If you couldn't extend Emacs interactively, then Emacs wouldn't really
be fundamentally different from, say, vim.

Python might be adequate.  But it's less powerful than Lisp, so in
that sense it would be a step in the wrong direction.

Re: Cool and Useful LISP for the .emacs file

[Kin Cho]

"Jody M. Klymak" <jklymak@coas.oregonstate.edu> writes:

> My point was that the rut occupied by C, python, perl, etc is wide and
> shallow compared to the rather narrow and deep rut occupied by lisp.
> I'm not trying to say that lisp is a bad language, but, adapting to
> new habits takes time.  Having to jump ruts is an obstacle to those of
> us who do not choose to invest this time.
> 
> I wonder how many more developers there might be for emacs if it had a
> more accessible programming language.  And I wonder if being wedded to
> lisp will have an impact on emacs' future.  Certainly, for me, it
> makes casual dilettante hacking for my own uses difficult, whereas I
> can usually muddle by in a piece of perl code.  


> My point was that the rut occupied by C, python, perl, etc is wide and
> shallow compared to the rather narrow and deep rut occupied by lisp.
> I'm not trying to say that lisp is a bad language, but, adapting to
> new habits takes time.  Having to jump ruts is an obstacle to those of
> us who do not choose to invest this time.
> 
> I wonder how many more developers there might be for emacs if it had a
> more accessible programming language.  And I wonder if being wedded to
> lisp will have an impact on emacs' future.  Certainly, for me, it
> makes casual dilettante hacking for my own uses difficult, whereas I
> can usually muddle by in a piece of perl code.  

I used to carry around a collection of shell, sed, awk, and perl
scripts to do various text/file/directory processing, as well as
doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
(almost) all these things in elisp.

Except for the limitation of 28 bit integers (which is about the
only time I need to drop to perl), elisp is much more powerful
and elegant.

Some of the things I wrote elisp to do include: run special
compilation commands depending on project directory, mount
loopback filesystem devices within dired, parse tcpdump output,
etc...

In short, elisp makes it possible for me to create my very own
(text-based) IDE.

> But perhaps your sentiments are correct - maybe the litmus test of
> having to learn lisp keeps out the riff-raff and leaves emacs to be
> developed by the dedicated "professional programmers."  Maybe that is
> why it has remained so successful and the quality of what is out
> there so high.  I'm just trying to point out the point of view from a
> longtime user in the trenches.  

I suspect many excellent elisp authors aren't "professional
programmers", but smart tinkerers.

-kin

Re: Cool and Useful LISP for the .emacs file

[Artur Hefczyc]

Kin Cho <kin@techie.com> writes:
> I used to carry around a collection of shell, sed, awk, and perl
> scripts to do various text/file/directory processing, as well as
> doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
> (almost) all these things in elisp.

I like this idea! I would like to use elisp as scripting language
also. However I would like to know if it is possible to use it that
way. I mean, lets assume I create elisp script to update my Linux box
system with new releases of some packages.

Is it possible to run it from command line like all other scripts,
bash, perl etc.?

I mean file script starting from:
#!/usr/bin/emacs

Or any other elisp interpreter?

Artur
-- 
Artur Hefczyc, Open Source Developer:
http://www.geotools.org/
http://generguide.sourceforge.net/
http://wttools.sourceforge.net/
http://maven-plugins.sourceforge.net/

Re: Cool and Useful LISP for the .emacs file

[Thien-Thi Nguyen]

Artur Hefczyc <DONTkobit@SPAMplusnet.MEpl> writes:

> Is it possible

google for:

  sesquicolon anagram swaby

you may try "feeling lucky".

thi

Re: Cool and Useful LISP for the .emacs file

[David Kastrup]

Artur Hefczyc <DONTkobit@SPAMplusnet.MEpl> writes:

> Kin Cho <kin@techie.com> writes:
> > I used to carry around a collection of shell, sed, awk, and perl
> > scripts to do various text/file/directory processing, as well as
> > doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
> > (almost) all these things in elisp.
> 
> I like this idea! I would like to use elisp as scripting language
> also. However I would like to know if it is possible to use it that
> way. I mean, lets assume I create elisp script to update my Linux box
> system with new releases of some packages.
> 
> Is it possible to run it from command line like all other scripts,
> bash, perl etc.?
> 
> I mean file script starting from:
> #!/usr/bin/emacs
> 
> Or any other elisp interpreter?

#!/usr/bin/emacs -batch -l


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Cool and Useful LISP for the .emacs file

[Artur Hefczyc]

David Kastrup <dak@gnu.org> writes:

>> I mean file script starting from:
>> #!/usr/bin/emacs
>> Or any other elisp interpreter?
> #!/usr/bin/emacs -batch -l

Well, it doesn't work :-(
It looks like emacs thinks that it got one parameter: "-batch -l" which
is not recognized as any valid option. I tried also to use:

#!/usr/bin/emacs --batch --script

with the same effect. Only if I will but only '--batch' option emacs
starts in batch mode, however it doesn't read the rest of script
content.

Any other ideas?

Artur
-- 
Artur Hefczyc, Open Source Developer:
http://www.geotools.org/
http://generguide.sourceforge.net/
http://wttools.sourceforge.net/
http://maven-plugins.sourceforge.net/

Re: Cool and Useful LISP for the .emacs file

[Artur Hefczyc]

Artur Hefczyc <DONTkobit@SPAMplusnet.MEpl> writes:

>> #!/usr/bin/emacs -batch -l
> Well, it doesn't work :-(
> It looks like emacs thinks that it got one parameter: "-batch -l" which
> is not recognized as any valid option. I tried also to use:
> #!/usr/bin/emacs --batch --script

At last I found it, this one works as expected:
#!/usr/bin/emacs --script

Artur
-- 
Artur Hefczyc, Open Source Developer:
http://www.geotools.org/
http://generguide.sourceforge.net/
http://wttools.sourceforge.net/
http://maven-plugins.sourceforge.net/

Re: Cool and Useful LISP for the .emacs file

[Kin Cho]

Artur Hefczyc <DONTkobit@SPAMplusnet.MEpl> writes:

> Kin Cho <kin@techie.com> writes:
> > I used to carry around a collection of shell, sed, awk, and perl
> > scripts to do various text/file/directory processing, as well as
> > doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
> > (almost) all these things in elisp.
> 
> I like this idea! I would like to use elisp as scripting language
> also. However I would like to know if it is possible to use it that
> way. I mean, lets assume I create elisp script to update my Linux box
> system with new releases of some packages.
> 
> Is it possible to run it from command line like all other scripts,
> bash, perl etc.?
> 
> I mean file script starting from:
> #!/usr/bin/emacs
> 
> Or any other elisp interpreter?

Well, the preferred way is to make a interactive defun and run it
with M-x.  That way, you can write it, debug it, and enhance it
-- all in the comfort of the emacs environment.

-kin

Re: Cool and Useful LISP for the .emacs file

[David Masterson]

>>>>> Artur Hefczyc writes:

> Kin Cho <kin@techie.com> writes:
>> I used to carry around a collection of shell, sed, awk, and perl
>> scripts to do various text/file/directory processing, as well as
>> doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
>> (almost) all these things in elisp.

> I like this idea! I would like to use elisp as scripting language
> also. However I would like to know if it is possible to use it that
> way. I mean, lets assume I create elisp script to update my Linux box
> system with new releases of some packages.

> Is it possible to run it from command line like all other scripts,
> bash, perl etc.?

> I mean file script starting from:
> #!/usr/bin/emacs

> Or any other elisp interpreter?

Given how big Emacs is, I would think that it would be best to start
emacs in background (say, from your .login) and then use something
like gnudoit or emacsclient to send your elisp to the background
Emacs.  Done correctly, I would think that it would execute your
scripts much faster, no?

-- 
David Masterson

Re: Cool and Useful LISP for the .emacs file

[Matthew Kennedy]

David Masterson <dsm@rawbw.com> writes:

>>>>>> Artur Hefczyc writes:
>

[...]

>> I like this idea! I would like to use elisp as scripting language
>> also. However I would like to know if it is possible to use it that
>> way. I mean, lets assume I create elisp script to update my Linux box
>> system with new releases of some packages.
>
>> Is it possible to run it from command line like all other scripts,
>> bash, perl etc.?
>
>> I mean file script starting from:
>> #!/usr/bin/emacs
>
>> Or any other elisp interpreter?
>
> Given how big Emacs is, I would think that it would be best to start
> emacs in background (say, from your .login) and then use something
> like gnudoit or emacsclient to send your elisp to the background
> Emacs.  Done correctly, I would think that it would execute your
> scripts much faster, no?

How about using:

,----[ C-h f dump-emacs RET ]
| dump-emacs is a built-in function.
| (dump-emacs FILENAME SYMFILE)
| 
| Dump current state of Emacs into executable file FILENAME.
| Take symbols from SYMFILE (presumably the file you executed to run Emacs).
| This is used in the file `loadup.el' when building Emacs.
| 
| You must run Emacs in batch mode in order to dump it.
`----

This way you can have your scripts compiled and dumped into a
standalone executable.  Its very fast[1].

If you don't like that, try placing the following at the top of your
emacs lisp scripts, and then chmod +x the script.

:;exec emacs --batch --no-init-file --no-site-file  --load $0 --func main $* 

Footnotes: 
[1]  http://www.emacswiki.org/cgi-bin/wiki/DumpingEmacs

-- 
Matthew Kennedy

Re: Cool and Useful LISP for the .emacs file

[Pascal Bourguignon]

David Masterson <dsm@rawbw.com> writes:

> >>>>> Artur Hefczyc writes:
> 
> > Kin Cho <kin@techie.com> writes:
> >> I used to carry around a collection of shell, sed, awk, and perl
> >> scripts to do various text/file/directory processing, as well as
> >> doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
> >> (almost) all these things in elisp.
> 
> > I like this idea! I would like to use elisp as scripting language
> > also. However I would like to know if it is possible to use it that
> > way. I mean, lets assume I create elisp script to update my Linux box
> > system with new releases of some packages.
> 
> > Is it possible to run it from command line like all other scripts,
> > bash, perl etc.?
> 
> > I mean file script starting from:
> > #!/usr/bin/emacs
> 
> > Or any other elisp interpreter?
> 
> Given how big Emacs is, I would think that it would be best to start
> emacs in background (say, from your .login) and then use something
> like gnudoit or emacsclient to send your elisp to the background
> Emacs.  Done correctly, I would think that it would execute your
> scripts much faster, no?

No.

emacs IS NOT big.

$ ls -l emacs perl
-rwxr-xr-t    1 pascal   regular   4433296 2003-11-12 19:08 emacs*
-rwxr-xr-x    1 pascal   regular   1113248 2003-11-12 19:08 perl*

emacs is already in core memory so forking additionnal emacs processes
does not cost anything significant.


Starting a script  in perl or in emacs takes the  same time. (Any time
below 0.7 s IS the same time).




#!/bin/bash
echo =================================================
time emacs -batch -no-site-file -q \
    -eval '(progn (message "Hello from emacs") (kill-emacs))'
echo =================================================
time clisp -q -ansi -norc \
    -x '(progn (format t "Hello from clisp!~%") (ext:quit))'
echo =================================================
time sbcl --noinform --noprint --sysinit /dev/null --userinit /dev/null \
    --eval '(progn (format t "Hello from sbcl!~%") (SB-EXT:QUIT))'
echo =================================================
echo '(display "Hello from scsh\n") ,exit' | bash -c 'time scsh'
echo =================================================
time perl -e 'printf "Hello from perl\n";exit'
echo =================================================
exit 0



./script-times
=================================================
Hello from emacs

real  0m0.060s
user  0m0.040s
sys   0m0.010s
=================================================
Hello from clisp!

real  0m0.023s
user  0m0.010s
sys   0m0.010s   
=================================================
Hello from sbcl!

real  0m0.024s
user  0m0.010s
sys   0m0.010s   
=================================================
Scsh 0.5.3
> Hello from scsh
#f
> 
real  0m0.076s
user  0m0.030s
sys   0m0.020s   
=================================================
Hello from perl

real  0m0.009s
user  0m0.000s
sys   0m0.000s   
=================================================




To allow the use of #! for emacs, I implemented this small wrapper:


lisp-script.c:
------------------------------------------------------------------------
/******************************************************************************
FILE:               lisp-script.c
LANGUAGE:           ANSI-C
SYSTEM:             POSIX
USER-INTERFACE:     POSIX
DESCRIPTION
    This is a simple tool that encapsulate clisp or emacs invokation as
    script interpreters.
USAGE
    Insert #!/usr/local/bin/emacs-script
    or     #!/usr/local/bin/clisp-script
    as the first line of a lisp program, and run it.
AUTHORS
    <PJB> Pascal J. Bourguignon
MODIFICATIONS
    2003-10-27 <PJB> Added SBCL.
    2002-04-06 <PJB> Creation.
BUGS
LEGAL
    GPL
    Copyright Pascal J. Bourguignon 2002 - 2003

    This file is part of lisp script tools.

    This  program is  free software;  you can  redistribute  it and/or
    modify it  under the  terms of the  GNU General Public  License as
    published by the Free Software Foundation; either version 2 of the
    License, or (at your option) any later version.

    This program  is distributed in the  hope that it  will be useful,
    but  WITHOUT ANY WARRANTY;  without even  the implied  warranty of
    MERCHANTABILITY or FITNESS FOR  A PARTICULAR PURPOSE.  See the GNU
    General Public License for more details.

    You should have received a  copy of the GNU General Public License
    along with  this program; see the  file COPYING; if  not, write to
    the Free  Software Foundation, Inc.,  59 Temple Place,  Suite 330,
    Boston, MA 02111-1307 USA
******************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sysexits.h>

#ifndef EMACS
#define EMACS "/usr/local/bin/emacs"
#endif

#ifndef CLISP
#define CLISP "/usr/local/bin/clisp"
#endif

#ifndef SBCL
#define SBCL  "/usr/local/bin/sbcl"
#endif


#ifdef MACOSX

    /* Not exactly correct. We should grab GNU dirname/basename.*/

    static const char* basename(const char* path)
    {
        const char* slash=strrchr(path,'/');
        if(slash==0){
            return(path);
        }else{
            return(slash+1);
        }
    }/*basename*/

#else
#include <libgen.h>
#endif


    const char* pname="lisp-script";

    void usage(const char* pname)
    {
        fprintf(stderr,
                "%s usage:\n"\
                "    %s -h|--help | script-file [script-arguments...]\n",
                pname,pname);
    }/*usage*/

                
int main(int argc,char** argv)
{
    int i;
    int length;
    int position;
    char* script_file=0;
    char* script_option;
    char* init_file;
    enum { emacs, clisp, sbcl } kind;

    pname=basename(argv[0]);
    if(strcmp(pname,"emacs-script")==0){
        kind=emacs;
    }else if(strcmp(pname,"clisp-script")==0){
        kind=clisp;
    }else if(strcmp(pname,"sbcl-script")==0){
        kind=sbcl;
    }else{
      lisp_script:
        fprintf(stderr,"%s: should be invoked either as emacs-script, "
                "clisp-script or sbcl-script.\n",pname);
        return(EX_USAGE);        
    }

    if((strcmp(argv[1],"-h")==0)||(strcmp(argv[1],"--help")==0)){
        usage(pname);
        return(EX_OK);
    }

    if(1<argc){
        script_file=argv[1];
    }else{
        fprintf(stderr,"%s: missing script-file argument.\n",pname);
        usage(pname);
        return(EX_USAGE);        
    }

    if(0!=access(script_file,R_OK)){
        fprintf(stderr,"Can't read script file '%s'.\n",script_file);
        return(EX_NOINPUT);
    }

    init_file=(char*)malloc(strlen(argv[0])+8);
    switch(kind){
    case emacs:
        sprintf(init_file,"%s.el",argv[0]);
        break;
    case clisp:
    case sbcl:
        sprintf(init_file,"%s.lisp",argv[0]);
        break;
    default:
        goto lisp_script;
    }

    if(0!=access(init_file,R_OK)){
        fprintf(stderr,"Can't read %s init file '%s'.\n",argv[0],init_file);
        return(EX_UNAVAILABLE);
    }

    length=0;
    for(i=1;i<argc;i++){
        length+=3+strlen(argv[i]);
    }
    script_option=(char*)malloc(length+16);
    position=0;
    position+=sprintf(script_option+position,"(script ");
    for(i=1;i<argc;i++){
        position+=sprintf(script_option+position,"\"%s\" ",argv[i]);
    }
    position+=sprintf(script_option+position,")");
    /*
    fprintf(stderr,"init_file=%s\n",init_file);
    fprintf(stderr,"script_option=%s\n",script_option);
    */

    switch(kind){
    case emacs:
        execl(EMACS,"emacs","--batch","--no-site-file","--no-init-file",
              "--load",init_file,
              "--eval",script_option,
              0);
        fprintf(stderr,"Can't execl '%s'.\n",EMACS);
        break;
    case clisp:
        execl(CLISP,"clisp","-q",
              "-i",init_file,
              "-x",script_option,
              0);
        fprintf(stderr,"Can't execl '%s'.\n",CLISP);
        break;
    case sbcl:
        execl(SBCL,"sbcl","--noinform",
              "--userinit",init_file,
              "--eval",script_option,
              0);
        fprintf(stderr,"Can't execl '%s'.\n",SBCL);
        break;
    default:
        goto lisp_script;
    }
    return(EX_UNAVAILABLE);
}/*main*/

/*** lisp-script.c                    -- 2003-10-27 22:57:16 -- pascal   ***/
------------------------------------------------------------------------


emacs-script.el:
------------------------------------------------------------------------
;;
;; elisp initialization for emacs scripts.
;; We try to install some stuff to make it more like Common-Lisp.
;; GPL

;; (add-to-list 'load-path "")

(require 'cl)


(defun script (file &rest arguments)
  "
DO:     reads the FILE, skip the first line if it begins with '#!' and   
"
  (unless (file-readable-p file)
    (error "Can't read file %S." file))
  (setq ext:*args* arguments)
  (setq *load-pathname* file)
  (setq *LOAD-PATHNAME* *load-pathname*
        EXT:*ARGS*      ext:*args*)
  (find-file file)
  (let ((buf (current-buffer)))
    (unwind-protect
        (progn
          (toggle-read-only 1)
          (goto-char (point-min))
          (if (looking-at "#!")
              (forward-line 1))
          (narrow-to-region (point) (point-max))
          (eval-buffer)
          )
      (kill-buffer buf)))
  );;script




;; Exit status from <sysexit.h>
(defconst  EX_OK           0       "successful termination")
(defconst  EX__BASE        64      "base value for error messages")
(defconst  EX_USAGE        64      "command line usage error")
(defconst  EX_DATAERR      65      "data format error")
(defconst  EX_NOINPUT      66      "cannot open input")
(defconst  EX_NOUSER       67      "addressee unknown")
(defconst  EX_NOHOST       68      "host name unknown")
(defconst  EX_UNAVAILABLE  69      "service unavailable")
(defconst  EX_SOFTWARE     70      "internal software error")
(defconst  EX_OSERR        71      "system error (e.g., can't fork)")
(defconst  EX_OSFILE       72      "critical OS file missing")
(defconst  EX_CANTCREAT    73      "can't create (user) output file")
(defconst  EX_IOERR        74      "input/output error")
(defconst  EX_TEMPFAIL     75      "temp failure; user is invited to retry")
(defconst  EX_PROTOCOL     76      "remote error in protocol")
(defconst  EX_NOPERM       77      "permission denied")
(defconst  EX_CONFIG       78      "configuration error")
(defconst  EX__MAX         78      "maximum listed value")


(defun ext:exit (&optional status)
  "
DO:     stops the script, exiting with the given status.
"
  (unless status (setq status EX_OK))
  (kill-emacs status)
  );;ext:exit


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Common-Lisp / Elisp 

(defun read-line (&optional input-stream eof-error-p eof-value recursive-p)
  "
DO:     Implement partially Common-Lisp read-line function.
"
  (unless input-stream (setq input-stream standard-input))
  (let ( (standard-input input-stream)
         (line nil)
         (char (read-char)) )
    (while (not (member char '(10 13)))
      (push char line)
      (setq char (read-char)) )
    (funcall 'concat  (nreverse line))
    );;let
  );;read-line



(defalias 'EXT:EXIT  'ext:exit)
(defalias 'READ-LINE 'read-line)

;;;; emacs-script.el                  -- 2003-02-08 04:35:08 -- pascal   ;;;;
------------------------------------------------------------------------





-- 
__Pascal_Bourguignon__
http://www.informatimago.com/

Re: Cool and Useful LISP for the .emacs file

[Artur Hefczyc]

Pascal Bourguignon <spam@thalassa.informatimago.com> writes:
>> > Kin Cho <kin@techie.com> writes:
>> >> I used to carry around a collection of shell, sed, awk, and perl
>> >> scripts to do various text/file/directory processing, as well as
>> >> doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
>> >> (almost) all these things in elisp.
>> > I like this idea! I would like to use elisp as scripting language
>> > also. However I would like to know if it is possible to use it that
>> > way. I mean, lets assume I create elisp script to update my Linux box
>> > system with new releases of some packages.
>> > Is it possible to run it from command line like all other scripts,
>> > bash, perl etc.?
>> > I mean file script starting from:
>> > #!/usr/bin/emacs
>> > Or any other elisp interpreter?
>> Given how big Emacs is, I would think that it would be best to start
>> emacs in background (say, from your .login) and then use something
>> like gnudoit or emacsclient to send your elisp to the background
>> Emacs.  Done correctly, I would think that it would execute your
>> scripts much faster, no?
> No.
> emacs IS NOT big.
> $ ls -l emacs perl
> -rwxr-xr-t    1 pascal   regular   4433296 2003-11-12 19:08 emacs*
> -rwxr-xr-x    1 pascal   regular   1113248 2003-11-12 19:08 perl*
> emacs is already in core memory so forking additionnal emacs processes
> does not cost anything significant.
> Starting a script  in perl or in emacs takes the  same time. (Any time
> below 0.7 s IS the same time).
> <snip>

Thank you all for your comments. They are very valuable for me.
I am emacs user for many years but not an expert of elisp or any other
Lisp implementation.
So I don't care whether it is efficient or not, fast or slow, I just
want to learn lisp and become good in it. Therefore I want to start
using it whenever possible.

At the moment, with emacs-cvs ver. 21.3.50 using emacs as script
interpreter is pretty easy without any additional tricks. Just put to
your first line of script file:

#!/use/bin/emacs --script

;; And after that you can use regular elisp code:
(princ "Hello world!")
;; end.

Of course it doesn't work with earlier versions and does _not_ work
construction presented below:

#!/use/bin/emacs --batch -l $0

because for some reason emacs thinks that the whole parameter string:
"--batch -l $0" is one option - unknown for him.

Artur
-- 
Artur Hefczyc, Open Source Developer:
http://www.geotools.org/
http://generguide.sourceforge.net/
http://wttools.sourceforge.net/
http://maven-plugins.sourceforge.net/

Re: Cool and Useful LISP for the .emacs file

[Tim X]

>>>>> "Artur" == Artur Hefczyc <DONTkobit@SPAMplusnet.MEpl> writes:

 Artur> Kin Cho <kin@techie.com> writes:
 >> I used to carry around a collection of shell, sed, awk, and perl
 >> scripts to do various text/file/directory processing, as well as
 >> doing cvs/rcs stuff, running compilation and gdb etc...  Now I do
 >> (almost) all these things in elisp.

 Artur> I like this idea! I would like to use elisp as scripting
 Artur> language also. However I would like to know if it is possible
 Artur> to use it that way. I mean, lets assume I create elisp script
 Artur> to update my Linux box system with new releases of some
 Artur> packages.

 Artur> Is it possible to run it from command line like all other
 Artur> scripts, bash, perl etc.?

 Artur> I mean file script starting from: #!/usr/bin/emacs

 Artur> Or any other elisp interpreter?

 Artur> Artur -- Artur Hefczyc, Open Source Developer:
 Artur> http://www.geotools.org/ http://generguide.sourceforge.net/
 Artur> http://wttools.sourceforge.net/
 Artur> http://maven-plugins.sourceforge.net/

For this sort of thing, I'd be tempted to just use lisp, not emacs
lisp. There are numerous lisp implementations which will allow you to
do this sort of thing. 

The thing about elisp is that its got lots of things which are useful
when dealing with text, buffers, displays characters etc. However, its
not as good as a general lisp if you want ot do more general stuff. 

Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!

Re: Cool and Useful LISP for the .emacs file

[Joe Fineman]

"Jody M. Klymak" <jklymak@coas.oregonstate.edu> writes:

> But perhaps your sentiments are correct - maybe the litmus test of
> having to learn lisp keeps out the riff-raff and leaves emacs to be
> developed by the dedicated "professional programmers."

Alas, it doesn't always work.  I am a nonprogrammer, and Elisp is the
only programming language I have ever used, unless you count some
youthful hacks in Basic.

Riffraffishly,
-- 
---  Joe Fineman    jcf@TheWorld.com

||:  Masochist:  "Hurt me!"  :||
||:  Sadist:  "No."          :||

Re: Cool and Useful LISP for the .emacs file

[Stefan Monnier]

> My point was that the rut occupied by C, python, perl, etc is wide and
> shallow compared to the rather narrow and deep rut occupied by lisp.

Seeing how much trouble you seem to have getting from your C rut to
elisp's, I have a hard time understanding why you consider the C rut as
being wide and shallow.

I still haven't heard from a Lisp hacker who found it difficult to switch to
C or Java (painful, yes of course, but not difficult, except maybe for manual
memory management), so I'd say that Lisp's rut is rather shallow indeed.


        Stefan

Re: Cool and Useful LISP for the .emacs file

[Thien-Thi Nguyen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Lisp's rut is rather shallow indeed.

the confusion lies in the concept of "rut" as a directional gouging of
the mud (that is, one's mental makeup ;-).  lisp's gouging is shallow or
deep depending on the softness of the mud, but more importantly, it is
expansive, so much so that it engulfs mere 1d ruts in its 2d nature.

you pour effort into other languages and pox-ridden sewer grot emerges,
you pour effort into lisp and the field of wildflowers grows.

thi

Re: Cool and Useful LISP for the .emacs file

[Burton Samograd]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> My point was that the rut occupied by C, python, perl, etc is wide and
>> shallow compared to the rather narrow and deep rut occupied by lisp.
>
> Seeing how much trouble you seem to have getting from your C rut to
> elisp's, I have a hard time understanding why you consider the C rut as
> being wide and shallow.
>
> I still haven't heard from a Lisp hacker who found it difficult to switch to
> C or Java (painful, yes of course, but not difficult, except maybe for manual
> memory management), so I'd say that Lisp's rut is rather shallow indeed.

>From my experience, switching to lisp is a bit more work than the
other way around, due to the type of people that helped shape lisp in
the first place.  C and UNIX were developed around the "worse is
better" type philosophy, where LISPy systems were more focused on the
consistent and perfect side.  Each philosophy has it's advantages, but
the perfect side has the drawback of having to learn idiosyncratic
perfections, rather than diving in and just doing something.  Current
operating systems have evolved from the experience and knowledge of
UNIX systems, where Common Lisp evolved from the now defunct LISP
machines of the 80's.  Emacs seems one of the last bastions of LISP
being found in production work (there are exceptions, but they aren't
heard of them that much anymore), and even still it's not part of the
production process and lies in the users own desire and drive to
learn, which requires un-learning many things before the power and
beauty of lisp can be fully realized.

For the ones that want to attack the LISP learning curve there are
plenty of resources available from the existing LISP community, but
don't expect much help if you dive in and start telling them thier
language should be changed because you "don't get it".  LISP is great
and LISP is fun, but it's still a programming language, but much more
akin to a sketchbook than a paintroller.  Sketching is quite fun, but
with lisp the finalization of programs (such as for relesase) can be
obscure and won't be found with much research, guidance and the
ability to accept things how they are, at least for the time being.

My 2cents based on my research, 

-- 
burton samograd
http://kruhftwerk.dyndns.org

Re: Cool and Useful LISP for the .emacs file

[Alan Mackenzie]

Burton Samograd <kruhft@hotmail.com> wrote on Mon, 10 Nov 2003 21:00:03
GMT:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I still haven't heard from a Lisp hacker who found it difficult to
>> switch to C or Java (painful, yes of course, but not difficult, except
>> maybe for manual memory management), so I'd say that Lisp's rut is
>> rather shallow indeed.

> From my experience, switching to lisp is a bit more work than the other
> way around, due to the type of people that helped shape lisp in the
> first place.  C and UNIX were developed around the "worse is better"
> type philosophy, where LISPy systems were more focused on the
> consistent and perfect side.

All due respect, and everything, but the above is incoherent nonsense.
"Worse is better"?  What's that supposed to mean?  "..due to the type of
people that helped shape lisp"?  That seems disparaging.  What have
personalities got to do with the difficulties of learning a new
programing language?

[ .... ]

> For the ones that want to attack the LISP learning curve there are
> plenty of resources available from the existing LISP community, but
> don't expect much help if you dive in and start telling them their
> language should be changed because you "don't get it".  LISP is great
> and LISP is fun, but it's still a programming language, but much more
> akin to a sketchbook than a paintroller.

A "pain troller".  What a strange concept!  Such posters are, thankfully,
not common on gnu.emacs.help, but they are regretfully abundant elsewhere
on Usenet.  :-(

> -- 
> burton samograd
> http://kruhftwerk.dyndns.org

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Re: Cool and Useful LISP for the .emacs file

[Jesper Harder]

Alan Mackenzie<none@example.invalid> writes:

> Burton Samograd <kruhft@hotmail.com> wrote:
>
>> From my experience, switching to lisp is a bit more work than the other
>> way around, due to the type of people that helped shape lisp in the
>> first place.  C and UNIX were developed around the "worse is better"
>> type philosophy, where LISPy systems were more focused on the
>> consistent and perfect side.
>
> All due respect, and everything, but the above is incoherent nonsense.
> "Worse is better"?  What's that supposed to mean?

It's an expression coined by Richard P. Gabriel (a Lisp hacker) while
trying to explain why C and Unix became so popular even though they
(in his view) were technically inferior to The Right Thing, i.e. Lisp.

See

    <http://www.dreamsongs.com/WorseIsBetter.html>

for more details.

Re: Cool and Useful LISP for the .emacs file

[Burton Samograd]

Jesper Harder <harder@myrealbox.com> writes:
> Alan Mackenzie<none@example.invalid> writes:
>> All due respect, and everything, but the above is incoherent nonsense.
>> "Worse is better"?  What's that supposed to mean?
>
> It's an expression coined by Richard P. Gabriel (a Lisp hacker) while
> trying to explain why C and Unix became so popular even though they
> (in his view) were technically inferior to The Right Thing, i.e. Lisp.
>
> See
>
>     <http://www.dreamsongs.com/WorseIsBetter.html>
>
> for more details.

Thanks for the clarification; I thought that paper was more widely
known.  Although the wording of the sentance is a bit inflammitory
without reference, I happen to find that it's closer to the way the
world works than being technically perfect (better translated as
academic).  In the end I'm still using a "worse" UNIX based OS, while
the LISP machines have faded into history (although many of the ideas
still live on inside of emacs).

-- 
burton samograd
http://kruhftwerk.dyndns.org

Re: Cool and Useful LISP for the .emacs file

[Burton Samograd]

Alan Mackenzie<none@example.invalid> writes:

> Burton Samograd <kruhft@hotmail.com> wrote on Mon, 10 Nov 2003 21:00:03
> GMT:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I still haven't heard from a Lisp hacker who found it difficult to
>>> switch to C or Java (painful, yes of course, but not difficult, except
>>> maybe for manual memory management), so I'd say that Lisp's rut is
>>> rather shallow indeed.
>
>> From my experience, switching to lisp is a bit more work than the other
>> way around, due to the type of people that helped shape lisp in the
>> first place.  C and UNIX were developed around the "worse is better"
>> type philosophy, where LISPy systems were more focused on the
>> consistent and perfect side.
>
> All due respect, and everything, but the above is incoherent nonsense.
> "Worse is better"?  What's that supposed to mean?  "..due to the type of
> people that helped shape lisp"?  That seems disparaging.  What have
> personalities got to do with the difficulties of learning a new
> programing language?


Another poster replied as to what "Worse is better" was refering to.
Just because you haven't heard of something doesn't make it nonsense.
As a hint, when you're wondering what something is supposed to mean,
rather than do an instant-flame, try googling.
 
Also, try hanging out in comp.lang.lisp for a while where you'll get
to hear discussions and talk with the people that helped form the CL
standard.  There are some very smart people that have some very good
reasons for why things are the way they are in the lisp world and
their personalities have *a lot* to do with it.  They have a knowledge
base of many years of experience that they have incorporated into the
Lisp standard, and it takes almost as long to learn all the nuances. 

This is part of the difficulty where people that are new to something
find it different to what they are used to so they feel a need to
change it to something more like what they are comfortable with rather
than learning why it was done that way in the first place.  

>
> [ .... ]
>
>> For the ones that want to attack the LISP learning curve there are
>> plenty of resources available from the existing LISP community, but
>> don't expect much help if you dive in and start telling them their
>> language should be changed because you "don't get it".  LISP is great
>> and LISP is fun, but it's still a programming language, but much more
>> akin to a sketchbook than a paintroller.
>
> A "pain troller".  What a strange concept!  Such posters are, thankfully,
> not common on gnu.emacs.help, but they are regretfully abundant elsewhere
> on Usenet.  :-(

That's "paint roller"; sorry for missing a space.  I figured that most
posters like yours were a bit less abundant in these groups...I was
just sharing my thoughts on a programming language.

-- 
burton samograd
http://kruhftwerk.dyndns.org

Re: Cool and Useful LISP for the .emacs file

[Alan Mackenzie]

Burton Samograd <kruhft@hotmail.com> wrote on Tue, 11 Nov 2003 17:00:06
GMT:
> Alan Mackenzie<none@example.invalid> writes:

>> Burton Samograd <kruhft@hotmail.com> wrote on Mon, 10 Nov 2003 21:00:03
>> GMT:

>>> From my experience, switching to lisp is a bit more work than the
>>> other way around, due to the type of people that helped shape lisp in
>>> the first place.  C and UNIX were developed around the "worse is
>>> better" type philosophy, where LISPy systems were more focused on the
>>> consistent and perfect side.

>> All due respect, and everything, but the above is incoherent nonsense.
>> "Worse is better"?  What's that supposed to mean?  "..due to the type
>> of people that helped shape lisp"?  That seems disparaging.  What have
>> personalities got to do with the difficulties of learning a new
>> programing language?

> Another poster replied as to what "Worse is better" was refering to.
> Just because you haven't heard of something doesn't make it nonsense.
> As a hint, when you're wondering what something is supposed to mean,
> rather than do an instant-flame, try googling.

Apologies.

[ .... ]

> -- 
> burton samograd
> http://kruhftwerk.dyndns.org

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Re: Cool and Useful LISP for the .emacs file

[Oliver Scholz]

Dan Anderson <dan@mathjunkies.com> writes:

[...]
> For most professional programmers learning LISP should not be hard
> at all. For people who have never done any programming or taken
> computer science courses, I can understand how it might cause
> problems.

I firmly disagree.  Emacs Lisp was my first programming language and
I do not recall having any troubles learning it which I could
justifiedly attribute to the language.

On the contrary the (mostly) uniform and very simple syntax of Lisp
makes it very easy for a beginner. You may simply forget about the
syntax, once you understood the meaning of `'', and concentrate on the
much more important and much more difficult task of learning how to
program. Without having to struggle with semicolons and operator
precedence or whatever.

After all, by definition a beginner had no prior exposure to a pure
imperative, semicolon-driven language.

Lisp is very friendly especially for beginners.

    Oliver

PS: I would also like to note that copying and yanking only half
understood Lisp snippets may also be a good first step into learning
Emacs Lisp.
-- 
18 Brumaire an 212 de la Révolution
Liberté, Egalité, Fraternité!

Re: Cool and Useful LISP for the .emacs file

[Orm Finnendahl]

Am 08. November 2003, 11:15 Uhr (+0100) schrieb Oliver Scholz:
>
> Lisp is very friendly especially for beginners.

I agree. I had quite some problems learning Lisp *because* I was quite
fluent in imperative languages and used to be amazed reading about
lisp being easy to learn until I started teaching it by myself to
complete novices. They don't have any problems whatsoever. It is
amazing how fast they progress even with tricky tasks. Without any
doubt Lisp and especially scheme are very friendly to beginners and
would be my first choice for teaching programming.

I wouldn't start with emacs lisp for the tricky parts concerning
emacs, though.

--
Orm

Re: Cool and Useful LISP for the .emacs file

[Ole Laursen]

"Jody M. Klymak" <jklymak@coas.oregonstate.edu> writes:

[...]

> I personally find lisp quite difficult.  The opportunities to code in
> it are few and far enough between, and the syntax so different from
> any other modern language, that I have a one-day overhead just to
> spool up to the point where I can do even the simplest thing.  And
> thus the coding opportunities get even fewer and further between, and
> the cycle spirals to the point where I am dependent on the good nature
> of package maintainers to tweak what I want.
> 
> This must limit the base of emacs coders.

Lisp was once very hot, and Emacs was started in eighties. I think you
are underestimating the number of people on Unix who know Lisp. It is
still being taught in many computer science classes.

If you find Emacs Lisp confusing, you could try learning Scheme first.
Scheme is a very small Lisp dialect.

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/

Re: Cool and Useful LISP for the .emacs file

[Tim X]

>>>>> "Jody" == Jody M Klymak <jklymak@coas.oregonstate.edu> writes:

 Jody> Hi Dan,

 Jody> Dan Anderson <dan@mathjunkies.com> writes:

 Jody> [snip much good advice...]

 >> Learning LISP is not hard...

 Jody> Heh, heh.  Compared to what?  Assembly code?

 Jody> I personally find lisp quite difficult.  The opportunities to
 Jody> code in it are few and far enough between, and the syntax so
 Jody> different from any other modern language, that I have a one-day
 Jody> overhead just to spool up to the point where I can do even the
 Jody> simplest thing.  And thus the coding opportunities get even
 Jody> fewer and further between, and the cycle spirals to the point
 Jody> where I am dependent on the good nature of package maintainers
 Jody> to tweak what I want.

 Jody> This must limit the base of emacs coders.

 Jody> Despite this, of course, there are many wonderful packages
 Jody> written for emacs.  It causes me to wonder if this is despite
 Jody> lisp or in some way because of it.

Wow, that sounds familiar. I found the same thing, at first. However,
after investing considerable time I now *think* I see the light at the
end of the tunnel. 

to some extent, I think its harder to get your head around lisp when
you come form a background of more procedural type languages such as
C. Those starting with lisp rather than moving to it from another
language seem to have an easier time. It think its because lisp (and
elisp) represent a totally different way of thinking about problems,
coding the solutions and debugging. 

While I still class myself as very much a novice with elisp, I am at
last beginning to see some of the elegance and find my own solutions
are beginning to reflect my shift to a more elisp/lisp approach. Once
you get there, you begin to find its very quick compard to languages
like C. Now, I'm less hesitant when I come across something which
doesn't quite work the way I like it and often find myself stunned by
how few lines and how easily I can modify or add some functionality. 

I've even started prototyping some of my ideas in lisp and if
applicable elisp. then, if the idea seems to bare fruit and I want to
apply it to some project I'm doing in another language, I recode it in
that language. this is very enlightening as you begin to see how some
things are very simple to do in lisp and much more complicated or time
consuming to do in C or some other language. 

the thing I'm really pleased about is I believe my C coding, scripting
and work I do generally has improved - solutions/algorithims seem to
be clearer and to me, more elegant.

While it does take time, I think there is a lot to recommend
lisp/elisp for both coding and learning.

Tim
-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!

Re: Cool and Useful LISP for the .emacs file

[Kai Grossjohann]

"Jody M. Klymak" <jklymak@coas.oregonstate.edu> writes:

> I personally find lisp quite difficult.  The opportunities to code in
> it are few and far enough between, and the syntax so different from
> any other modern language, that I have a one-day overhead just to
> spool up to the point where I can do even the simplest thing.

I guess it's not that bad.  Lisp, especially the Emacs Lisp dialect,
is quite a small language.  It can be learned quickly.  Of course,
actually using Emacs Lisp requires you to also learn the "standard
library", which is really huge.  But once you have learned the basic
language, you never have to struggle with the syntax again.  And in
Lisp, there is not much syntax to speak of.

And I find that after not using Emacs Lisp for a while, I just need
the confidence to think that the standard library function is already
there -- then a bit of persistence with M-x apropos RET or index
search in the info file will get me there ;-)

Kai

Re: Cool and Useful LISP for the .emacs file

[Reiner Steib]

On Thu, Nov 06 2003, Dan Anderson wrote:

> http://www.emacswiki.org/cgi-bin/wiki/DotEmacs

|   (put 'narrow-to-region 'disabled nil)

I don't think it's a good idea to recommend this to users who probably
aren't aware what this means.  They will never find `widen', I guess,
and believe that they lost all text outside the region.

|   (setq require-final-newline 'query)

Hm, it works, but maybe it should be "ask", see `files.el'.

| Additional `C-x LETTER' key bindings for useful commands (notice
| uppercase LETTER):

`C-x LETTER' is not reserver for users, better use `C-c LETTER'.

| Turn on Mouse Wheel Scrolling:
| 
|   ;; turn on mouse wheel scrolling
|   (defun sd-mousewheel-scroll-up (event)

What's wrong with `mouse-wheel-mode'?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Cool and Useful LISP for the .emacs file

[lawrence mitchell]

Reiner Steib wrote:

[...]

> |   (setq require-final-newline 'query)

> Hm, it works, but maybe it should be "ask", see `files.el'.

Whilst the defcustom form for REQUIRE-FINAL-NEWLINE has 'ask in
it, note the docstring:

| Non-nil but not t says ask user whether to add a newline when
| there isn't one.  nil means don't add newlines.

Note also this code from BASIC-SAVE-BUFFER:

| (or (eq require-final-newline t)
|     (and require-final-newline
|          (y-or-n-p
|           (format "Buffer %s does not end in newline.  Add one? "
|                   (buffer-name)))))

i.e. any non-nil but not-t value will have the same effect as
any other.  Setting it to 'ask, or 'query makes sense for
someone looking at the variable binding later.

Though (setq require-final-newline 'fnord) should work equally well.

[...]

-- 
lawrence mitchell <wence@gmx.li>

Re: Cool and Useful LISP for the .emacs file

[Reiner Steib]

On Fri, Nov 07 2003, lawrence mitchell wrote:

> Reiner Steib wrote:
>> |   (setq require-final-newline 'query)
>
>> Hm, it works, but maybe it should be "ask", see `files.el'.
>
> Whilst the defcustom form for REQUIRE-FINAL-NEWLINE has 'ask in
> it, note the docstring:
>
> | Non-nil but not t says ask user whether to add a newline when
> | there isn't one.  nil means don't add newlines.
[...]
> Though (setq require-final-newline 'fnord) should work equally well.

Yes you are right (I already said that it works, see above).  I
_thought_ that 'ask is more typical as 'query in Emacs and therefore
it's preferable to use it.  Grepping[1] the sources shows that 'query
is used two times (`checkdoc.el', `sendmail.el') and 'ask 11 times,
i.e. not so clear as I expected. ;-) Is there a coding convention for
'ask vs. 'query?

BTW, now I learned from (info "(elisp)Composite Types"), what's the
difference between (const :tag "Ask" foo) and (other :tag "Ask" foo)
in defcustom. :-)

Bye, Reiner.

[1] grep -n -e "\\(const\\|other\\).* \\(query\\|ask\\))" *.el */*.el  
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Cool and Useful LISP for the .emacs file

[Edward Dodge]

Dan Anderson <dan@mathjunkies.com> writes:

> I was wondering what other people have in their .emacs file.  I would
> like to challenge everyone to add at least one cool tip / trick to:
>
> http://www.emacswiki.org/cgi-bin/wiki/DotEmacs
>
> -Dan

My personal favorite:

   (defun autocompile nil
     "compile itself if ~/.emacs"
     (interactive)
     (if (string= (buffer-file-name) (concat default-directory ".emacs"))
         (byte-compile-file (buffer-file-name))))

   (add-hook 'after-save-hook 'autocompile)

Never byte-compile your .emacs file by hand again!   

-- 
Edward Dodge

/GNU Emacs 21.3.50.1 (powerpc-apple-darwin5.5) of 2002-10-11 on G3/

Re: Cool and Useful LISP for the .emacs file

[Stefan Monnier]

> Never byte-compile your .emacs file by hand again!   

Better yet:

    Never byte-compile your .emacs file

This way, you save disk space, time, and energy when things don't work
as expected.
Have you ever measured a speed difference between starting Emacs with
.emacs.el and with .emacs.elc ?  I strongly doubt it (unless you write
a lot of real elisp code in your .emacs which is a bad idea in the
first place).


-- Stefan

Re: Cool and Useful LISP for the .emacs file

[kgold]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > Never byte-compile your .emacs file by hand again!   
> 
> Better yet:
> 
>     Never byte-compile your .emacs file
> 
> This way, you save disk space, time, and energy when things don't work
> as expected.
> Have you ever measured a speed difference between starting Emacs with
> .emacs.el and with .emacs.elc ?  I strongly doubt it (unless you write
> a lot of real elisp code in your .emacs which is a bad idea in the
> first place).

Even better yet, use gnuserv.  Who cares how long it takes to start
when you do it twice a year.

-- 

Re: Cool and Useful LISP for the .emacs file

[Alan Mackenzie]

kgold <kgold@watson.ibm.com> wrote on 10 Nov 2003 21:17:28 GMT:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> > Never byte-compile your .emacs file by hand again!   

>> Better yet:

>>     Never byte-compile your .emacs file

>> This way, you save disk space, time, and energy when things don't work
>> as expected.
>> Have you ever measured a speed difference between starting Emacs with
>> .emacs.el and with .emacs.elc ?  I strongly doubt it (unless you write
>> a lot of real elisp code in your .emacs which is a bad idea in the
>> first place).

> Even better yet, use gnuserv.  Who cares how long it takes to start
> when you do it twice a year.

<flamebait>

Some of us actually have to pay for our electricity.  Some of us care
that leaving a computer running continuously spews carbon dioxide into
the atmosphere (fuelling global warming) and creates radioactive waste.
We switch our computers off when not in use.  I often boot my computer
several times a day.

But I don't like leaving Emacs running, even when my PC is on.  You see,
jit-lock runs continuously in the background, consuming vast amounts of
CPU usage, thus contributing even more to global warming, et al.

<\flamebait>

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Re: Cool and Useful LISP for the .emacs file

[Eli Zaretskii]

> From: Alan Mackenzie<none@example.invalid>
> Newsgroups: gnu.emacs.help
> Date: Tue, 11 Nov 2003 10:43:35 +0000
> 
> <flamebait>

You've got it ;-)

> Some of us actually have to pay for our electricity.  Some of us care
> that leaving a computer running continuously spews carbon dioxide into
> the atmosphere (fuelling global warming) and creates radioactive waste.

Power-saving settings, which can switch off almost everything during
idle time without requiring a reboot, were invented for this.

> But I don't like leaving Emacs running, even when my PC is on.  You see,
> jit-lock runs continuously in the background, consuming vast amounts of
> CPU usage, thus contributing even more to global warming, et al.

JIT-lock only eats up cycles as long as there are buffers that aren't
completely fontified; then it stops.

Re: Cool and Useful LISP for the .emacs file

[Stefan Monnier]

> Some of us actually have to pay for our electricity.  Some of us care
> that leaving a computer running continuously spews carbon dioxide into
> the atmosphere (fuelling global warming) and creates radioactive waste.
> We switch our computers off when not in use.  I often boot my computer
> several times a day.

Why not `suspend' it ?
[ Incidentally: does anybody here have experience configuring a Linux
  desktop machine to behave "a bit like a laptop" and turn off its drive
  when not used, ...
  This is not only to save power but to save my ears as well.  ]

> But I don't like leaving Emacs running, even when my PC is on.  You see,
> jit-lock runs continuously in the background, consuming vast amounts of
> CPU usage, thus contributing even more to global warming, et al.

Not continuously: only until it's all been re-font-lock'd.
And if you don't like it, you can turn off the background jit-locking
by setting jit-lock-stealth-time to nil.


        Stefan

Re: Cool and Useful LISP for the .emacs file

[Thien-Thi Nguyen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [ Incidentally: does anybody here have experience configuring a Linux
>   desktop machine to behave "a bit like a laptop" and turn off its drive
>   when not used, ...
>   This is not only to save power but to save my ears as well.  ]

check out the openbrick and similar small-form-factor systems.  i'm
happy to use the one here to work on emacs, guile, etc., even though
it's only 300MHz.  it is more silent than the ambiant noise and much
more silent than the dude twiddling the guitar waiting for the compile
to finish...

otherwise, if you have an IDE drive try "hdparam -S 1 /dev/hda".

thi

Re: Cool and Useful LISP for the .emacs file

[Lars Brinkhoff]

Thien-Thi Nguyen <ttn@glug.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > Incidentally: does anybody here have experience configuring a Linux
> > desktop machine to behave "a bit like a laptop" and turn off its drive
> > when not used, ...
> > This is not only to save power but to save my ears as well.
> if you have an IDE drive try "hdparam -S 1 /dev/hda".

Be aware that all the starting and stopping can be bad for the drive.
Listen carefully for the whining nose the drive makes when the bearings
starts to wear out, and run, don't walk, to the nearest computer hard-
ware store to buy a replacement.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

Re: Cool and Useful LISP for the .emacs file

[Colin Marquardt]

Lars Brinkhoff <lars@nocrew.org> writes:

> Thien-Thi Nguyen <ttn@glug.org> writes:
>> if you have an IDE drive try "hdparam -S 1 /dev/hda".
>
> Be aware that all the starting and stopping can be bad for the drive.

Also, mount the disks with the "noatime" option in order to prevent
unnecessary spin up.

Re: Cool and Useful LISP for the .emacs file

[David Kastrup]

Colin Marquardt <c.marquardt@alcatel.de> writes:

> Lars Brinkhoff <lars@nocrew.org> writes:
> 
> > Thien-Thi Nguyen <ttn@glug.org> writes:
> >> if you have an IDE drive try "hdparam -S 1 /dev/hda".
> >
> > Be aware that all the starting and stopping can be bad for the drive.
> 
> Also, mount the disks with the "noatime" option in order to prevent
> unnecessary spin up.

But be aware that this means periodic disk cleaning on /tmp
directories and similar for files that have not been accessed for a
certain time will then not heed how recently the files have indeed
been in use.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Cool and Useful LISP for the .emacs file

[Stefan Monnier]

> But be aware that this means periodic disk cleaning on /tmp
> directories and similar for files that have not been accessed for a
> certain time will then not heed how recently the files have indeed
> been in use.

That's OK: periodic cleaning of /tmp is braindead anyway since it can
remove a file that was not accessed for a long time but that is still
in use nevertheless.


        Stefan

Re: Cool and Useful LISP for the .emacs file

[Joe Corneli]

Gareth Rees,

>   Delete your .emacs!

How about just ditching the computer and working with pen and ink?

> This means that you can go to a new machine, run Emacs on it, and it
> works just the same as on your old machine!

Or maybe as a more moderate course, be careful to write a .emacs that
works universally?  This might be more or less challenging, but I
think it is a good goal for participants in the emacswiki .emacs
project to keep in mind.  At least say whether the code is *designed*
to work on any Emacs or whether it is hand-crafted for some specific
setup.

> And when you find a problem you know it's really to do with
> Emacs and not with some "cool" trick you copied out of someone else's
> .emacs without understanding it.

C-h k <string>  will tell you where your keystrokes are defined,
from there it shouldn't be too hard to track down the source of
the problems you find.  You can always delete code you don't 
understand if you think it is causing you trouble.  

Joe

Re: Cool and Useful LISP for the .emacs file

[Joe Corneli]

> PS: I would also like to note that copying and yanking only half
> understood Lisp snippets may also be a good first step into learning
> Emacs Lisp.

I agree with Oliver. My main learning steps (so far) were approximately
these:

writing macros |
saving them    |  ~ nine months (also learned bash)
tweaking them  |
importing Lisp snippets  |
tweaking them            | ~ eight months (bash use peaks)
writing basic defuns     |
learning some Lisp concepts              |
writing somewhat more complicated defuns | ~ six months (little bash)

Only after quite a while of writing basic defuns did I ever do
anything that might be considered to be more complicated. Also, only
after that did I begin to understand how to use built-in Emacs
functionality at all well.

Joe