[climacs-devel] More ideas for gardeners

[Derek Peschel]

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