handling parenthesis and quotes

handling parenthesis and quotes

[Adam]

Am using Emacs and Slime in Linux, and looked 
thru the Emacs and Elisp manuals, but so far 
haven't found how to do this trivial thing; 
to dispatch a grep line to a Lisp subprocess:- 

(shell "grep -i "(define " ~/mydir/myfile?.lisp") 

Have tried ' and \ and \: but ask how I should  
include " or ( in such a line. 

Re: handling parenthesis and quotes

[Giorgos Keramidas]

On Wed, 24 Jan 2007 09:09:13 +1300, Adam <nospam@example.com> wrote:
> Am using Emacs and Slime in Linux, and looked 
> thru the Emacs and Elisp manuals, but so far 
> haven't found how to do this trivial thing; 
> to dispatch a grep line to a Lisp subprocess:- 
>
> (shell "grep -i "(define " ~/mydir/myfile?.lisp") 
>
> Have tried ' and \ and \: but ask how I should  
> include " or ( in such a line. 

AFAIK, you can `escape' the quotes, with:

  (shell "grep -i \"(define \" ~/mydir/myfile?.lisp")

Re: handling parenthesis and quotes

[Adam]

Giorgos Keramidas wrote:

> AFAIK, you can `escape' the quotes, with:
> 
>   (shell "grep -i \"(define \" ~/mydir/myfile?.lisp")

That's got it, Giorgos.  Thank you. 
Seems I didn't escape often enough.

(shell "grep -i \"\(define \" ~/mydir/myfile?.lisp")

Re: handling parenthesis and quotes

[Harald Hanche-Olsen]

+ Adam <nospam@example.com>:

| Giorgos Keramidas wrote:
|
|> AFAIK, you can `escape' the quotes, with:
|> 
|>   (shell "grep -i \"(define \" ~/mydir/myfile?.lisp")
|
| That's got it, Giorgos.  Thank you. 
| Seems I didn't escape often enough.
|
| (shell "grep -i \"\(define \" ~/mydir/myfile?.lisp")

Much easier to use the single quote for the shell command.  It does
not need to be escaped within the emacs string (and escaping the
parenthesis seems pointless BTW):

(shell "grep -i 'define ' ~/mydir/myfile?.lisp")

Of course, sometimes shell syntax demands double quotes and then you
must escape those: as in "$foo" vs '$foo'.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell

Re: handling parenthesis and quotes

[Eli Zaretskii]

> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> Date: Wed, 24 Jan 2007 08:24:51 +0100
> |
> | (shell "grep -i \"\(define \" ~/mydir/myfile?.lisp")
> 
> Much easier to use the single quote for the shell command.

But double quotes are more portable, as the Windows shells support
them, but don't support '...' quoting.

Re: handling parenthesis and quotes

[Harald Hanche-Olsen]

+ Eli Zaretskii <eliz@gnu.org>:

|> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
|> Date: Wed, 24 Jan 2007 08:24:51 +0100
|> |
|> | (shell "grep -i \"\(define \" ~/mydir/myfile?.lisp")
|> 
|> Much easier to use the single quote for the shell command.
|
| But double quotes are more portable, as the Windows shells support
| them, but don't support '...' quoting.

Oh.  I didn't know that.  But single quotes are more portable, as es
and rc both support them, but not "...".

Er, never mind.

Oh, but I am confused now, because shell doesn't even take a command
as an argument.  Did the OP mean shell-command?  And *that* isn't
really portable either, if you wish to obsess about it, because (a) by
default it uses the user's login shell, and (b) as you pointed out,
different OSes have different kinds of shells anyhow.

In summary, if you wish to use shell-command portably on unix you need
to wrap (let ((explicit-shell-file-name "/bin/sh")) ...) around it.

(Disclaimer:  I use a CVS emacs, so that variable may not be available
on older emacsen for all I know.)

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell

Re: handling parenthesis and quotes

[Adam]

Harald Hanche-Olsen wrote:

> + Eli Zaretskii <eliz@gnu.org>:
> 
> |> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> |> Date: Wed, 24 Jan 2007 08:24:51 +0100
> |> |
> |> | (shell "grep -i \"\(define \" ~/mydir/myfile?.lisp")
> |> 
> |> Much easier to use the single quote for the shell command.
> |
> | But double quotes are more portable, as the Windows shells support
> | them, but don't support '...' quoting.
> 
> Oh.  I didn't know that.  But single quotes are more portable, as es
> and rc both support them, but not "...".
> 
> Er, never mind.
> 
> Oh, but I am confused now, because shell doesn't even take a command
> as an argument.  Did the OP mean shell-command?  And *that* isn't
> really portable either, if you wish to obsess about it, because (a) by
> default it uses the user's login shell, and (b) as you pointed out,
> different OSes have different kinds of shells anyhow.
> 
> In summary, if you wish to use shell-command portably on unix you need
> to wrap (let ((explicit-shell-file-name "/bin/sh")) ...) around it.
> 
> (Disclaimer:  I use a CVS emacs, so that variable may not be available
> on older emacsen for all I know.)

Thanks for your interest.  And the Windows or more 
general non-portable case is interesting. 

No - I just wanted a grepped list to pop up 
in my Emacs Slime *inferior-lisp* buffer, my 
user login shell works fine for this. 

A related newbie question might be, is this the 
usual approach for 'incremental programming' by 
Lisp users ?  That is; write a function, 
then append that function to a file of work 
with append-to-file ?  

This creates a file of functions that need 
to be listed from time to time. The grep thing 
works well for now. 

Perhaps that file will become a package for 
slime-set-package  slime-profile-package 
or preferably something more Emacs native. 

Am I on track with my understanding of this 
so far as 'incremental programming'?

Re: handling parenthesis and quotes

[Harald Hanche-Olsen]

+ Adam <nospam@example.com>:

| A related newbie question might be, is this the 
| usual approach for 'incremental programming' by 
| Lisp users ?  That is; write a function, 
| then append that function to a file of work 
| with append-to-file ?  

I don't know what most people do.  Incremental programming is more
about ways to build a program than about particular editing habits, I
think.

It is all about building your application bit by bit, testing as you
go, and basing your work on what went before - and occassionally going
back and redoing things when you discover that design mistakes become
a hindrance to further work.  How people save and organize their work
is probably highly individual, but appending new functions willy-nilly
to a file seems too disorganized for my taste.  Rather, I work on the
program files themselves, trying to keep related functions
together. And whenever I have written a new function or rewritten an
old one, I evaluate the defun directly from the buffer (using C-M-x).
Then I use the interaction buffer mainly to test my work.
The same method works for Common Lisp using slime.  And since slime
has facilities for making this style of work easy, I suspect something
like it is a popular method.  8-)

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell

Re: handling parenthesis and quotes

[Adam]

Understood.  Thanks for good response, Harald. 

Re: handling parenthesis and quotes

[Tim X]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> + Adam <nospam@example.com>:
>
> | A related newbie question might be, is this the 
> | usual approach for 'incremental programming' by 
> | Lisp users ?  That is; write a function, 
> | then append that function to a file of work 
> | with append-to-file ?  
>
> I don't know what most people do.  Incremental programming is more
> about ways to build a program than about particular editing habits, I
> think.
>
> It is all about building your application bit by bit, testing as you
> go, and basing your work on what went before - and occassionally going
> back and redoing things when you discover that design mistakes become
> a hindrance to further work.  How people save and organize their work
> is probably highly individual, but appending new functions willy-nilly
> to a file seems too disorganized for my taste.  Rather, I work on the
> program files themselves, trying to keep related functions
> together. And whenever I have written a new function or rewritten an
> old one, I evaluate the defun directly from the buffer (using C-M-x).
> Then I use the interaction buffer mainly to test my work.
> The same method works for Common Lisp using slime.  And since slime
> has facilities for making this style of work easy, I suspect something
> like it is a popular method.  8-)
>

This is basically the way I work as well and most people I've spoken to or
worked with on projects in elisp, CL and scheme do it this way - in fact, any
language where you have some sort of REPL. Its a nice way to work as you see
results quite quickly and don't spend time sitting around for slow makes to
complete before you can see if your small bug fix worked. 

I do tent to have an elisp working file which contains functions etc that I've
been working on that are not yet part of a bigger, more defined project.
However, often I find that my initial function spawns more functions as I
break up my code and begin to understand the problem better, so eventually, I
usually end up with related functions in a file or library. 

One aspect of working this way I really like is that the programming is more
exploratory than with other languages like C or Java. In these languages, you
(I) tend to spend a fair amount of time up front designing the system and then
coding it. IN lisp dialects, I often start with only a fairly vague idea of
what I want and the program sort of emerges from that initially vague
definition through exploration. I can't say which method works better, but I
certainly find the exploratory approach more rewarding intellectually. 

Tim

tcross (at) rapttech dot com dot au