unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: MON KEY <monkey@sandpframing.com>
To: Lennart Borgman <lennart.borgman@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Proposal: `buffer-offer-save' be made a permanent-local
Date: Mon, 28 Jun 2010 00:39:08 -0400	[thread overview]
Message-ID: <AANLkTil25F-g4ii87-pfy8MkNLi3J3h9QVFCWYhSVwkq@mail.gmail.com> (raw)
In-Reply-To: <AANLkTin6yM07q4MbXTBrPda6k4s8nIVzuBDwvkVP4S-q@mail.gmail.com>

On Wed, Jun 16, 2010 at 7:11 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Thu, Jun 17, 2010 at 12:02 AM, MON KEY <monkey@sandpframing.com> 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	other threads:[~2010-06-28  4:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14  0:17 Proposal: `buffer-offer-save' be made a permanent-local MON KEY
2010-06-14  0:59 ` Lennart Borgman
2010-06-14  1:00 ` Stefan Monnier
2010-06-14  8:48   ` MON KEY
2010-06-14  9:18     ` Lennart Borgman
2010-06-16  7:21       ` MON KEY
2010-06-16 11:39         ` Lennart Borgman
2010-06-16 22:02           ` MON KEY
2010-06-16 23:11             ` Lennart Borgman
2010-06-28  4:39               ` MON KEY [this message]
2010-06-14 13:38     ` Stefan Monnier
2010-06-17  4:15   ` Kevin Rodgers
2010-06-17 20:19     ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2010-06-17 21:36 MON KEY
2010-06-17 22:25 ` Lennart Borgman
2010-06-18  0:13   ` MON KEY
2010-06-18  0:33     ` Lennart Borgman
2010-06-18  2:53       ` MON KEY
2010-06-19 15:20         ` Lennart Borgman
2010-06-20  5:05           ` MON KEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTil25F-g4ii87-pfy8MkNLi3J3h9QVFCWYhSVwkq@mail.gmail.com \
    --to=monkey@sandpframing.com \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).