Spreadsheet display mode

Spreadsheet display mode

[Richard Stallman]

Someone suggested that Emacs should have a spreadsheet display mode.
I did some thinking about the idea.  A list of cell definitions could
control how to display each line, and they could go in a `display'
property that might be on an overlay or text property (so that you
could display just a part of the buffer as a spreadsheet).

The actual text would use delimiters to separate cell contents.
The cell definitions could specify what delimiters to use.

What do you think?

Re: Spreadsheet display mode

[Glenn Morris]

Richard Stallman wrote:

> Someone suggested that Emacs should have a spreadsheet display mode.

You've tried ses.el? info ses.

Re: Spreadsheet display mode

[Richard Stallman]

    > Someone suggested that Emacs should have a spreadsheet display mode.

    You've tried ses.el? info ses.

I'm not talking about a spreadsheet.  I'm talking about a spreadsheet
display mode -- something ses and other programs could use to present
columnar displays more easily, more reliably, and without advising
anything.

Re: Spreadsheet display mode

[David O'Toole]

Hi Richard,

I wrote something called "cell-mode" that seems similar to what you
describe. It holds a grid of cells whose "labels" are
application-defined strings with text properties, and draws them to a
buffer. The display code can do several things:

  - Insert display-property "specified spaces" during rendering so
that all cells in a column
    are the same width---even when there are images and text in the label
  - optional vertical and/or horizontal "zebra stripes" (i.e. every
other column / row is tinted)
  - seamlessly tile various identically-sized rectangular images

I did have a version that supported embedding an interactive
spreadsheet UI into random buffers as a minor mode, using display
properties. You can't put point inside the text, but it can still
receive mouse clicks and keyboard events, so I could just draw a fake
cursor (with an overlay) and map keystrokes to commands that move the
fake cursor.  The illusion was pretty good.

Anyway, I'm trying to make it into a very general-purpose library that
could be used as a front-end for SES and all the other "display stuff
in a table interactively" modes (dired, buffer list, etc)

Here are some screenshots:

an old demo with some interactive objects:
http://dto.freeshell.org/images/cell-mode.png

a recent shot of a rudimentary XPM pixel art drawing program:
http://dto.freeshell.org/images/pixel-preview.png

an example of embedding cell-mode in a buffer:
http://dto.freeshell.org/images/EcaSpace-alpha.png

image tiling stuff:
http://dto.freeshell.org/images/RogueLike-11.png
http://dto.freeshell.org/images/RogueLike-12.png

larger images:
http://dto.freeshell.org/images/cell-mode-2.png

I've been looking for an excuse to work on cell-mode again. It does
need some fixes (especially to make it work well on ttys) but if
anyone is interested i will clean it up and post it to
gnu.emacs.sources.
------------------------------------

From: Richard Stallman <rms <at> gnu.org>
Subject: Spreadsheet display mode
Newsgroups: gmane.emacs.devel
Date: 2007-11-22 16:23:02 GMT (8 hours and 5 minutes ago)

Someone suggested that Emacs should have a spreadsheet display mode.
I did some thinking about the idea.  A list of cell definitions could
control how to display each line, and they could go in a `display'
property that might be on an overlay or text property (so that you
could display just a part of the buffer as a spreadsheet).

The actual text would use delimiters to separate cell contents.
The cell definitions could specify what delimiters to use.

What do you think?

Re: Spreadsheet display mode

[Bastien]

"David O'Toole" <dto@gnu.org> writes:

> Anyway, I'm trying to make it into a very general-purpose library that
> could be used as a front-end for SES and all the other "display stuff
> in a table interactively" modes (dired, buffer list, etc)

FWIW, you might also try to make this spreadsheet display work with
Org tables.  I don't know about ses.el, but Org is doing a rather good
job at spreadsheets.

-- 
Bastien

Re: Spreadsheet display mode

[Richard Stallman]

    FWIW, you might also try to make this spreadsheet display work with
    Org tables.  I don't know about ses.el, but Org is doing a rather good
    job at spreadsheets.

Perhaps Org could also make use of the spreadsheet display facility
that I am suggesting.

Re: Spreadsheet display mode

[Johan Bockgård]

"David O'Toole" <dto@gnu.org> writes:

> I did have a version that supported embedding an interactive
> spreadsheet UI into random buffers as a minor mode, using display
> properties. You can't put point inside the text, but it can still
> receive mouse clicks and keyboard events, so I could just draw a fake
> cursor (with an overlay) and map keystrokes to commands that move the
> fake cursor.  The illusion was pretty good.

  `cursor'
       Normally, the cursor is displayed at the end of any overlay and
       text property strings present at the current window position.  You
       can place the cursor on any desired character of these strings by
       giving that character a non-`nil' CURSOR text property.


