From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "David O'Toole" Newsgroups: gmane.emacs.devel Subject: Re: Spreadsheet display mode Date: Sat, 24 Nov 2007 06:49:24 -0500 Message-ID: <64bfe3d50711240349m6e9d2100n4ffcf9d5607bb8ff@mail.gmail.com> References: <64bfe3d50711221703n6a2aa803refcae006b68a022a@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1195904985 28968 80.91.229.12 (24 Nov 2007 11:49:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Nov 2007 11:49:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 24 12:49:53 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 1IvtW8-0000Zq-IJ for ged-emacs-devel@m.gmane.org; Sat, 24 Nov 2007 12:49:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvtVt-0002vN-W3 for ged-emacs-devel@m.gmane.org; Sat, 24 Nov 2007 06:49:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IvtVq-0002tE-8e for emacs-devel@gnu.org; Sat, 24 Nov 2007 06:49:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IvtVo-0002rs-OQ for emacs-devel@gnu.org; Sat, 24 Nov 2007 06:49:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IvtVo-0002rl-JF for emacs-devel@gnu.org; Sat, 24 Nov 2007 06:49:28 -0500 Original-Received: from wa-out-1112.google.com ([209.85.146.177]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IvtVn-0007cb-Vg for emacs-devel@gnu.org; Sat, 24 Nov 2007 06:49:28 -0500 Original-Received: by wa-out-1112.google.com with SMTP id k34so116177wah for ; Sat, 24 Nov 2007 03:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=x6EQm3o0vXcDxhN/lXOhUJ9Z4968vxnmTcukboRTxtc=; b=xT7jjZiGqyw/sZqPihK/u9RCQGn4pBW6IjVTRiKnDK78KctVU7A7I18iaMNwQDdLHt31+0QwLUiZzistEaoqyZPfQYG8zF0xdUzRQnuuni8gL7HINWQL+Z2RIU9RIkSTEPqt9i7p4JaoyMgMjXOWE5X7NquEwuQEGfATM2QSScI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sg4aYZwHvLhWmoDz8p+irw0xxp6byAdq6HFD+hW54v+TgQtHXcRxyOI062sVOdhuQEv2gXKfn2um3eH2ndslE1YXHHEFd8oQ/oHoYI811kG/EYn5WEwRdpPB/ayQPCH1gku5YAAYwri22vBsjj3T7VEznPaJHjT8HtttmPuR2RA= Original-Received: by 10.114.209.1 with SMTP id h1mr384518wag.1195904964671; Sat, 24 Nov 2007 03:49:24 -0800 (PST) Original-Received: by 10.114.169.15 with HTTP; Sat, 24 Nov 2007 03:49:24 -0800 (PST) In-Reply-To: Content-Disposition: inline X-Google-Sender-Auth: e2944977ae41bb6d X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:84044 Archived-At: Hi Richard, On Nov 23, 2007 10:13 PM, Richard Stallman 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