[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lispm programming questions
Date: Wed, 30 AUG 89 18:13:09 PDT
From: KARNICKY@CRVAX.SRI.COM (Karnicky)
In ZMACS, I create and compile the following buffer:
;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: (JTEST) -*-
(defun jfoo ()
(format t "~%This symbol is in package jtest"))
Next, in a lisp-listener, I evaluate the following:
(jfoo)
Use the definition of JTEST:JFOO? (Y, N, V, P, or G) Yes.
This symbol is in package jtest
NIL
;;;Why is jfoo external? <*************************
(use-package "jtest")
T
;;;fine
(jfoo)
Use the definition of JTEST:JFOO? (Y, N, V, P, or G) Yes.
This symbol is in package jtest
NIL
;;;I expected to be able to use (jfoo) without a prefix!? <*****************
You are assuming that it is external because it is printing with a
single colon. This is not always true in Genera. For backward
compatibility with Zetalisp, which didn't have the distinction between
internal and external symbols, Symbolics supports an option called
:COLON-MODE when creating packages. It can be either :INTERNAL or
:EXTERNAL, and specifies what type of symbol a single colon requires.
With COLON-MODE :INTERNAL, foo:bar is the same as foo::bar. If a symbol
is interned in a :COLON-MODE :INTERNAL package, it is printed with a
single colon.
For further compatibility, :COLON-MODE :INTERNAL is the default if the
package is created using a Zetalisp package creation function. When a
package is created because "Package: (NAME)" was seen in the file
attribute line, the Zetalisp package creation function is used. Had you
created the package earlier using the Common Lisp MAKE-PACKAGE function
you would have seen the behavior you expected. But since you let the
package be created automatically, you got hit by Symbolics's extension.
(export 'jfoo "jtest")
;;;here I got a complaint that the symbol JFOO is not present in package JTEST
;;;this I understand
Back to Dribbling Lisp Listener in Dynamic Lisp Listener 2.
(export 'jtest:jfoo "jtest")
;;;here I got a complaint that exporting the symbol JFOO would cause a name
;;;conflict in USER- this I don't understand <****************************
When you typed the previous form you created USER::JTEST. Since USER
:USEs JTEST, exporting FOO from JTEST would cause a conflict.
;;;Finally, I tried importing JTEST:JFOO into USER but it complained that
;;;"this would cause a name conflict with JFOO which is already present"
;;;This I dont understand <***********************************
This is the same problem as the previous one. When you typed 'JFOO in
the first EXPORT form, you interned a symbol named JFOO in USER.
===============================================================================
===============================================================================
I want to be able to access any EXISTING window objects.
(for example, so I can send it various messages etc.) The question is, how
can I get the window object?
If I'm making a NEW window I can use (setq x (tv:make-window .... etc.
and then refer to the value of x.
There is no data structure that contains a list of ALL existing windows.
You can get pretty close by recursing through the :INFERIORS of
TV:MAIN-SCREEN, e.g.:
(defun map-windows (function &optional (superior tv:all-the-screens) (depth 0))
(mapc #'(lambda (w)
(funcall function w depth)
(map-windows function w (1+ depth)))
(etypecase superior
(tv:sheet (send superior :inferiors))
(list superior))))
This is the same hierarchy that Peek Windows displays. You can get a
similar display with:
(map-windows #'(lambda (w d) (format t "~&~VT~A~%" (* d 4) w)))
However, some windows will not be found using this. For example,
typeout windows are only in this hierarchy when they are activated
(until then, they are only in the superior's :TYPEOUT-WINDOW). Zmail
has lots of windows that aren't in this hierarchy; for example, the
Profile editor windows are only in the hierarchy when you're in Profile
mode (and then the regular windows aren't).
A kludgey way to find all windows is to scan TV:SHEET-AREA using the
area-scanning routines documented in "Internals, Processes, and Storage
Management." Be careful, though -- this area contains windows that have
been killed and are waiting to be GCed.
By poking around in the source for SYS:FIND-WINDOW-OF-FLAVOR
I found that the function call:
(SYS:CONSOLE-PREVIOUSLY-SELECTED-WINDOWS SYS:*SLB-MAIN-CONSOLE*)
returns an array whose members are PREVIOUSLY-SELECTED windows, which is pretty
close to what I want. Incidently, the source for SYS:FIND-WINDOW-OF-FLAVOR has
the intriqueing (sp?) comment: "Only looks at PREVIOUSLY-SELECTED-WINDOWS,
but that should have all the ones of any interest." indeed!
SYS:FIND-WINDOW-OF-FLAVOR is the function that implements the Select
key. For its purpose, the windows in PREVIOUSLY-SELECTED-WINDOWS should
be sufficient. It has no need to find non-top-level windows, for
instance. The name PREVIOUSLY-SELECTED-WINDOWS, by the way, is a
misnomer; it includes windows that have never actually been selected.
The only selectable window that's not in it is the currently selected
window.
A similar function is TV:SELECTABLE-WINDOWS. This is the function used
to produce the list used by the [Select] item in the System Menu. It
includes the current window, as well.
barmar