From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Spreadsheet display mode Date: Sat, 24 Nov 2007 17:05:51 -0500 Message-ID: References: <64bfe3d50711221703n6a2aa803refcae006b68a022a@mail.gmail.com> <64bfe3d50711240349m6e9d2100n4ffcf9d5607bb8ff@mail.gmail.com> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1195941976 29644 80.91.229.12 (24 Nov 2007 22:06:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Nov 2007 22:06:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: "David O'Toole" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 24 23:06:23 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Iw38d-0004PX-0Z for ged-emacs-devel@m.gmane.org; Sat, 24 Nov 2007 23:06:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iw38N-0000Cp-VZ for ged-emacs-devel@m.gmane.org; Sat, 24 Nov 2007 17:05:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iw38K-0000Au-C6 for emacs-devel@gnu.org; Sat, 24 Nov 2007 17:05:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iw38J-000094-IB for emacs-devel@gnu.org; Sat, 24 Nov 2007 17:05:51 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iw38J-00008m-Ez for emacs-devel@gnu.org; Sat, 24 Nov 2007 17:05:51 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iw38J-0000pM-8B for emacs-devel@gnu.org; Sat, 24 Nov 2007 17:05:51 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Iw38J-0006FE-3t; Sat, 24 Nov 2007 17:05:51 -0500 In-reply-to: <64bfe3d50711240349m6e9d2100n4ffcf9d5607bb8ff@mail.gmail.com> (dto@gnu.org) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:84077 Archived-At: 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.