[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