(setq foo-map
      (let ((map (make-sparse-keymap)))
	(define-key map [down-mouse-1] 'foo)
	map))

(defun foo (e)
  (interactive "e")
  (let* ((x (posn-string (event-start e)))
	 (str (car x))
	 (pos (cdr x)))
    (mouse-set-point e)
    (remove-text-properties 0 (length str) '(cursor nil) str)
    (put-text-property pos (1+ pos) 'cursor t str)
    ;; `redisplay' doesn't work!!
    (force-mode-line-update)))

(insert (propertize "$" 'display (propertize "123456" 'keymap foo-map)))

;; Click to place point


-- 
Johan Bockgård

Re: Spreadsheet display mode

[Johan Bockgård]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

>     ;; `redisplay' doesn't work!!
>     (force-mode-line-update)))

I also found force-window-update, which does the job (as do
redraw-display and redraw-frame, but they clear the frame which causes
flickering).

    *** New function `force-window-update' can initiate a full redisplay
    of one or all windows. Normally, this is not needed as changes in
    window contents are detected automatically. However, certain
    implicit changes to mode lines, header lines, or display properties
    may require forcing an explicit window update.

The manual is not explicit about the difference between
(info "(elisp) Refresh Screen") and
(info "(elisp) Forcing Redisplay")

It's not clear why (redisplay t) shouldn't work

    If the optional argument FORCE is non-`nil', it forces an immediate
    and complete redisplay even if input is available.

-- 
Johan Bockgård

Re: Spreadsheet display mode

[Richard Stallman]

    The manual is not explicit about the difference between
    (info "(elisp) Refresh Screen") and
    (info "(elisp) Forcing Redisplay")

I will clear that up.

    It's not clear why (redisplay t) shouldn't work

	If the optional argument FORCE is non-`nil', it forces an immediate
	and complete redisplay even if input is available.

This causes redisplay _now_.  `force-window-update'
causes a certain window to be redisplayed in full
whenever redisplay happens.

Re: Spreadsheet display mode

[David O'Toole]

I never could get that to work, but perhaps I missed something.

On Nov 23, 2007 7:03 AM, Johan Bockgård <bojohan+news@dd.chalmers.se> wrote:
>
>   `cursor'
>        Normally, the cursor is displayed at the end of any overlay and
>        text property strings present at the current window position.  You
>        can place the cursor on any desired character of these strings by
>        giving that character a non-`nil' CURSOR text property.
>

Re: Spreadsheet display mode

[Richard Stallman]

    I wrote something called "cell-mode" that seems similar to what you
    describe. It holds a grid of cells whose "labels" are
    application-defined strings with text properties, and draws them to a
    buffer.

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

In the design I have in mind, the real, underlying text is in the
buffer, so editing operates on the underlying text.  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.

With this design, the C code would be more general, and the columnar
part of it would be entirely in Lisp.

In difference to your current design, the data that the user edits
would be in the buffer.  Ordinary editing commands would mostly still
work.

What do you think?

Re: Spreadsheet display mode

[David O'Toole]

Hi Richard,

On Nov 23, 2007 10:13 PM, Richard Stallman <rms@gnu.org> 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

Re: Spreadsheet display mode

[Richard Stallman]

    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.

I think you are saying that the base data structure is not text at all,
rather Lisp data, and the only text that is used is the generated
text that you use for the display.  Is that right?

    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.

I wasn't saying anything about an XPM version of anything.  That isn't
part of what I was talking about.  I was talking about a columnar
mode for Emacs redisplay, which would take the text in the buffers
and put it into columns for display only.

    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 don't entirely understand the question.  The dired data is already
represented as text.  I am not sure whether we would want to use the
columnar mode fyr a dired buffer, but if we did, it wouldn't change
anything but the way it appears on the screen.  (The columns might be
aligned, for instance).

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

I don't have more specific ideas yet.

Re: Spreadsheet display mode

[David O'Toole]

On Nov 24, 2007 5:05 PM, Richard Stallman <rms@gnu.org> wrote:

> I think you are saying that the base data structure is not text at all,
> rather Lisp data, and the only text that is used is the generated
> text that you use for the display.  Is that right?

Correct. I could change this if you want, because the display code
doesn't depend on it.

But first I would like to move the spreadsheet-drawing code into its
own .el file, and post a revised version of that.