[climacs-devel] Can syntax classes handle text overlays? (Evaluating from buffer)

[Derek Peschel]

On Thu, Aug 25, 2005 at 06:34:46AM +0200, Robert Strandh wrote:
> Sort of.  It gets called for every parse tree that is at least
> partially on display in a window. 

Does the caller of display-parse-tree keep track of what's on display,
say by tracking the parse item in the upper left corner of the window?
What's the sequence of events when you scroll the window?

>  > Can that handle anything like Emacs's text properties or overlays?
>  > In the most general case, they apply to characters and not parse-tree items,
>  > so the character-by-character formatting of the overlay would have to be
>  > mixed with the formatting of the parse item.
> 
> If you do want overlays, you probably would have to do essentially
> what emacs does, as a mechanism separate from that of displaying parse
> trees. 

But I assume Emacs merges the overlay information into a data structure
holding characters, while I would need to work with characters and parse
state.

>  > Right now, the only thing on the screen that has X-Y coordinates derived
>  > from a text location seems to be the cursor.  And I've edited LISP files
>  > with strings (displayed in a larger italic font) and the cursor can go to
>  > the wrong place in the window, so I suspect the syntax machinery is not
>  > being used.
> 
> Right, the way the position of the cursor is currently computed is
> bogus.

So I won't use the cursor code as an example. :)  But I mentioned it because
it would have to deal with the same issues I've been thinking about.  I can
think of two ways to do it, and there may be better ones:

	- treat all chars. as monospaced -- keep cursor location in line
	  and character coordinates -- attach pixel coordinates to each
	  parse item, or each character of each parse item -- when cursor
	  moves, find new pixel coordinates from new line/character
	  coordinates (using various data structures) -- use pixel
	  coordinates to display the cursor

	- treat buffer as a series of lines containing non-monospaced
	  chars., so that the goal column is a pixel coordinate rather
	  than a character offset in the line -- the data structures
	  are probably the same as the first method, actually

If you could explain how Emacs places the cursor, that might help me think
about Climacs's design.

> For the structured part, you could highlight a parse tree (say) by
> entering it in a hash table of parse trees to be highlighted in
> particular ways, and then use an :around method to turn on and off
> highlighting.  Clicking on some text could select that parse tree, or
> you could use specific commands for that. 

The simple-minded approach would add a state field to every syntax item;
display-parse-tree would check the state field and choose a presentation
style.  Your :around method would set the state to "highlighted" at some
node in the tree, and the tree structure would propagate the state to the
subtrees of the node and thus the correct block of text, and then the :around
method would set the state back to "unhighlighted" when the appropriate
tree had been traversed.  Right?

You also mentioned a PRESENT method.  How might that help the
implementation?

> For the unstructured commands, I am not sure.  It seems to me like you
> might want to indicate a certain parse tree by putting point there,
> but you probably would not want arbitrary sequences of characters to
> be selected.  At least not in this particular application. 

In fact I did mean "arbitrary sequences of characters" but you're right,
it does violate the abstraction and I can't think of a good reason when
evaluating LISP code.  Still, restricting the marking to entire parse
items may be a problem for other applications.  That's why it's worth
thinking about marking characters too.

Even for LISP, it may be useful to mark snippets of code in strings or
comments, or evaluate part of a variable name.  For those you'd need to
look inside parse items.

-- Derek