In article <···························@stablecross.com>,
····@stablecross.com (Bob Felts) wrote:
> Is there any way to quickly comment out a block of Lisp? Something
> along the lines of #if 0 ... #endif in C?
Wrap it with #|| ... ||#
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin wrote:
> Wrap it with #|| ... ||#
you need only one bar: #| ... |#
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Barry Margolin wrote:
>
>> Wrap it with #|| ... ||#
>
> you need only one bar: #| ... |#
But you can help dumb editors to correctly font-lock the comment with
#|| ... ||# instead of #| ... |#
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
On Mon, 20 Feb 2006 22:51:57 +0100, Frank Buss <··@frank-buss.de> wrote:
> Barry Margolin wrote:
>
>> Wrap it with #|| ... ||#
>
> you need only one bar: #| ... |#
It wouldn't surprise me if Barry already knew this when you where
still in kindergarten... :)
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mon, 20 Feb 2006 15:55:55 -0500, ····@stablecross.com (Bob Felts) wrote:
> Is there any way to quickly comment out a block of Lisp? Something
> along the lines of #if 0 ... #endif in C?
#+(or)
comments out the next S-expression (which could be the next DEFUN for
example).
#|
comments out everything until |#.
<http://www.lispworks.com/documentation/HyperSpec/Body/02_dhq.htm>
<http://www.lispworks.com/documentation/HyperSpec/Body/02_dhs.htm>
Cheers,
Edi.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Mon, 20 Feb 2006 15:55:55 -0500, ····@stablecross.com (Bob Felts) wrote:
>
>> Is there any way to quickly comment out a block of Lisp? Something
>> along the lines of #if 0 ... #endif in C?
>
> #+(or)
>
> comments out the next S-expression (which could be the next DEFUN for
> example).
#-(and) does the same thing. I prefer the latter because the "-" gives
me a clue that the following sexp is "subtracted" from the code.
...Peder...
--
It's not called hacking or trial and error!
It's called rapid prototyping and extreme programming.
- Kristoffer Gleditsch
In article <··············@beto.netfonds.no>,
Peder O. Klingenberg <·····@news.klingenberg.no> wrote:
+---------------
| Edi Weitz <········@agharta.de> writes:
| > #+(or) comments out the next S-expression (which could be
| > the next DEFUN for example).
|
| #-(and) does the same thing. I prefer the latter because the "-" gives
| me a clue that the following sexp is "subtracted" from the code.
+---------------
Ditto.
Similarly, #+(and) hints that the following is "added" (included).
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
·····@news.klingenberg.no (Peder O. Klingenberg) writes:
> #-(and) does the same thing. I prefer the latter because the "-" gives
> me a clue that the following sexp is "subtracted" from the code.
I prefer #+ignore. Not quite as safe & kosher, but easier to read.
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> I prefer #+ignore. Not quite as safe & kosher, but easier to read.
I know you do. Remind me to stuff a (pushnew :ignore *features*)
somewhere in a library sometime. ;-P
...Peder...
--
It's not a bug, it's a *feature*
·····@news.klingenberg.no (Peder O. Klingenberg) writes:
> I know you do. Remind me to stuff a (pushnew :ignore *features*)
> somewhere in a library sometime. ;-P
Well, if you want your library to have an :ignore-feature, I'll be
your guest and politely ignore that library ;-P
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> ·····@news.klingenberg.no (Peder O. Klingenberg) writes:
>
>> #-(and) does the same thing. I prefer the latter because the "-" gives
>> me a clue that the following sexp is "subtracted" from the code.
>
> I prefer #+ignore. Not quite as safe & kosher, but easier to read.
> --
How about #+NIL ? Just as clear, three fewer letters, and guaranteed
to work (as far as I know).
David
--
David Trudgett
http://www.zeta.org.au/~wpower/
They were going to assist at the murder of their fathers or
grandfathers just as if they were going on a party of pleasure, or at
any rate on some quite ordinary business.
-- Leo Tolstoy, "The Kingdom of God is Within You"
David Trudgett <······@zeta.org.au.nospamplease> writes:
> Espen Vestre <·····@vestre.net> writes:
>
>> ·····@news.klingenberg.no (Peder O. Klingenberg) writes:
>>
>>> #-(and) does the same thing. I prefer the latter because the "-" gives
>>> me a clue that the following sexp is "subtracted" from the code.
>>
>> I prefer #+ignore. Not quite as safe & kosher, but easier to read.
>> --
>
> How about #+NIL ? Just as clear, three fewer letters, and guaranteed
> to work (as far as I know).
This is a FAQ.
There's a New Implementation of Lisp that's called NIL, and which has
:NIL in its *FEATURES*.
(Well, perhaps not, since it wasn't Common Lisp, but anyways...)
The only things that are guaranteed to work are: #+(or) or #-(and)
and: #-(or) or #+(and)
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
Pascal Bourguignon <······@informatimago.com> writes:
> David Trudgett <······@zeta.org.au.nospamplease> writes:
>
> > Espen Vestre <·····@vestre.net> writes:
> >
> >> ·····@news.klingenberg.no (Peder O. Klingenberg) writes:
> >>
> >>> #-(and) does the same thing. I prefer the latter because the "-" gives
> >>> me a clue that the following sexp is "subtracted" from the code.
> >>
> >> I prefer #+ignore. Not quite as safe & kosher, but easier to read.
> >> --
> >
> > How about #+NIL ? Just as clear, three fewer letters, and guaranteed
> > to work (as far as I know).
>
> This is a FAQ.
>
> There's a New Implementation of Lisp that's called NIL, and which has
> :NIL in its *FEATURES*.
>
> (Well, perhaps not, since it wasn't Common Lisp, but anyways...)
>
>
> The only things that are guaranteed to work are: #+(or) or #-(and)
> and: #-(or) or #+(and)
Well yes, but these obviously suck -- so why not just informally agree on
#+nil and be done with it?
The existence of some ANSI standard (that in all likelihood will never be
updated) doesn't preclude the possibility of developing common usage patterns
as a community that are no directly sanctioned by the standard.
'as
Alexander Schmolck <··········@gmail.com> writes:
> Pascal Bourguignon <······@informatimago.com> writes:
>
>> David Trudgett <······@zeta.org.au.nospamplease> writes:
>>
>> > Espen Vestre <·····@vestre.net> writes:
>> >
>> >> ·····@news.klingenberg.no (Peder O. Klingenberg) writes:
>> >>
>> >>> #-(and) does the same thing. I prefer the latter because the "-" gives
>> >>> me a clue that the following sexp is "subtracted" from the code.
>> >>
>> >> I prefer #+ignore. Not quite as safe & kosher, but easier to read.
>> >> --
>> >
>> > How about #+NIL ? Just as clear, three fewer letters, and guaranteed
>> > to work (as far as I know).
>>
>> This is a FAQ.
>>
>> There's a New Implementation of Lisp that's called NIL, and which has
>> :NIL in its *FEATURES*.
>>
>> (Well, perhaps not, since it wasn't Common Lisp, but anyways...)
>>
>>
>> The only things that are guaranteed to work are: #+(or) or #-(and)
>> and: #-(or) or #+(and)
>
>
> Well yes, but these obviously suck -- so why not just informally agree on
> #+nil and be done with it?
>
> The existence of some ANSI standard (that in all likelihood will never be
> updated) doesn't preclude the possibility of developing common usage patterns
> as a community that are no directly sanctioned by the standard.
Another possibility that just occured to me:
#+#:ignore whatever
Since #:ignore is uninterned, there's no way it's going to be in
*features*. Up to you whether you like the thicket of #'s.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> Another possibility that just occured to me:
>
> #+#:ignore whatever
>
> Since #:ignore is uninterned, there's no way it's going to be in
> *features*. Up to you whether you like the thicket of #'s.
Heh. Nice hack. But will it work? It happens to work in LispWorks and
MCL, I noted, but is there anything in the standard that prevents an
uninterned symbol from "naming a feature"? (E.g. suppose an
implementation does its features-check by checking for (find (intern
(symbol-name symbol-just-read) :keyword) *features*)...)
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> Another possibility that just occured to me:
>>
>> #+#:ignore whatever
>>
>> Since #:ignore is uninterned, there's no way it's going to be in
>> *features*. Up to you whether you like the thicket of #'s.
>
> Heh. Nice hack. But will it work? It happens to work in LispWorks and
> MCL, I noted, but is there anything in the standard that prevents an
> uninterned symbol from "naming a feature"? (E.g. suppose an
> implementation does its features-check by checking for (find (intern
> (symbol-name symbol-just-read) :keyword) *features*)...)
I don't see how that can be interpeted by what the spec calls for.
The notion of "present" as it applies to features in the glossary
implies identity for symbols.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> I don't see how that can be interpeted by what the spec calls for.
> The notion of "present" as it applies to features in the glossary
> implies identity for symbols.
Ah, yes, I missed the important point that the #+ reader macro is
specified to set its current package to the keyword package (2.4.8.17
in the spec)
So it's actually possible to have no-keyword *features* if you specify
their package - I learn a little Common Lisp every day....
(Maybe I should start using #+vestre.net.bogus-package::ignore just to
be safe ;-))
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> Duane Rettig <·····@franz.com> writes:
>
>> I don't see how that can be interpeted by what the spec calls for.
>> The notion of "present" as it applies to features in the glossary
>> implies identity for symbols.
>
> Ah, yes, I missed the important point that the #+ reader macro is
> specified to set its current package to the keyword package (2.4.8.17
> in the spec)
>
> So it's actually possible to have no-keyword *features* if you specify
> their package - I learn a little Common Lisp every day....
>
> (Maybe I should start using #+vestre.net.bogus-package::ignore just to
> be safe ;-))
The problem with that is then the reader will barf unless you've
created the package VESTRE.NET.BOGUS-PACKAGE. Uninterned symbols don't
have that problem.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> The problem with that is then the reader will barf unless you've
> created the package VESTRE.NET.BOGUS-PACKAGE.
Sure, I'd have to put in a require... (it was just a joke, anyway).
--
(espen)
Peter Seibel <·····@gigamonkeys.com> writes:
> Alexander Schmolck <··········@gmail.com> writes:
>
>> Pascal Bourguignon <······@informatimago.com> writes:
>>
>>> David Trudgett <······@zeta.org.au.nospamplease> writes:
>>>
>>> > Espen Vestre <·····@vestre.net> writes:
>>> >
>>> >> ·····@news.klingenberg.no (Peder O. Klingenberg) writes:
>>> >>
>>> >>> #-(and) does the same thing. I prefer the latter because the "-" gives
>>> >>> me a clue that the following sexp is "subtracted" from the code.
>>> >>
>>> >> I prefer #+ignore. Not quite as safe & kosher, but easier to read.
>>> >> --
>>> >
>>> > How about #+NIL ? Just as clear, three fewer letters, and guaranteed
>>> > to work (as far as I know).
>>>
>>> This is a FAQ.
An entry for the FAQ, Peter? Then Pascal will be able to supply the
URL... ;-)
Cheers,
David
--
David Trudgett
http://www.zeta.org.au/~wpower/
We want one class to have a liberal education. We want another class,
a very much larger class of necessity, to forego the privilege of a
liberal education and fit themselves to perform specific difficult
manual tasks.
-- U.S. President Woodrow Wilson
Pascal Bourguignon <······@informatimago.com> writes:
> David Trudgett <······@zeta.org.au.nospamplease> writes:
>
> > How about #+NIL ? Just as clear, three fewer letters, and guaranteed
> > to work (as far as I know).
>
> This is a FAQ.
>
> There's a New Implementation of Lisp that's called NIL, and which has
> :NIL in its *FEATURES*.
>
> (Well, perhaps not, since it wasn't Common Lisp, but anyways...)
Actually, NIL was a Common Lisp (CLtL1) implementation on the VAX. I
would guess that there are very few instances of it running anymore.
--
Thomas A. Russ, USC/Information Sciences Institute
Pascal Bourguignon <······@informatimago.com> writes:
> David Trudgett <······@zeta.org.au.nospamplease> writes:
>
>> Espen Vestre <·····@vestre.net> writes:
>>
>>> ·····@news.klingenberg.no (Peder O. Klingenberg) writes:
>>>
>>>> #-(and) does the same thing. I prefer the latter because the "-" gives
>>>> me a clue that the following sexp is "subtracted" from the code.
>>>
>>> I prefer #+ignore. Not quite as safe & kosher, but easier to read.
>>> --
>>
>> How about #+NIL ? Just as clear, three fewer letters, and guaranteed
>> to work (as far as I know).
>
> This is a FAQ.
You probably mean an OAQ, as in "occasionally". I myself had to do a
google search to find any such questions on c.l.l., even though I've
been attempting to follow this group for some time now.
>
> There's a New Implementation of Lisp that's called NIL, and which has
> :NIL in its *FEATURES*.
Their marketing slogan: Would you use our new, improved Lisp? NIL
And Peter Herth better get in quick with his Next Iteration of LTk! ;-)
So, anyway, that would explain why #-t doesn't work. I knew I should
have read the doc... :-)
>
> (Well, perhaps not, since it wasn't Common Lisp, but anyways...)
>
>
> The only things that are guaranteed to work are: #+(or) or #-(and)
> and: #-(or) or #+(and)
Uhmmm... those choices are unintuitive, but someone else already
pointed that out, spelling 'unintuitive' S - U - C - K - S. :-)
David
--
David Trudgett
http://www.zeta.org.au/~wpower/
The State is a soulless machine that owes its very existence to violence.
David Trudgett wrote:
> Pascal Bourguignon <······@informatimago.com> writes:
>
>
>>David Trudgett <······@zeta.org.au.nospamplease> writes:
>>
>>
>>>Espen Vestre <·····@vestre.net> writes:
>>>
>>>
>>>>·····@news.klingenberg.no (Peder O. Klingenberg) writes:
>>>>
>>>>
>>>>>#-(and) does the same thing. I prefer the latter because the "-" gives
>>>>>me a clue that the following sexp is "subtracted" from the code.
>>>>
>>>>I prefer #+ignore. Not quite as safe & kosher, but easier to read.
>>>>--
>>>
>>>How about #+NIL ? Just as clear, three fewer letters, and guaranteed
>>>to work (as far as I know).
>>
>>This is a FAQ.
>
>
> You probably mean an OAQ, as in "occasionally". I myself had to do a
> google search to find any such questions on c.l.l., even though I've
> been attempting to follow this group for some time now.
>
>
>
>>There's a New Implementation of Lisp that's called NIL, and which has
>>:NIL in its *FEATURES*.
>
>
> Their marketing slogan: Would you use our new, improved Lisp? NIL
>
> And Peter Herth better get in quick with his Next Iteration of LTk! ;-)
>
> So, anyway, that would explain why #-t doesn't work. I knew I should
> have read the doc... :-)
>
>
>
>>(Well, perhaps not, since it wasn't Common Lisp, but anyways...)
>>
>>
>>The only things that are guaranteed to work are: #+(or) or #-(and)
>>and: #-(or) or #+(and)
>
>
> Uhmmm... those choices are unintuitive, but someone else already
> pointed that out, spelling 'unintuitive' S - U - C - K - S. :-)
Well, some people take an understandable quiet pleasure in doing things
right.
I am more sloppy. I like #+nahhhh for code I decide is daft but might
stage a comeback, and #+shhhh for debugging print statements. The
package namer out to get me has to guess how many h's I used.
:)
kenny
Kenny Tilton <·············@nyc.rr.com> writes:
> I am more sloppy. I like #+nahhhh for code I decide is daft but might
> stage a comeback, and #+shhhh for debugging print statements. The
> package namer out to get me has to guess how many h's I used.
We have instances of #+notyet and #+nomore in our code.
Personally, I like a more old-lisp style car/cdr style,
like #+uhuh and #+unhuh - where the form is similar and the
only difference is a single letter.
> :)
I agree completely. C'mon, people, lighten up; this is Common
Lisp, the language of _choices_!
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> > :)
>
> I agree completely. C'mon, people, lighten up; this is Common
> Lisp, the language of _choices_!
Yes, let's not delve into devastating ideological discussions here...
This discussion reminds me somewhat of the package-definition
discussion a year or two ago. I still insist on using keywords in
package definitions - I simply find a bunch of uninterned symbols so
visually apalling (they /almost/ look like oatmeal with nail
clippings ;)) that I'd rather waste a few hundred keyword symbols. And
it does no harm.
--
(espen)
Duane Rettig wrote:
> Kenny Tilton <·············@nyc.rr.com> writes:
>
>
>>I am more sloppy. I like #+nahhhh for code I decide is daft but might
>>stage a comeback, and #+shhhh for debugging print statements. The
>>package namer out to get me has to guess how many h's I used.
>
> Personally, I like a more old-lisp style car/cdr style,
> like #+uhuh and #+unhuh - where the form is similar and the
> only difference is a single letter.
>
>>:)
Reminds me of a faculty member who used just 3 different comments in the
margins of dissertation drafts: huh, eh, and feh
Chris Riesbeck <··············@gmail.com> writes:
> Duane Rettig wrote:
>> Kenny Tilton <·············@nyc.rr.com> writes:
>>
>>>I am more sloppy. I like #+nahhhh for code I decide is daft but might
>>>stage a comeback, and #+shhhh for debugging print statements. The
>>>package namer out to get me has to guess how many h's I used.
>> Personally, I like a more old-lisp style car/cdr style,
>> like #+uhuh and #+unhuh - where the form is similar and the
>> only difference is a single letter.
>>
>>>:)
>
> Reminds me of a faculty member who used just 3 different comments in
> the margins of dissertation drafts: huh, eh, and feh
Was "eh" a sign of approval?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Chris Riesbeck wrote:
> Duane Rettig wrote:
>
>> Kenny Tilton <·············@nyc.rr.com> writes:
>>
>>
>>> I am more sloppy. I like #+nahhhh for code I decide is daft but might
>>> stage a comeback, and #+shhhh for debugging print statements. The
>>> package namer out to get me has to guess how many h's I used.
>>
>>
>> Personally, I like a more old-lisp style car/cdr style,
>> like #+uhuh and #+unhuh - where the form is similar and the
>> only difference is a single letter.
>>
>>> :)
>
>
> Reminds me of a faculty member who used just 3 different comments in the
> margins of dissertation drafts: huh, eh, and feh
I believe it was the legendary Harold Ross of the New Yorker who used
something I sometimes flag my code with for future review: "m/b" for
"make better".
:)
kenny
Bob Felts wrote:
> Is there any way to quickly comment out a block of Lisp? Something
> along the lines of #if 0 ... #endif in C?
Put your cursor at the start of the block and hit C-SPACE (mark).
Go to the end of the block and hit M-x comment-region.
Aloha,
David Sletten
In article <·····················@tornado.socal.rr.com>,
David Sletten <·····@slytobias.com> wrote:
> Bob Felts wrote:
> > Is there any way to quickly comment out a block of Lisp? Something
> > along the lines of #if 0 ... #endif in C?
>
> Put your cursor at the start of the block and hit C-SPACE (mark).
> Go to the end of the block and hit M-x comment-region.
That won't work right if there are extra close parens on the last line,
e.g.
(progn
(do-something)
(do-another-thing)
(do-final-thing))
If you use comment-region to comment out (do-final-thing), you have to
remember to move the second close paren to the next line, or you'll end
up with mismatching parens.
While I'm firmly wedded to the traditional parenthesis style, this can
be one argument for the C-style parentheses:
(progn
(do-something)
(do-another-thing)
(do-final-thing)
)
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
In article <····························@comcast.dca.giganews.com>,
Barry Margolin <······@alum.mit.edu> wrote:
> [M-x comment-region] won't work right if there are extra close parens
> on the last line, e.g.
>
> (progn
> (do-something)
> (do-another-thing)
> (do-final-thing))
>
> If you use comment-region to comment out (do-final-thing), you have to
> remember to move the second close paren to the next line, or you'll end
> up with mismatching parens.
My copy of Emacs seems to do the right thing and moves the parens on its
own.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
On Tue, 21 Feb 2006 08:57:00 GMT, Brian Downing <·············@lavos.net> wrote:
> In article <····························@comcast.dca.giganews.com>,
> Barry Margolin <······@alum.mit.edu> wrote:
>> [M-x comment-region] won't work right if there are extra close
>> parens on the last line, e.g.
>>
>> (progn
>> (do-something)
>> (do-another-thing)
>> (do-final-thing))
>>
>> If you use comment-region to comment out (do-final-thing), you have
>> to remember to move the second close paren to the next line, or
>> you'll end up with mismatching parens.
>
> My copy of Emacs seems to do the right thing and moves the parens on
> its own.
But if the second close paren was part of the region you marked and
your Emacs didn't comment it, then `comment-region' didn't do what you
asked it for. Is that really the right thing? A bit too DWIM-ish for
my taste.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
> But if the second close paren was part of the region you marked and
> your Emacs didn't comment it, then `comment-region' didn't do what you
> asked it for. Is that really the right thing? A bit too DWIM-ish for
> my taste.
I think David Sletten meant to press C-M-SPC (`mark-sexp'), which
will put the mark just after the first closing paren. The second
closing paren is not inside the region then.
if you are not gonna use the block of lisp for a while and the block is
fairly large and you use emacs and folding.el i would suggest you make
a folding block around the code and use M-x folding-comment-fold or
your folding-prefix-code plus ; . This has the additional benifit of
getting the code out of your view. Uncommenting the code is done by
giving folding-comment-fold a prefix value, and it doesnt have a
shortcut, so i would suggest making your own emacs function for that
one and bind it. say:
(defun fold-uncomment ()
(interactive)
(folding-comment-fold 1))
(folding-kbd "'" 'fold-uncomment)
Ties