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

[Robert Strandh]

Hello, 

Derek Peschel writes:
 > 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?

No, there is an :around method that checks whether part of the parse
tree is on display, if so, it does (call-next-method).  We guarantee
that the leaf parse trees (lexemes) do not span newlines, so no need
to take care of partially-displayed lexemes.

The rest is done by CLIM.  We use updating-output and CLIM figures out
if things were already on display, and if it can optimize the
redisplay.  As far as Climacs is concerned, it just displays
everything that is visible. 

 > What's the sequence of events when you scroll the window?

Noting particular.  It goes through the same thing, except that this
time, the :around method will (call-next-method) on a different set of
parse trees.  If some of them are the same as last time, CLIM will try
to optimize. 

 > > 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.

I don't think I would organize that in this way at all.  I would keep
the overlays in a data structure (interval tree?) that could be
interrogated by the display-parse-tree function so that when an object
is to be presented, its visual aspects could be modified accordingly. 

 > > 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.  

You think so?  I got the impression that overlays were based not on XY
coordinates but on buffer positions.  Maybe I'm wrong. 

 > 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

This does not sound right at all.  In particular because that
information would have to be recomputed in every command-loop
iteration in case scrolling has happened.  

 > 	- 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

Actually, probably the best way to go is to interrogate the output
record in which the cursor is located as to its position.  and then,
based on the contents of that output record, compute the exact
location of the cursor. 

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

Sorry, I do not know that. 

 > > 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?

Yep

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

Anything that should be highlighted or clickable should use PRESENT so
that it can be used by ACCEPT in other contexts than the exact one you
have been thinking of. 

 > > 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.

OK, I'll let you think about it some more then :-)

Personally, I think that for these "other applications", we should
have a different grammar so that the parse trees look different, and
so that as a consequence, highlighting and selection will be
appropriate for the particular syntax of that application.  This could
be individual characters in some applications of course. 

 > 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.

Again, I'll let you think about that some more.  While it could be
useful, I am not willing to put it huge amounts of kludgey code unless
there is a real need. 

-- 
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.
---------------------------------------------------------------------