Re: CCL Editor Extendability [Cocoa IDE v1 project]

On Feb 20, 2009, at 2:55 PM, Terje Norderhaug wrote:
> On Feb 17, 2009, at 4:41 AM, Gail Zacharias wrote:
>> At 2/16/2009 08:02 PM, Terje Norderhaug wrote:
>>> My general wish for the Cocoa IDE effort is that there are well
>>> planned hooks for us developers to extend and customize the
>>> functionality. For example, it would be great if the Fred datamodel
>>> supported arbitrary non-character objects in the text, with a  
>>> defined
>>> interface for how these integrate and display, but without their
>>> implementation having to be part of the initial IDE project.
>>
>> The working proposal for extending the CCL editor with font support
>> is in: http://trac.clozure.com/openmcl/wiki/CocoaIde/FontSupport
>
> Just to brainstorm: Buffer mark ("cursors") may also provide an
> abstraction to insert images and other media into text, and to
> overlay structure.  Imagine if buffer marks had their own
> visualization methods and could be subclassed.
>
> To share one of my own uses of Fred in my software: I am using buffer
> marks to build, visualize and maintain a hierarchical representation
> of content. Mostly XML documents in my case, for example displaying
> an outline using a twist-down-view with each node a buffer-mark to
> the start of markup tokens in the document. It depends on fast and
> scalable buffer marks to handle large complex content - as far as I
> recall, the ones in Fred start to be sluggish as they grow in number.

Customizable buffer marks would be useful for editor extensions that  
overlay rather than modify the edited content. The buffer mark based  
XML document outline implementation above can also be applied to CL  
editing features.

Consider the case of implementing a third party editor contribution  
that upgrades the functionality of the List Definitions dialog of the  
Tools menu of MCL, which lists the Common LISP definitions in the  
current editor window. Instead of requiring use of a refresh button  
to update the list, we would like to provide a constantly dynamically  
updated list of the definitions in the editor, yet make it forgiving  
for the common editing situations in which a definition (and thus the  
file) is in an invalid state.

One possible implementation has the List Definitions window maintain  
a list of buffer marks to the start of each top level definition.  
When there is a change in the file, it finds the item matching buffer  
mark in the listed definitions and updates the display of the item if  
required. The change is only considered for the relevant buffer mark  
- an invalid definition state doesn't have to affect the listing of  
the other definitions. That is, local edits in the text have local  
implications in the listing of the definitions, rather than requiring  
a repeated refresh parsing the complete file.

I have implemented this type of functionality by patching fred to  
notify a dialog update function about content changes on fred-update,  
ed-insert-with-undo, and the like. It would be useful for editor  
extensions if such notification features could be part of the  
implementation of the editor rather than having to be patched on.

-- Terje Norderhaug



  
_______________________________________________
info-mcl mailing list
[email protected]
http://clozure.com/mailman/listinfo/info-mcl