Re: Spreadsheet display mode

[David O'Toole]

Hi Richard,

On Nov 23, 2007 10:13 PM, Richard Stallman <address@hidden> wrote:

> In your design, the buffer holds the text as it is displayed,
> and the real underlying text is somewhere else.

This isn't quite correct---actions in a cell-mode spreadsheet don't
inherently cause updates to some other text that actually represents
the spreadsheet data (i.e. formulas.) That is more like how SES works.
In contrast, most of the stuff I've done with cell-mode involved cells
with cl structs in them, each typically having some function-valued
slots, and different user actions could trigger different functions.

> In the design I have in mind, the real, underlying text is in the
> buffer, so editing operates on the underlying text.

This is good for formulas and quite a bit else, so I would like to
support this in cell-mode. But I can think of situations where I would
not want it to act this way.

For example, I wrote a little program that uses cell-mode to display a
grid of colored squares. You can issue cell-mode commands that tell
the cell to change its color, etc. Once you've drawn something, you
can invoke another command to generate a buffer with an XPM version of
the image, as text. It sounds like what you are suggesting is that
each editing operation (i.e. color change in a pixel) would result in
an immediate corresponding update to the XPM text. But I don't know if
it makes sense to parse the XPM buffer and figure out which bits need
to be updated for every editing operation (especially since the number
of characters per pixel etc. can vary) instead of just generating the
XPM all at once when it's time to save (or autosave.)

In short, I would rather write a function that translates Lisp data to
XPM (and another function to do the reverse) than edit an image by
making repeated changes to its ASCII representation. (I don't think
XPM was ever intended as an in-memory format for dealing with
pixmaps.)

I can imagine other, similar situations. For example, using cell-mode
to replace the default display of dired, buffer-list, and other
interactive-table stuff--- what would the "real text" be, which we
were supposed to update on every operation, if the spreadsheet
represents a list of Emacs buffers or external processes?

I think the real gain would be allowing the spreadsheet (when
appropriate) to explicitly NOT correspond to some block of text in
another buffer.

> The columnar
> display form would NOT be in the buffer.  It would be generated
> inside the display code under the control of this new feature.
>
> Maybe we could combine the two ideas using a hidden buffer.  Your code
> could operate on the user-visible buffer, generating text in another
> buffer, and redisplay would use part of that other buffer in place of
> parts of the user-visible buffer.

Hmm.

I'd like to understand a bit more clearly what you envision for the C
part (i.e. "this new feature") and how it would fit in with the other
special display property stuff. This would help me figure out if I can
adapt cell-mode into something suitable.

 Actually it sounds like there are three distinct parts:

 - A user-interface library that can draw fancy spreadsheets and help
the user interact with grids of arbitrary Lisp objects (insert/delete
rows/columns and other basic spreadsheet stuff).
 - Applications that use the UI as a front-end (potentially SES,
org-table, dired etc)
 - A new feature in the display code of Emacs (written in C) that
makes this all possible. Can you be more specific about this part? It
sounds a little bit like indirect buffers.

--Dave