emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: `buffer-offer-save' be made a permanent-local


From: MON KEY
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Mon, 28 Jun 2010 00:39:08 -0400

On Wed, Jun 16, 2010 at 7:11 PM, Lennart Borgman
<address@hidden> wrote:
> On Thu, Jun 17, 2010 at 12:02 AM, MON KEY <address@hidden> 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\



reply via email to

[Prev in Thread] Current Thread [Next in Thread]