From nikodemus at random-state.net  Thu Dec 15 12:48:36 2005
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Thu, 15 Dec 2005 12:48:36 +0000
Subject: [climacs-devel] Per-pane command-tables?
Message-ID: <87bqzittjv.fsf@j178.myrootshell.com>

Is there a way to associate command-tables with pane-classes? (If this
is more properly asked on mcclim-devel I'll do so.)

The reason I'm asking is that I'd like to make eg. arrow-keys work in
a typeout-pane for scrolling around, and I'd rather not test with
buffer-pane-p in the command definitions.

Also, climacs user manual chap. 9. refers to a proposal to change
buffer/pane relations. Is this done already?

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."


From splittist at yahoo.com  Fri Dec 16 14:04:14 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Fri, 16 Dec 2005 14:04:14 +0000 (UTC)
Subject: [climacs-devel] Re: Per-pane command-tables?
References: <87bqzittjv.fsf@j178.myrootshell.com>
Message-ID: <loom.20051216T135141-950@post.gmane.org>

Nikodemus Siivola <nikodemus <at> random-state.net> writes:
 
> Is there a way to associate command-tables with pane-classes?

If it's not already there, it should be fairly easy to add. I think it just 
needs another indirection on find-applicable-command-table through the class 
of the pane: buffer panes will ask the syntax, typeouts won't.

> Also, climacs user manual chap. 9. refers to a proposal to change
> buffer/pane relations. Is this done already?

No. I got most of the way there, and hit problems/got distracted/had to work.

The idea was this:

A climacs application-frame has:
o A minibuffer
o One or more windows
o One or more panes

A window is a combination of a pane and an associated info-pane (info-pane 
= 'mode-line')

A pane might have an associated buffer. More than one pane might be associated 
with the same buffer, but each pane will have its own point, mark etc. A pane 
might be associated with NO buffer, if it is a help pane or some other kind of 
user feedback.

With this scheme, a nubmer of the buffer commands from emacs become, 
naturally, pane commands (Switch To Pane, Next Pane, Kill Pane etc.).

My approach on a Switch Pane was to leave the window constellations where they 
were but disown the exisiting pane and adopt a new pane into the 
constellation, changing the info-pane's master-pane slot to point to the new 
pane.

Here is a description of what I did, based on a diff printout of a couple of 
months (!) ago that I exceptionally have lying around here. I hope it is of 
some use to someone somewhere.

* make-extended-pane and make-typeout-pane functions that had the appropriate 
defaults (including command-table defaults) and essentially just did a make-
pane of the appropriate type then pushed the resulting pane on the front of 
the (panes *application-frame*) list.

* (defmethod full-redisplay ((pane typeout-pane))) was a nop.

* a display-name gf that returned the title of a typeout-pane (set on 
creation) and, for an extended-pane, either a user-set title or an 
autogenerated one. This was to account for creating multiple panes on a single 
underlying buffer. The autogenerated name for the first pane on a buffer would 
be the buffer name, for subsequent panes something like 'foo.lisp<1>' and so 
on. A user-set title would be useful for something like 'foo.lisp pane 
defs', 'foo.lisp commands' and so on. The display-name obviously got used in 
the info-pane display, pane name completion etc.

* a typeout-table command table (intially inheriting from global-esa-table, 
help-table, base-table and window-table, but I think that needed refinement)

* a new panes slot in the climacs application-frame

* a new function buffers, called on the frame, returned a list of the extended-
panes (now, I guess, panes responding t to buffer-pane-p). This replaced the 
loop in redisplay-frame-panes :around, so that update-sytax et al. wouldn't 
get called on typeout-panes etc.

* display-info just called the new display-info-for-master gf on the master-
pane of the relevant info-pane. Different pane classes would then effectively 
have their own info-pane displays.

* a new function replace-pane called on current-pane, new-pane. This caused 
current-pane's parent to disown current-pane and adopt new-pane, and fixed the 
info-pane's master-pane slot to point to new-pane. It also caused the windows 
and panes list of the application-frame to get updated, but I never really 
ironed out the good way to do this.

* find-file function was re-engineered to talk about panes rather than buffers 
(and to include the almost identical find-file-read-only).

* presentation methods for panes paralleling those of buffers.

* other-pane and switch-to-pane functions/methods using replace-pane. 
Switching to a non-existent pane needed to do a make-buffer, a make-extended-
pane, and set the buffer of the new pane to the new buffer before switching to 
it.

* a Set Label command (see above); a Kill Pane command etc.

* make-typeout-constellation used make-typeout-pane.

* new function typeout-window-named returned an existing typeout-pane of that 
name (appropriately cleared) or created a new one.

* new List Panes command that used the above.

* make-pane-constellation used make-extended-pane.

* climacs-buffer objects no longer needed a point slot (with changes in make-
pane-constellation, initialize-instance :after ((buffer climacs-buffer)) and 
((pane climacs-pane)), and (setf buffer) :after (buffer (pane climacs-pane)).

Fun fact: if C-x B Switch To Buffer appears to work with its default argument, 
this is only by accident: the accept method does not return the default if you 
just hit return.

HTH

JQS




From strandh at labri.fr  Tue Dec 20 17:17:43 2005
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 20 Dec 2005 18:17:43 +0100
Subject: [climacs-devel] Lisp Gardeners to help Climacs
Message-ID: <17320.15543.680781.984170@serveur5.labri.fr>

Hello,

There seems to be a lot of interest in Peter Seibel's "Lisp Gardener"
project, which is a good thing if it works out as planned. 

It would be interesting for us to take advantage of this momentum to
get some help with Climacs development.  Before sending a message to
the gardener's mailing list, I think it would be appropriate to make a
list of at least half a dozen or so projects that would be suitable
for a gardener, and perhaps to try to estimate the amount of work for
each project.  

To establish such a list, I suggest we exchange some emails here with
suggestions of projects of various degrees of difficulty, and then
decide which ones to retain as gardener projects.  

I have already suggested to Peter (in the #lisp IRC channel) that I
would be willing to act as a mentor for a small number of gardeners.
I am betting that my teaching experience will come in handy here, and
I think this would be a good way to train future contributors to
Climacs and other projects. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From strandh at labri.fr  Tue Dec 20 17:49:33 2005
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 20 Dec 2005 18:49:33 +0100
Subject: [climacs-devel] suggested gardener project
Message-ID: <17320.17453.153969.909775@serveur5.labri.fr>

As a gardener project, I suggest "syntax-specific abbrevs".  Something
like this:

    The abbrev module of Climacs expands abbrevs by calling a generic
    function that typically has methods that specialize on the
    `abbrev-expander' argument.  This abstraction seem to be
    reasonable.  However, client code does not take full advantage of
    this capability.  It would be nice to have client code
    (essentially the `possibly-expand-abbrev' function) check a series
    of (at least two) abbrev expanders, say the buffer-specific one
    and a new one defined for the syntax of the buffer. 

    This would allow a user to define abbreviations specific to a
    particular natural language (by defining an
    `english-abbrev-expander') or to a particular programming
    language. 

    To demonstrate the possibilities of the abbrev abstraction, it
    would also be nice to define some more sophisticated abbrev
    expanders.  Right now, the only one used is the
    `dictionary-abbrev-expander' which maintains an alist of
    abbrev/expansion pairs.  It would be interesting to define one
    for Lisp that uses the SLIME algorithm for expanding things like
    m-v-b to multiple-value-bind.  

    The current dictionary-abbrev-expander is not terribly efficient
    due to the use of a simple alist.  Using a hash table instead
    would be an improvement. 

    As a minor point, the `possibly-expand-abbrev' function should be
    moved out of the abbrev module, so that the abbrev module becomes
    independent of Climacs. 

What do you think?
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From strandh at labri.fr  Tue Dec 20 18:10:49 2005
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 20 Dec 2005 19:10:49 +0100
Subject: [climacs-devel] another gardener project
Message-ID: <17320.18729.430835.345360@serveur5.labri.fr>

Here is another:

   Climacs is one of several CLIM applications (Closure, Clouseau,
   Beirc, etc) that should eventually be mutually callable.  In order
   to make that happen, we need to settle on a collection of
   signatures that we can document as the interface for each
   application. 

   Tentatively, each application should have a package that
   corresponds to the name of the application and which contains the
   entry points to it.  Also tentatively, where reasonable, there
   should be an entry point that also has this name, and that has
   zero required arguments and a bunch of keyword arguments.  For
   Climacs, this means that we have to define a new package called
   `climacs' in which we define the existing `climacs' main entry
   point. 

   Also, for Climacs to be usable from other applications, we would
   like a few more entry points.  First, we need a `climacs:edit-file'
   entry point that takes a file name and some of the same keyword
   arguments as the main entry point.  Next, we would like an entry
   point `climacs-edit-sequence'  that takes a Common Lisp sequence of
   objects, and returns an edited sequence (probably of the same type
   as the one that was passed as an argument).  Other, less urgent,
   entry points might be useful, such as one for editing a Lisp
   function (by pretty-printing the code to a buffer?), etc. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From splittist at yahoo.com  Tue Dec 20 20:59:29 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Tue, 20 Dec 2005 21:59:29 +0100
Subject: [climacs-devel] Re: Lisp Gardeners to help Climacs
In-Reply-To: <17320.15543.680781.984170@serveur5.labri.fr>
References: <17320.15543.680781.984170@serveur5.labri.fr>
Message-ID: <43A870B1.4070806@yahoo.com>

Robert Strandh wrote:
> There seems to be a lot of interest in Peter Seibel's "Lisp Gardener"
> project, which is a good thing if it works out as planned. 
> 
> It would be interesting for us to take advantage of this momentum to
> get some help with Climacs development.

A few more tasks spring to mind (completely made up details, of course):

1. LR parser

    The lisp-syntax facility in climacs includes a mostly-general
    LR parser. Currently this has a light layer of macros that make
    it easier, but not entirely transparent, to specify a grammar.

    The purpose of this project is to (a) ex-tract the parser
    functionality from the lisp-syntax file then (b) ab-stract that
    functionality to make it easier to specify a grammar.

    This project would be suitable for 1 gardener with some knowledge
    of parsing and (perhaps) experience in using parser generators.
    There are no very advanced lisp techniques to grok, although it
    is expected that a useful knowledge of macros will be developed
    in undertaking the project.

2. Lisp indentation

    The lisp-syntax facility in climacs includes powerful indentation
    functionality (ie. the automatic and syntax-driven indentation of
    lisp forms). Because it operates on pre-parsed syntactic forms
    rather than a textual representation of the code it should (and,
    in some cases already does) outperform emacs, at least in
    correctness.

    The purpose of this project is to (a) understand the existing code,
    (b) document it, (c) add indentation rules for forms that don't
    yet have them (but see (e)), (d) provide a way for users to
    specify rules for their own forms (which may be covered by (b)),
    and (e) write the ultimate LOOP indentation rule!

    This project would be suitable for 1 to 3 gardeners with a fair
    understanding of lisp syntax -- or the ability to read the spec
    and type TAB in emacs. No knowledge of clim is required.

3. Docstrings

    Currently climacs commands have no documentation attached to them
    within the program itself. There is also no way, currently, to
    access documentation.

    The purpose of this project is to provide docstrings (or similar)
    to the commands in climacs, and, as part of that process, to
    develop a standard format for documenting commands (and, perhaps,
    variables), for presenting that information to the user, and for
    capturing, storing and retrieving that information in the system.

    This project would be suitable for 1 gardener with the ability to
    write clear user-oriented documentation. No lisp knowledge would
    be required to start; it is anticipated that considerable lisp
    (and probably clim) knowledge would be acquired by the end.

JQS


From strandh at labri.fr  Tue Dec 20 21:37:01 2005
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 20 Dec 2005 22:37:01 +0100
Subject: [climacs-devel] Re: Lisp Gardeners to help Climacs
In-Reply-To: <43A870B1.4070806@yahoo.com>
References: <17320.15543.680781.984170@serveur5.labri.fr>
	<43A870B1.4070806@yahoo.com>
Message-ID: <17320.31101.716832.32106@serveur5.labri.fr>

John Q Splittist writes:
 > A few more tasks spring to mind (completely made up details, of course):

They all look good to me.
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From splittist at yahoo.com  Fri Dec 23 10:29:10 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Fri, 23 Dec 2005 10:29:10 +0000 (UTC)
Subject: [climacs-devel] Re: Lisp Gardeners to help Climacs
References: <17320.15543.680781.984170@serveur5.labri.fr>
	<43A870B1.4070806@yahoo.com>
	<17320.31101.716832.32106@serveur5.labri.fr>
Message-ID: <loom.20051223T102022-746@post.gmane.org>

I wonder if we need to give the gardeners a bit of a blurb about what climacs 
is (and isn't), how it fits into the gardener philosophy (such as it is), and 
how to go about getting and using it?

Perhaps something along these lines (I assume it works with CMUCL):

_An Introduction To/For Climacs_

Climacs is a project to develop a Common Lisp based Emacs-like editor in [Mc]
CLIM. (See http://common-lisp.net/project/climacs/ for some not-necessarily-up-
to-date eye candy and a note on what climacs is _not_.)

But climacs is more than this. It is also:

o part of an actually-used-in-the-real-(or, at least, academic)-world 
application with genuine users - a lute tablature editor

o a complex system that raises interesting issues of design, protocol and 
architecture

o a platform for exploring the power of the clim paradigm

o an application that provides a tough challenge for its supporting subsystems 
(compilers and mcclim) ie. it regularly throws up bugs and/or performance 
issues

o part of a suite of co-operating clim-based apps that provide a full Common 
Lisp development environment - or, at least, it will be, one day (see Dwight 
Holman's clim-desktop for a good start to this: http://www.cliki.net/clim-
desktop )

o a way for Common Lisp developers to eat their own dogfood - already a few 
trailblazers are using climacs (and clim-desktop) to develop other CL apps, 
fixing bugs in or extending the functionality of climacs as they go

Climacs is not quite yet at the point where bug-reports unaccompanied by bug-
fixes are useful, but with a bit of TLC and regular tending by a few 
gardeners, there is no reason it shouldn't soon be in a state to be a sensible 
recommendation to programmers who happen to be new to Common Lisp.

We believe helping with/using climacs benefits the Common Lisp Garden more 
generally (but we would, wouldn't we? :-). By making it possible for Common 
Lisp developers to live in a fully CL environment, it encourages and enables 
continuous and incremental improvement of all the elements of that 
environment, from compilers and guis to debuggers and editors to irc clients, 
document viewers and (who knows?) media players and lisp movie makers...

We'll be suggesting a few climacs-related gardeners projects soon, but if you 
have something you want to work on, feel free to suggest it. (Suggesting 
things for others to work on is less welcome, and perhaps better directed to 
the climacs-devel mailing list.)

We also encourage you to have a play with climacs. There are instructions on 
downloading on the project page (see above (use the CVS version); you will 
need McClim http://common-lisp.net/project/mcclim/ (use the CVS version) and 
Flexichain (but this is mentioned in the INSTALL file, so you didn't need us 
to tell you that...); it's probably a good idea to do the whole clim-desktop 
thing while you're at it (see above), not least because you will get some 
interesting slime-like functionality with Swine (part of clim-desktop).). 
Climacs works with CMUCL, SBCL and OpenMCL.

JQS



From anonfunc at gmail.com  Fri Dec 23 11:57:15 2005
From: anonfunc at gmail.com (Dwight Holman)
Date: Fri, 23 Dec 2005 03:57:15 -0800
Subject: [climacs-devel] Re: Lisp Gardeners to help Climacs
In-Reply-To: <2b0819810512230342t15a8e4d1h64e988335cab1615@mail.gmail.com>
References: <17320.15543.680781.984170@serveur5.labri.fr>
	<43A870B1.4070806@yahoo.com>
	<17320.31101.716832.32106@serveur5.labri.fr>
	<loom.20051223T102022-746@post.gmane.org>
	<2b0819810512230342t15a8e4d1h64e988335cab1615@mail.gmail.com>
Message-ID: <2b0819810512230357m142be42epec9e66583ace4b8e@mail.gmail.com>

I'm new to mailing lists, and thought the email was on cl-gardeners. (Need
to redo my filters.)
Your blurb looks excellent, and I rushed to respond.

I sent this reply to the wrong list :) :

On 12/23/05, Dwight Holman <anonfunc at gmail.com> wrote:
>
> JQS Said:
> o part of a suite of co-operating clim-based apps that provide a full
> Common
>
> > Lisp development environment - or, at least, it will be, one day (see
> > Dwight
> > Holman's clim-desktop for a good start to this:
> > http://www.cliki.net/clim-desktop )
> >
> >
> I'm finding work on McCLIM apps or Climacs to be a rather fufilling way to
> read lots of Common Lisp code,
> pick some low hanging fruit, and feel generally useful.
>
> Once you learn the basic Flexichain and buffer functions,  you gain the
> ability to implement a whole bunch of useful Emacs functions and keys.
> Adding commands to the buffer you are running is quite an interesting
> experience. as well.
>
> --Dwight
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20051223/7f06d57f/attachment.html>

From nicolas.sceaux at free.fr  Sat Dec 24 13:02:43 2005
From: nicolas.sceaux at free.fr (Nicolas Sceaux)
Date: Sat, 24 Dec 2005 14:02:43 +0100
Subject: [climacs-devel] LR parser (was Re: Lisp Gardeners to help Climacs)
In-Reply-To: <43A870B1.4070806@yahoo.com> (John Q. Splittist's message of "Tue,
	20 Dec 2005 21:59:29 +0100")
References: <17320.15543.680781.984170@serveur5.labri.fr>
	<43A870B1.4070806@yahoo.com>
Message-ID: <m2r782fy18.fsf_-_@robert.local>

John Q Splittist <splittist at yahoo.com> writes:

> 1. LR parser
>
>     The lisp-syntax facility in climacs includes a mostly-general
>     LR parser. Currently this has a light layer of macros that make
>     it easier, but not entirely transparent, to specify a grammar.
>
>     The purpose of this project is to (a) ex-tract the parser
>     functionality from the lisp-syntax file then (b) ab-stract that
>     functionality to make it easier to specify a grammar.

I've made an (naive) attempt at task (a). Patch is attached, and
comments most welcome.

nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lr.patch
Type: text/x-patch
Size: 17962 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20051224/aa174c81/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lr-syntax.lisp
URL: <https://mailman.common-lisp.net/pipermail/climacs-devel/attachments/20051224/aa174c81/attachment.ksh>

From strandh at labri.fr  Sun Dec 25 19:28:43 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sun, 25 Dec 2005 20:28:43 +0100
Subject: [climacs-devel] Re: Lisp Gardeners to help Climacs
In-Reply-To: <loom.20051223T102022-746@post.gmane.org>
References: <17320.15543.680781.984170@serveur5.labri.fr>
	<43A870B1.4070806@yahoo.com>
	<17320.31101.716832.32106@serveur5.labri.fr>
	<loom.20051223T102022-746@post.gmane.org>
Message-ID: <17326.62187.905624.224230@serveur5.labri.fr>

John Q Splittist writes:
 > I wonder if we need to give the gardeners a bit of a blurb about what climacs 
 > is (and isn't), how it fits into the gardener philosophy (such as it is), and 
 > how to go about getting and using it?
 > 
 > Perhaps something along these lines (I assume it works with CMUCL):

As I already said on #lisp, I think this is a great description.
Please post it to the gardener's list. 
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From splittist at yahoo.com  Tue Dec 27 14:18:05 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Tue, 27 Dec 2005 15:18:05 +0100
Subject: [climacs-devel] Re: LR parser (was Re: Lisp Gardeners to help
	Climacs)
In-Reply-To: <m2r782fy18.fsf_-_@robert.local>
References: <17320.15543.680781.984170@serveur5.labri.fr>	<43A870B1.4070806@yahoo.com>
	<m2r782fy18.fsf_-_@robert.local>
Message-ID: <43B14D1D.1030501@yahoo.com>

Nicolas Sceaux wrote:
> John Q Splittist <splittist at yahoo.com> writes:

>>     The purpose of this project is to (a) ex-tract the parser
>>     functionality from the lisp-syntax file then (b) ab-stract that
>>     functionality to make it easier to specify a grammar.
> 
> I've made an (naive) attempt at task (a). Patch is attached, and
> comments most welcome.

Nicolas,

Do you want to continue on to part (b)? If so, do you want gardener 
help? I'm sure Robert et al would be willing to help you co-ordinate a 
team/another person if that's the way you want to go.

JQS


From nicolas.sceaux at free.fr  Tue Dec 27 16:07:10 2005
From: nicolas.sceaux at free.fr (Nicolas Sceaux)
Date: Tue, 27 Dec 2005 17:07:10 +0100
Subject: [climacs-devel] Re: LR parser
In-Reply-To: <43B14D1D.1030501@yahoo.com> (John Q. Splittist's message of "Tue,
	27 Dec 2005 15:18:05 +0100")
References: <17320.15543.680781.984170@serveur5.labri.fr>
	<43A870B1.4070806@yahoo.com> <m2r782fy18.fsf_-_@robert.local>
	<43B14D1D.1030501@yahoo.com>
Message-ID: <m27j9qttg1.fsf@robert.local>

John Q Splittist <splittist at yahoo.com> writes:

> Nicolas Sceaux wrote:
>> John Q Splittist <splittist at yahoo.com> writes:
>
>>>     The purpose of this project is to (a) ex-tract the parser
>>>     functionality from the lisp-syntax file then (b) ab-stract that
>>>     functionality to make it easier to specify a grammar.
>> I've made an (naive) attempt at task (a). Patch is attached, and
>> comments most welcome.
>
> Nicolas,
>
> Do you want to continue on to part (b)? If so, do you want gardener
> help? I'm sure Robert et al would be willing to help you co-ordinate a
> team/another person if that's the way you want to go.

I'd like to continue on part b, yes. And indeed, I need some advice on
how/what to do first (and I'd also like to hear Robert about that,
embedded language courses at ENSERB were too few ;)

1) The lexer part, ie defining lexer states, lexeme types, and LEX methods,
is well readable and understandable as it is. However, with some other
languages, you may want to define the same bits of the lexer for different
lexer states. When using lex/flex, you can say eg:
  <lexer-state1,lexer-state2>some-regex { return some-lexeme-type; }
Maybe some syntax for defining the same bits of lexing for several lexer
states would be helpful for other syntaxes.

  (with-lexer-definition (initial-lexer-state inner-block-lexer-state some-other-state)
                         some-syntax
    ...
    (define-lex-rule-by-string "\\include" (initial-lexer-state inner-block-lexer-state)
      (make-instance 'include-lexeme))
    ...)

2) The grammar definition in lisp-syntax.lisp is a bit more opaque. I've
been thinking about a syntax for defining the grammar, maybe something
like:

  (define-lisp-parser-state-rules
    ;; (new-parser-state -> parser-state parser-symbol)
    (|( form* |   -> form-may-follow left-parenthesis-lexeme)
    (|( form* |   -> |( form* |      form)
    (|( form* |   -> |( form* |      comment)
    (|( form* ) | -> |( form* |      right-parenthesis-lexeme))

  (define-lisp-parser-reductions
    ;; (parser-symbol -> parser-state lexeme :reduce-keyword [reduce-arg])
    ;; reduce according to the rule form -> ( form* )
    (complete-list-form    -> |( form* ) | t   :until-type left-parenthesis-lexeme)
    ;; reduce at the end of the buffer
    (incomplete-form-mixin -> |( form* |   nil :until-type left-parenthesis-lexeme))

nicolas


From dpeschel at eskimo.com  Wed Dec 28 23:30:35 2005
From: dpeschel at eskimo.com (Derek Peschel)
Date: Wed, 28 Dec 2005 15:30:35 -0800
Subject: [climacs-devel] More ideas for gardeners
Message-ID: <20051228153035.A960@eskimo.com>

First, does someone have a URL describing the gardener concept?  I've been
looking over the discussion but have had to pick it up from context.

If I were choosing development projects, they might be:

	- Taking advantage of Climacs's parsing to do more than just
	  coloring files.

	  So Climacs could be aware of the regular-expression language
	  and color expressions as they are being typed.  This is not
	  an earth-shattering feature but it would be nice to have,
	  and is one reason I downloaded and set up Climacs.

	  The other language used in Climacs development is LISP.
	  Of course Climacs is aware of the structure of LISP, but the
	  editing commands don't make use of it much.  I have been
	  looking for a uniform and complete set of LISP structure
	  navigation and editing commands, and a series of action
	  commands that work with a structure you have marked. 
	  Shortcut commands would avoid the marking step and work with
	  a structure around (before, after) the cursor, but they
	  don't change the basic design.

	  Although it is against Climacs's goals to be a complete
	  development environment, the combination of structure
	  editing and evaluation (or other actions) may be useful,
	  especially when working with Climacs's own source.

	  We also have two LISP syntaxes, probably with different
	  strengths and weaknesses.  Is that a good idea?

	- Personally I use an editor called jstar most of the time;
	  it uses the WordStar keystrokes.  I find them more logical
	  than Emacs's.  Rebinding all the existing Climacs commands
	  is easy.  Changing Climacs's assumptions to match jstar's
	  might be harder.  The jstar commands separate the beginning
	  of the current selection, the end of the current selection,
	  the cursor, and the stack of previous positions.  They also
	  use a quarter-plane display (no wrapped lines) and the
	  cursor movement and scrolling behave differently than in
	  Emacs.  In fact many things (blocks, files, windows,
	  searching) differ from Emacs.

	  A Climacs with few assumptions about commands would
	  be useful.  Thinking about various editors also forces
	  developers to think about use cases (something that is
	  almost completely missing from GNU Emacs).  It might also be
	  nice to allow radical key rebindings at runtime.

	  The idea of keeping data separate may also be useful when
	  editing LISP structure -- you may want to work with more
	  than a few points at the same time.
	  
	- Fixing Climacs's weak points: lack of speed, lack of
	  developer documentation, incorrect calculation of the cursor
	  position, and probably others.  I know speed conflicts with
	  the generality I mentioned just above.

I have not mastered the skill of quick programming (especially in LISP,
which I am new to) so I don't have any implementations of my ideas.
But posting ideas is still better than doing nothing.  And I'd like to know
what everyone thinks.

Thanks,

-- Derek


From amoroso at mclink.it  Thu Dec 29 08:52:54 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 29 Dec 2005 09:52:54 +0100
Subject: [climacs-devel] More ideas for gardeners
In-Reply-To: <20051228153035.A960@eskimo.com> (Derek Peschel's message of
	"Wed, 28 Dec 2005 15:30:35 -0800")
References: <20051228153035.A960@eskimo.com>
Message-ID: <87hd8sl1y1.fsf@plato.moon.paoloamoroso.it>

Derek Peschel <dpeschel at eskimo.com> writes:

> First, does someone have a URL describing the gardener concept?  I've been

See:

  CL Gardeners - Tending the Common Lisp garden
  http://www.lispniks.com/cl-gardeners/


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From wchogg at login01.hep.wisc.edu  Fri Dec 30 20:27:04 2005
From: wchogg at login01.hep.wisc.edu (Creighton Hogg)
Date: Fri, 30 Dec 2005 14:27:04 -0600 (CST)
Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings
In-Reply-To: <43B3BB46.8010807@yahoo.com>
References: <loom.20051228T143101-57@post.gmane.org>
	<Pine.LNX.4.58.0512281108230.21839@login01.hep.wisc.edu>
	<43B3BB46.8010807@yahoo.com>
Message-ID: <Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>

Hello,
so a couple of days ago I volunteered on the Lisp Gardeners 
group to work on a project involving documenting commands in 
climacs.

As can be seen below, I was asked to continue this here.
I really am interested in helping out with this.

Thanks guys,
Creighton Hogg

On Thu, 29 Dec 2005, John Q Splittist wrote:

> Creighton Hogg wrote:
> > Hi,
> > Have you gotten any responses yet for this project?
> 
> You're the first.
> 
> > I think I'd be interested in it.
> > It sounds like something I could do in little bits and 
> > pieces when I have time, which would be perfect.
> 
> Sounds good. Shall we continue this on climacs-devel? Then the experts 
> can weigh in with helpful suggestions, and we can go through the process 
> of getting you commit authority.
> 
> cheers,
> JQS
> 


From strandh at labri.fr  Sat Dec 31 00:35:30 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 31 Dec 2005 01:35:30 +0100
Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings
In-Reply-To: <Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>
References: <loom.20051228T143101-57@post.gmane.org>
	<Pine.LNX.4.58.0512281108230.21839@login01.hep.wisc.edu>
	<43B3BB46.8010807@yahoo.com>
	<Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>
Message-ID: <17333.53842.675301.220125@serveur5.labri.fr>

Hello,

Creighton Hogg writes:
 > so a couple of days ago I volunteered on the Lisp Gardeners 
 > group to work on a project involving documenting commands in 
 > climacs.
 > 
 > I really am interested in helping out with this.

Great!  Welcome to Climacs development.  I suggest sending patches to
this list for now. 

Also, please do not hesitate to ask questions here. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From splittist at yahoo.com  Sat Dec 31 09:16:55 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Sat, 31 Dec 2005 10:16:55 +0100
Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings
In-Reply-To: <Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>
References: <loom.20051228T143101-57@post.gmane.org>	<Pine.LNX.4.58.0512281108230.21839@login01.hep.wisc.edu>	<43B3BB46.8010807@yahoo.com>
	<Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>
Message-ID: <43B64C87.8090202@yahoo.com>

Creighton Hogg wrote:
> so a couple of days ago I volunteered on the Lisp Gardeners 
> group to work on a project involving documenting commands in 
> climacs.

My simple plan for enabling this (in the short term) would be something 
like this:

Have a hashtable that collects the docstrings:

(defvar *command-documentation* (make-hash-table))

Then create a new macro, say def-command, that fills the table:

(defmacro def-command ((name . options)
		       arguments
		       documentation
		       &body body)
   `(progn
     (setf (gethash ,name *command-documentation*) ,documentation)
     (define-command (,name , at options) ,arguments , at body)))

(or something slightly more complex that checks if DOCUMENTATION is a 
string, and, if not, omits the hashing and treats DOCUMENTATION as the 
first form of BODY.)

The form of the docstring could be something like:

"First line of the docstring, for display in the minibuffer.
A longer explanation, continuing on from the first line, that would be 
suitable for display on a help pane, once we have them."

Perhaps it will be found that further markup in the docstrings will be 
helpful.

Thoughts, anyone?

JQS

PS Creighton, many thanks for volunteering!


From brian at mastenbrook.net  Sat Dec 31 14:06:49 2005
From: brian at mastenbrook.net (Brian Mastenbrook)
Date: Sat, 31 Dec 2005 08:06:49 -0600
Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings
In-Reply-To: <43B64C87.8090202@yahoo.com>
References: <loom.20051228T143101-57@post.gmane.org>	<Pine.LNX.4.58.0512281108230.21839@login01.hep.wisc.edu>	<43B3BB46.8010807@yahoo.com>
	<Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>
	<43B64C87.8090202@yahoo.com>
Message-ID: <C85F26F1-54C6-45F9-AAD3-375D2553F248@mastenbrook.net>

On Dec 31, 2005, at 3:16 AM, John Q Splittist wrote:

> Creighton Hogg wrote:
>> so a couple of days ago I volunteered on the Lisp Gardeners group  
>> to work on a project involving documenting commands in climacs.
>
> My simple plan for enabling this (in the short term) would be  
> something like this:
>
> Have a hashtable that collects the docstrings:
>
> (defvar *command-documentation* (make-hash-table))
>
> Then create a new macro, say def-command, that fills the table:
>
> (defmacro def-command ((name . options)
> 		       arguments
> 		       documentation
> 		       &body body)
>   `(progn
>     (setf (gethash ,name *command-documentation*) ,documentation)
>     (define-command (,name , at options) ,arguments , at body)))
>
> (or something slightly more complex that checks if DOCUMENTATION is  
> a string, and, if not, omits the hashing and treats DOCUMENTATION  
> as the first form of BODY.)

I'm not sure that def-command is really a self-explanitory name. How  
about define-command/documentation, or does that offend other  
peoples' style senses?

>
> The form of the docstring could be something like:
>
> "First line of the docstring, for display in the minibuffer.
> A longer explanation, continuing on from the first line, that would  
> be suitable for display on a help pane, once we have them."
>
> Perhaps it will be found that further markup in the docstrings will  
> be helpful.
>
> Thoughts, anyone?

The natural form for markup would be to make the documentation a  
function which, when invoked, draws the documentation (or the  
extended documentation) to a pane argument. A few macros could be  
supplied to create this lambda without actually having to write out  
all the CLIM drawing commands.

--
Brian Mastenbrook
brian at mastenbrook.net
http://brian.mastenbrook.net/




From strandh at labri.fr  Sat Dec 31 19:08:47 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 31 Dec 2005 20:08:47 +0100
Subject: [climacs-devel] More ideas for gardeners
In-Reply-To: <20051228153035.A960@eskimo.com>
References: <20051228153035.A960@eskimo.com>
Message-ID: <17334.55103.60430.674260@serveur5.labri.fr>

Derek Peschel writes:
 > 
 > If I were choosing development projects, they might be:
 > 
 > 	- Taking advantage of Climacs's parsing to do more than just
 > 	  coloring files.

This is already the case to some extent with Swine, at least for
Lisp.  We do navigation, indentation, compilation, CLHS lookup, etc. 

 > 	  So Climacs could be aware of the regular-expression language
 > 	  and color expressions as they are being typed.  

Not sure what you mean here, but Climacs does not rely on regular
expressions for syntax highlighting.  It uses a parser capable of
doing LR parsing which is more powerful than regular expressions.  And
it updates the parse tree as you type, so the syntax highlighting
should be up to date as you type. 

 > 	  We also have two LISP syntaxes, probably with different
 > 	  strengths and weaknesses.  Is that a good idea?

No, cl-syntax should probably be ditched, but I would like to keep it
around until lisp-syntax can be generated from a grammar. 

 > 	  A Climacs with few assumptions about commands would
 > 	  be useful.  Thinking about various editors also forces
 > 	  developers to think about use cases (something that is
 > 	  almost completely missing from GNU Emacs).  It might also be
 > 	  nice to allow radical key rebindings at runtime.

This would be a good thing, but I think it is lower priority than most
other things.  For now, it is probably OK for most people who need to
rebind keys and to alter commands to do so "manually".

 > 	- Fixing Climacs's weak points: lack of speed, lack of
 > 	  developer documentation, incorrect calculation of the cursor
 > 	  position, and probably others.

I would go for correctness before speed.  On both my laptop and my
desktop machines, it is almost fast enough as it is, so I don't see
speed as terribly important to work on right now

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From dpeschel at eskimo.com  Sat Dec 31 19:13:21 2005
From: dpeschel at eskimo.com (Derek Peschel)
Date: Sat, 31 Dec 2005 11:13:21 -0800
Subject: [climacs-devel] More ideas for gardeners
In-Reply-To: <17334.55103.60430.674260@serveur5.labri.fr>;
	from strandh@labri.fr on Sat, Dec 31, 2005 at 08:08:47PM +0100
References: <20051228153035.A960@eskimo.com>
	<17334.55103.60430.674260@serveur5.labri.fr>
Message-ID: <20051231111321.A24792@eskimo.com>

On Sat, Dec 31, 2005 at 08:08:47PM +0100, Robert Strandh wrote:
>  > 	  So Climacs could be aware of the regular-expression language
>  > 	  and color expressions as they are being typed.  
> 
> Not sure what you mean here, but Climacs does not rely on regular

I see I wasn't clear.  I meant the language supported by cl-automaton.

-- Derek


From strandh at labri.fr  Sat Dec 31 19:18:44 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 31 Dec 2005 20:18:44 +0100
Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings
In-Reply-To: <43B64C87.8090202@yahoo.com>
References: <loom.20051228T143101-57@post.gmane.org>
	<Pine.LNX.4.58.0512281108230.21839@login01.hep.wisc.edu>
	<43B3BB46.8010807@yahoo.com>
	<Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>
	<43B64C87.8090202@yahoo.com>
Message-ID: <17334.55700.645758.226250@serveur5.labri.fr>

John Q Splittist writes:
 > 
 > My simple plan for enabling this (in the short term) would be something 
 > like this:
 > 
 > Have a hashtable that collects the docstrings:
 > 
 > (defvar *command-documentation* (make-hash-table))
 > 
 > Then create a new macro, say def-command, that fills the table:
 > 
 > (defmacro def-command ((name . options)
 > 		       arguments
 > 		       documentation
 > 		       &body body)
 >    `(progn
 >      (setf (gethash ,name *command-documentation*) ,documentation)
 >      (define-command (,name , at options) ,arguments , at body)))
 > 
 > (or something slightly more complex that checks if DOCUMENTATION is a 
 > string, and, if not, omits the hashing and treats DOCUMENTATION as the 
 > first form of BODY.)
 > 
 > The form of the docstring could be something like:
 > 
 > "First line of the docstring, for display in the minibuffer.
 > A longer explanation, continuing on from the first line, that would be 
 > suitable for display on a help pane, once we have them."
 > 
 > Perhaps it will be found that further markup in the docstrings will be 
 > helpful.
 > 
 > Thoughts, anyone?
 
This looks like a reasonable way to start.  Though, I am a bit
confused; why is it not possibly to rely on (documentation f
'function) to avoid having our own hash table?

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From splittist at yahoo.com  Sat Dec 31 20:34:06 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Sat, 31 Dec 2005 21:34:06 +0100
Subject: [climacs-devel] Re: [Gardeners] RFG climacs docstrings
In-Reply-To: <17334.55700.645758.226250@serveur5.labri.fr>
References: <loom.20051228T143101-57@post.gmane.org>	<Pine.LNX.4.58.0512281108230.21839@login01.hep.wisc.edu>	<43B3BB46.8010807@yahoo.com>	<Pine.LNX.4.58.0512291653530.13246@login01.hep.wisc.edu>	<43B64C87.8090202@yahoo.com>
	<17334.55700.645758.226250@serveur5.labri.fr>
Message-ID: <43B6EB3E.4000905@yahoo.com>

Robert Strandh wrote:
> John Q Splittist writes:
>  > 
>  > My simple plan for enabling this (in the short term) would be something 
>  > like this:
[etc.]
>  > Thoughts, anyone?
>  
> This looks like a reasonable way to start.  Though, I am a bit
> confused; why is it not possibly to rely on (documentation f
> 'function) to avoid having our own hash table?

Well, initially it was because I hadn't bothered to look at definition 
of define-command to see what would happen to a docstring in the obvious 
position (sure enough, it gets passed through to DEFUN as I should have 
suspected). But:

(a) "An implementation is permitted to discard documentation strings at 
any time for implementation-defined reasons." and

(b) Having our own mechanism allows us to do what Brian suggested, and 
have a function that knows how to render the information onto a given 
pane/stream (we might what to throw an &allow-other-keys in there 
somewhere, too).

But I could be persuaded otherwise, of course.

(DEF-COMMAND was a similarly lazy coining; but since we'll need 
something that will work with other structures like special variables, 
syntaxes, views (?) etc. a naming scheme that doesn't grate too much for 
the others would be handy.)

BTW, I'm assuming it makes sense to have the documentation 
string/function as part of the command definition. (I'm not sure how 
this works with internationalized (ie. multilingual) help.) Let me know 
if I'm assuming incorrectly.

JQS



From a_bakic at yahoo.com  Sat Dec 31 21:05:11 2005
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Sat, 31 Dec 2005 13:05:11 -0800 (PST)
Subject: [climacs-devel] More ideas for gardeners
In-Reply-To: <20051231111321.A24792@eskimo.com>
Message-ID: <20051231210511.66965.qmail@web34602.mail.mud.yahoo.com>

Hi all,

> I see I wasn't clear.  I meant the language supported by cl-automaton.

Just to say hi and wish you a happy New Year (and to note that I owe the
integration of Derek's code).

Alex


		
__________________________________________ 
Yahoo! DSL ? Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 



From splittist at yahoo.com  Sat Dec 31 21:25:14 2005
From: splittist at yahoo.com (John Q Splittist)
Date: Sat, 31 Dec 2005 22:25:14 +0100
Subject: [climacs-devel] Re: More ideas for gardeners
In-Reply-To: <20051231210511.66965.qmail@web34602.mail.mud.yahoo.com>
References: <20051231111321.A24792@eskimo.com>
	<20051231210511.66965.qmail@web34602.mail.mud.yahoo.com>
Message-ID: <43B6F73A.4060704@yahoo.com>

Aleksandar Bakic wrote:
> Just to say hi and wish you a happy New Year (and to note that I owe the
> integration of Derek's code).

Indeed - Happy New Year to all!

cl-automaton seems to be the great underutilised resource in climacs at 
the moment. How difficult would it be to add grouping and a 
replacement/subsitution mechanism (to form the basis of, eg. Regexp 
Query Replace)?

JQS


From a_bakic at yahoo.com  Sat Dec 31 22:38:38 2005
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Sat, 31 Dec 2005 14:38:38 -0800 (PST)
Subject: [climacs-devel] Re: More ideas for gardeners
In-Reply-To: <43B6F73A.4060704@yahoo.com>
Message-ID: <20051231223838.98508.qmail@web34601.mail.mud.yahoo.com>

> How difficult would it be to add grouping and a 
> replacement/subsitution mechanism (to form the basis of, eg. Regexp Query
Replace)?

I haven't tried yet. However, I found out that cl-ppcre does work, at least in
some cases that I tried, with Unicode characters. (I think I had
Unicode-related problems (besides performance) with it, but I cannot remember
the details now.) I hope to finish some higher-priority stuff soon so that I
can spend some time with both...

Alex


	
		
__________________________________ 
Yahoo! for Good - Make a difference this year. 
http://brand.yahoo.com/cybergivingweek2005/