From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local Date: Mon, 28 Jun 2010 00:39:08 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1277699963 30398 80.91.229.12 (28 Jun 2010 04:39:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Jun 2010 04:39:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 28 06:39:21 2010 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.69) (envelope-from ) id 1OT67s-0001Ua-DM for ged-emacs-devel@m.gmane.org; Mon, 28 Jun 2010 06:39:20 +0200 Original-Received: from localhost ([127.0.0.1]:36841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OT67r-0008Fq-KI for ged-emacs-devel@m.gmane.org; Mon, 28 Jun 2010 00:39:19 -0400 Original-Received: from [140.186.70.92] (port=37486 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OT67l-0008Fl-Gn for emacs-devel@gnu.org; Mon, 28 Jun 2010 00:39:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OT67j-0001gy-SX for emacs-devel@gnu.org; Mon, 28 Jun 2010 00:39:13 -0400 Original-Received: from mail-pv0-f169.google.com ([74.125.83.169]:55163) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OT67j-0001eq-KG for emacs-devel@gnu.org; Mon, 28 Jun 2010 00:39:11 -0400 Original-Received: by pvg11 with SMTP id 11so3014814pvg.0 for ; Sun, 27 Jun 2010 21:39:08 -0700 (PDT) Original-Received: by 10.115.84.22 with SMTP id m22mr4562373wal.201.1277699948271; Sun, 27 Jun 2010 21:39:08 -0700 (PDT) Original-Received: by 10.114.150.4 with HTTP; Sun, 27 Jun 2010 21:39:08 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: PHtgq0O5e8BdxOqEUyd4xzPk3JQ X-detected-operating-system: by eggs.gnu.org: GNU/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:126472 Archived-At: On Wed, Jun 16, 2010 at 7:11 PM, Lennart Borgman wrote: > On Thu, Jun 17, 2010 at 12:02 AM, MON KEY wrote: >> While it is prob. _never_ gonna be retro-fitted onto Emacs lisp, >> AIUI the Common-Lisp or FTM MacLisp package systems accomplish(ed) >> much of what we are now trying to accomplish with buffers and >> (multiple)major-modes. Too bad. > > Did they really do that? How? Sorry it took me so long to get back to you on this: :SEE (URL `http://lispm.dyndns.org/lispm/system-78-48/') :SEE (URL `http://lispm.dyndns.org/news?ID=NEWS-2010-02-14-1') Of particular relevance to the topic at hand are the following procedures from the file: system-78-48/zwei/zmacs.lisp ,---- | ;;; Return T if the buffer has been changed since the last time it | ;;; was read or written. If it never has been read or written, | ;;; ERROR. | (DEFUN BUFFER-MUNGED-P (BUFFER &OPTIONAL SPECIAL-TOO) | (AND (SYMBOLP (BUFFER-FILE-ID BUFFER)) | (FERROR NIL | "BUFFER-MUNGED-P on a file that has not been read or written.")) | (AND (OR SPECIAL-TOO (NLISTP (BUFFER-FILE-ID BUFFER)) | (NEQ (CAR (BUFFER-FILE-ID BUFFER)) ':SPECIAL-BUFFER)) | (NEQ (NODE-TICK BUFFER) ':READ-ONLY) | (> (NODE-TICK BUFFER) (BUFFER-TICK BUFFER)))) | | ;;; Return T is a buffer should be offered for saving. If it has | ;;; been touched since it was last read or created (if it was a (New | ;;; File)). | (DEFUN BUFFER-NEEDS-SAVING-P (BUFFER &OPTIONAL SPECIAL-TOO) | (AND (BUFFER-FILE-ID BUFFER) | (OR SPECIAL-TOO (NLISTP (BUFFER-FILE-ID BUFFER)) | (NEQ (CAR (BUFFER-FILE-ID BUFFER)) ':SPECIAL-BUFFER)) | (NEQ (NODE-TICK BUFFER) ':READ-ONLY) | (> (NODE-TICK BUFFER) (BUFFER-TICK BUFFER)))) | | ;;; Update PACKAGE from the current buffer. This is called whenever | ;;; either the current buffer changes, or the package of the buffer | ;;; changes. | (DEFUN COMPUTE-BUFFER-PACKAGE (BUFFER) | (OR *RECURSIVE-PKG-FIND-PACKAGE-KLUDGE* | (LET ((GENERIC-PATHNAME (BUFFER-GENERIC-PATHNAME BUFFER)) | (*RECURSIVE-PKG-FIND-PACKAGE-KLUDGE* T) | N) | (MULTIPLE-VALUE-BIND (VARS VALS) | (FS:FILE-PROPERTY-BINDINGS GENERIC-PATHNAME) | (IF (SETQ N (FIND-POSITION-IN-LIST 'PACKAGE VARS)) | (SETQ PACKAGE (NTH N VALS)) | (FUNCALL GENERIC-PATHNAME | ':PUTPROP (PKG-NAME PACKAGE) 'PACKAGE))))) | NIL) `---- :SEE (URL `http://lispm.dyndns.org/lispm/system-78-48/zwei/zmacs.lisp') It is important that we be clear w/re the difference between Common-Lisp style packages and Elisp packages. Whereas the Emacs-lisp package is more akin to the GNU/Linux distribution concept of a pkg (e.g. sourcecode file(s) that extends the user's system once installed and/or compiled), the Common-Lisp packages is more similiar to what you might get if you were to combine the fully qualified symbols of an XML-namespace w/ the scoping rules of lexically (compiled/source-based) defined/bound symbols local to a particular subsystem within a running system where each package has a fully dedicated symbol table (think obarray) with internal, external, and inherited symbols. Once you have packages/namespacing/lexical-scoping you can put your symbols in a corner where they can no longer come and go as they please unless they ask nicely. If you want to make certain features dynamic you declare them `special' but FTMP the symbols live happily in their own little world because they are well fed and provided for. (URL `http://www.lispworks.com/documentation/HyperSpec/Body/11_aa.htm') Within a given namespace when we want content to be frobbed by or with a private symbol from the the context of a specific buffer we do so by either: - accessing those symbols direclty by directly accessing them by the package they live in e.g.: (setf minion::*grovel-var* (minion::grovel (minion::frob minion::*grovel-var*))) - or by importing the symbol into some package namespace specific to a buffer (or type of buffer) and thereafter calling it directly with e.g.: (use-package 'minion 'minions-cousin) (setf *grovel-var* (grovel (frob *grovel-var*))) IOW many of the control/state related issues that are currently piggy backed upon Emacs/Elisp concept of the buffer/major-mode could instead be handled by using the formal set of first class tools the (Mac/Inter/Spice/Butterfly/Z)Lisp inspired/derived languages like CLTL-[1-2]/ANSI Lisp's provide(d). This said, AFAICT the major-mode distinctions made by contemporary Emacsen (and in particular the `multiple major mode') do not have have direct correspondence with the features provided with the defunct historic Lisp systems. This said, it isn't clear that they were needed given the additional features that the system/language provided. e.g. "Why would anyone endeavor to chop down trees with a blunt hammer when they have a perfectly good chainsaw?" Unfortunately I'm too young to know this. Prob. only those fortunate enough to have had the opportunity to actively use such lisp systems can answer this question with any authority. Certainly there is at least one Emacs here who did/can :) -- /s_P\