[patch] XPM in gamegrid.el

[patch] XPM in gamegrid.el

[Oliver Scholz]

Hello!

The XPM stuff in gamegrid.el does not work in Emacs 21.2. Obviously it
is meant for XEmacs.

I have fixed this. With the following patch gamegrid packages like
`snake' and `tetris' display the nice XPM grids. Furthermore: I have
added XBM-grids for Emacsen that are not compiled with the XPM
library.

And very important: You can play Sokoban with graphics! :-)

    -- Oliver

--- /usr/local/share/emacs/21.2/lisp/play/gamegrid.el	Tue May  7 23:18:49 2002
+++ gamegrid.el	Mon Jul  1 15:45:24 2002
@@ -42,6 +42,10 @@
 (defvar gamegrid-font "-*-courier-medium-r-*-*-*-140-100-75-*-*-iso8859-*"
   "Name of the font used in X mode.")
 
+(defvar gamegrid-face nil
+  "Indicates the face to use as a default.")
+(make-variable-buffer-local 'gamegrid-face)
+
 (defvar gamegrid-display-options nil)
 
 (defvar gamegrid-buffer-width 0)
@@ -115,6 +119,16 @@
 "
   "XPM format image used for each square")
 
+(defvar gamegrid-xbm "\
+/* gamegrid XBM */
+#define gamegrid_width 16
+#define gamegrid_height 16
+static unsigned char gamegrid_bits[] = {
+   0xff, 0xff, 0xff, 0x7f, 0xff, 0x3f, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a,
+   0x57, 0x15, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a, 0x57, 0x15, 0xaf, 0x0a,
+   0x57, 0x15, 0x07, 0x00, 0x03, 0x00, 0x01, 0x00 };"
+  "XBM format image used for each square.")
+
 ;; ;;;;;;;;;;;;;;;; miscellaneous functions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
 (defsubst gamegrid-characterp (arg)
@@ -166,10 +180,10 @@
     face))
 
 (defun gamegrid-make-color-tty-face (color)
-  (let* ((color-str (symbol-value color))
-	 (name (intern (format "gamegrid-color-tty-face-%s" color-str)))
+  (let* (;(color-str (symbol-value color))
+	 (name (intern (format "gamegrid-color-tty-face-%s" color)))
 	 (face (make-face name)))
-    (gamegrid-setup-face face color-str)
+    (gamegrid-setup-face face color)
     face))
 
 (defun gamegrid-make-grid-x-face ()
@@ -215,13 +229,16 @@
        gamegrid-mono-tty-face))))
 
 (defun gamegrid-colorize-glyph (color)
-  (make-glyph
-   (vector
-    'xpm
-    :data gamegrid-xpm
-    :color-symbols (list (cons "col1" (gamegrid-color color 0.6))
-			 (cons "col2" (gamegrid-color color 0.8))
-			 (cons "col3" (gamegrid-color color 1.0))))))
+  (find-image `((:type xpm :data ,gamegrid-xpm
+		       :ascent center
+		       :color-symbols 
+		       (("col1" . ,(gamegrid-color color 0.6))
+			("col2" . ,(gamegrid-color color 0.8))
+			("col3" . ,(gamegrid-color color 1.0))))
+		(:type xbm :data ,gamegrid-xbm
+		       :ascent center
+		       :foreground ,(gamegrid-color color 1.0)
+		       :background ,(gamegrid-color color 0.5)))))
 
 (defun gamegrid-match-spec (spec)
   (let ((locale (car spec))
@@ -245,38 +262,35 @@
 	   (vector data))
 	  ((eq data 'colorize)
 	   (gamegrid-colorize-glyph color))
+	  ((listp data)
+	   (find-image data)) ;untested!
 	  ((vectorp data)
-	   (make-glyph data)))))
+	   (gamegrid-make-image-from-vector data)))))
 
-(defun gamegrid-color-display-p ()
-  (if (fboundp 'device-class)
-      (eq (device-class (selected-device)) 'color)
-    (eq (cdr-safe (assq 'display-type (frame-parameters))) 'color)))
+(defun gamegrid-make-image-from-vector (vect)
+  "Convert an XEmacs style \"glyph\" to an image-spec."
+  (let ((l (list 'image :type)))
+    (dotimes (n (length vect))
+      (setf l (nconc l (list (aref vect n)))))
+    (nconc l (list :ascent 'center))))
 
 (defun gamegrid-display-type ()
-  (let ((window-system-p 
-	 (or (and (fboundp 'console-on-window-system-p)
-		  (console-on-window-system-p))
-	     (and (fboundp 'display-color-p)
-		  (display-color-p))
-	     window-system)))
   (cond ((and gamegrid-use-glyphs
-		window-system-p
-	      (featurep 'xpm))
+	      (display-images-p))
 	 'glyph)
 	((and gamegrid-use-color
-		window-system-p
-	      (gamegrid-color-display-p))
+	      (display-graphic-p)
+	      (display-color-p))
 	 'color-x)
-	  (window-system-p
+	((display-graphic-p)
 	 'mono-x)
 	((and gamegrid-use-color
-	      (gamegrid-color-display-p))
+	      (display-color-p))
 	 'color-tty)
-	((fboundp 'set-face-property)
+	((display-multi-font-p) ;???
 	 'mono-tty)
 	(t
-	   'emacs-tty))))
+	   'emacs-tty)))
 
 (defun gamegrid-set-display-table ()
   (if (fboundp 'specifierp)
@@ -292,21 +306,20 @@
       (set-specifier text-cursor-visible-p nil (current-buffer))))
 
 (defun gamegrid-setup-default-font ()
-  (cond ((eq gamegrid-display-mode 'glyph)
-	 (let* ((font-spec (face-property 'default 'font))
-		(name (font-name font-spec))
-		(max-height nil))
-	   (loop for c from 0 to 255 do
-	     (let ((glyph (aref gamegrid-display-table c)))
-	       (cond ((glyphp glyph)
-		      (let ((height (glyph-height glyph)))
-			(if (or (null max-height)
-				(< max-height height))
-			    (setq max-height height)))))))
-	   (if max-height
-	       (while (and (> (font-height font-spec) max-height)
-			   (setq name (x-find-smaller-font name)))
-		 (add-spec-to-specifier font-spec name (current-buffer))))))))
+  (setq gamegrid-face
+	(copy-face 'default
+		   (intern (concat "gamegrid-face-" (buffer-name)))))
+  (when (eq gamegrid-display-mode 'glyph)
+    (let ((max-height nil))
+      (loop for c from 0 to 255 do
+	    (let ((glyph (aref gamegrid-display-table c)))
+	      (when (and (listp glyph) (eq (car  glyph) 'image))
+		(let ((height (cdr (image-size glyph))))
+		  (if (or (null max-height)
+			  (< max-height height))
+		      (setq max-height height))))))
+      (when (and max-height (< max-height 1))
+	(set-face-attribute gamegrid-face nil :height max-height)))))
 
 (defun gamegrid-initialize-display ()
   (setq gamegrid-display-mode (gamegrid-display-type))
@@ -324,7 +337,9 @@
 
 
 (defun gamegrid-set-face (c)
-  (unless (eq gamegrid-display-mode 'glyph)
+  (if (eq gamegrid-display-mode 'glyph)
+      (add-text-properties (1- (point)) (point)
+			   (list 'display (list (aref gamegrid-display-table c))))
     (put-text-property (1- (point))
 		       (point)
 		       'face
@@ -351,14 +366,18 @@
 (defun gamegrid-init-buffer (width height blank)
   (setq gamegrid-buffer-width width
 	gamegrid-buffer-height height)
-  (let ((line (concat
-	       (make-string width blank)
-	       "\n"))
+  (let ((line (concat (make-string width blank) "\n"))
 	(buffer-read-only nil))
     (erase-buffer)
     (setq gamegrid-buffer-start (point))
     (dotimes (i height)
-      (insert-string line))
+      (insert line))
+    ;; Adjust the height of the default face to the height of the
+    ;; images. Unlike XEmacs, Emacs doesn't allow to make the default
+    ;; face buffer-local; so we do this with an overlay.
+    (when (eq gamegrid-display-mode 'glyph)
+      (overlay-put (make-overlay (point-min) (point-max))
+		   'face gamegrid-face))
     (goto-char (point-min))))
 
 (defun gamegrid-init (options)

-- 
Oliver Scholz               13 Messidor an 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.
Tel. (069) 97 40 99 42

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

Thanks for taking the initiative to work on this.
A comment I saw raises a question:

    +    ;; Adjust the height of the default face to the height of the
    +    ;; images. Unlike XEmacs, Emacs doesn't allow to make the default
    +    ;; face buffer-local; so we do this with an overlay.

Why would it be useful to make the default face buffer-local
rather than simply specifying a different face on the text?
(such as with a text property)?

Re: [patch] XPM in gamegrid.el

[Oliver Scholz]

Richard Stallman <rms@gnu.org> writes:

> A comment I saw raises a question:
>
>     +    ;; Adjust the height of the default face to the height of the
>     +    ;; images. Unlike XEmacs, Emacs doesn't allow to make the default
>     +    ;; face buffer-local; so we do this with an overlay.
>
> Why would it be useful to make the default face buffer-local
> rather than simply specifying a different face on the text?
> (such as with a text property)?

A different face is necessary when the images are smaller in height
than the default face. Otherwise there would be an ugly space between
lines of grids.

Packages (games) that use gamegrid.el are supposed to change the
buffer via the function `gamegrid-set-cell'. To use text properties
instead of an overlay wouldn't take more than a simple change to this
functions. I used an overlay mainly because I am not sure if all
existing games refrain from using a simple `insert' or `insert-char'
somewhere to put text into the buffer. This would not inherit the text
property then. I wanted to emulate the behaviour of XEmacs as close as
possible, since so far all XPM stuff in games was designed for
XEmacs. Do you think I should change this?

To have true buffer local faces would be nice. It is absolutely
possible that different heights are necessary for different games. I
emulated buffer local faces by creating faces whose name-symbols
contain the buffer name (gamegrid does already something similar for
the color-faces) and that are accessible via the buffer-local variable
`gamegrid-face'.

BTW: I'd like to write a few comments and document strings and a
commentary section for gamegrid.el. After all it is a _library_ and I
don't think that it is good, if everyone who wants to use it has to
read the full source first. I'd like to have a few more games in Emacs
for the moments of rethinking and recreation while I am actually
working and writing in a different buffer. Of course, my English is
lousy, but it is probably better than nothing. Is this o.k. for you?

    -- Oliver

-- 
Oliver Scholz               15 Messidor an 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.
Tel. (069) 97 40 99 42

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

    Packages (games) that use gamegrid.el are supposed to change the
    buffer via the function `gamegrid-set-cell'. To use text properties
    instead of an overlay wouldn't take more than a simple change to this
    functions. I used an overlay mainly because I am not sure if all
    existing games refrain from using a simple `insert' or `insert-char'
    somewhere to put text into the buffer. This would not inherit the text
    property then.

I see.  Maybe we should have a way for the buffer to choose
a default face.

    To have true buffer local faces would be nice.

Buffer local *face definitions* would be rather hairy.  Do we need
them?  It could be a lot easier to have a variable whose value
specifies the name of the default face, and then you could give
that variable a buffer-local value.  Is it really useful to
give the same face name various buffer-local definitions?

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

    BTW: I'd like to write a few comments and document strings and a
    commentary section for gamegrid.el. After all it is a _library_ and I
    don't think that it is good, if everyone who wants to use it has to
    read the full source first.

Please do!  Once you write down correct information, lots of other
people would be able to fix up the English usage.

Re: [patch] XPM in gamegrid.el

[Stefan Monnier]

>     To have true buffer local faces would be nice.
> Buffer local *face definitions* would be rather hairy.

I have no understanding of how difficult it would be to implement,
but at least from a user perspective, I don't see why it would be hairy.

I know that I've never understood the point of having frame-local
face definitions, whereas the need for buffer-local face definitions
has shown up every once in a while.


	Stefan

Re: [patch] XPM in gamegrid.el

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> I know that I've never understood the point of having frame-local
> face definitions

It's quite handy for `special' frames, e.g., I sometimes use a `Calc'
frame which is very small but with a huge default face, and only keep a
Calc buffer in it (similarly for tooltip frames, etc).

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: [patch] XPM in gamegrid.el

[epameinondas]

Richard Stallman <rms@gnu.org> writes:
[...]
> I see.  Maybe we should have a way for the buffer to choose
> a default face.
>
>     To have true buffer local faces would be nice.
>
> Buffer local *face definitions* would be rather hairy.  Do we need
> them?  It could be a lot easier to have a variable whose value
> specifies the name of the default face, and then you could give
> that variable a buffer-local value.  Is it really useful to
> give the same face name various buffer-local definitions?

To have a variable would be enough for most purposes I can think
of. It surely is enough for gamegrid.

Another thing, BTW, that should be buffer-local rather than frame
local is the frame parameter `cursor-type'. I am mainly thinking of
the ability to turn the cursor off via 

(modify-frame-parameters nil '((cursor-type . nil)))

gamegrid.el provides a function that turns the cursor off in XEmacs. I
have not enabled this, of course, because it should only apply to the
game buffer.

[Other cases where I, as a User, would like to turn the cursor off are
dired or the *Group* and *Article* buffers in Gnus. I'd prefer to use
the line highlighting facility provided by `hl-line-mode' to select
things.]


    -- Oliver

-- 
Oliver Scholz               17 Messidor an 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.
Tel. (069) 97 40 99 42

Re: [patch] XPM in gamegrid.el

[John Paul Wallington]

epameinondas@gmx.de wrote:

> Another thing, BTW, that should be buffer-local rather than frame
> local is the frame parameter `cursor-type'.

Doesn't 

(setq cursor-type nil)

do what you want?

;-)

-- 
John Paul Wallington

Re: [patch] XPM in gamegrid.el

[Miles Bader]

epameinondas@gmx.de writes:
> gamegrid.el provides a function that turns the cursor off in XEmacs. I
> have not enabled this, of course, because it should only apply to the
> game buffer.

You can do this in emacs by setting the variable `cursor-type' to nil.
It's a buffer-local variable, so that setting will only affect the
gamegrid buffer.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: [patch] XPM in gamegrid.el

[Per Abrahamsen]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> I know that I've never understood the point of having frame-local
> face definitions,

If one frame use a dark background, and another use a a light
background.

If the frames are one different screens, maybe even one being a
termcap frame and the other an X11 frame.

Re: [patch] XPM in gamegrid.el

[Oliver Scholz]

Miles Bader <miles@lsi.nec.co.jp> writes:

> epameinondas@gmx.de writes:
>> gamegrid.el provides a function that turns the cursor off in XEmacs. I
>> have not enabled this, of course, because it should only apply to the
>> game buffer.
>
> You can do this in emacs by setting the variable `cursor-type' to nil.
> It's a buffer-local variable, so that setting will only affect the
> gamegrid buffer.
[...]

(!!!)

I missed that part about the variable in the Elisp Reference, as it
seems. Thank you and sorry for the noise. I'll change this and send it
to you together with a patch for documentation-strings and comments in
a week or two.


    -- Oliver

-- 
Oliver Scholz               17 Messidor an 210 de la Révolution
Taunusstr. 25               Liberté, Egalité, Fraternité!
60329 Frankfurt a. M.
Tel. (069) 97 40 99 42

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

    I know that I've never understood the point of having frame-local
    face definitions, whereas the need for buffer-local face definitions
    has shown up every once in a while.

I don't see much use for frame-local face definitions either.  The reason
the feature exists is that it was included in the original faces code
that I got from Lucid Emacs way back when.

Perhaps we should ask if anyone has ever used them, and consider
replacing this feature with buffer-local face definitions.

Miles wrote:

    It's quite handy for `special' frames, e.g., I sometimes use a `Calc'
    frame which is very small but with a huge default face, and only keep a
    Calc buffer in it (similarly for tooltip frames, etc).

Miles, would a buffer-local face definition work just as well for this
job?

Re: [patch] XPM in gamegrid.el

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Miles wrote:
> 
>     It's quite handy for `special' frames, e.g., I sometimes use a `Calc'
>     frame which is very small but with a huge default face, and only keep a
>     Calc buffer in it (similarly for tooltip frames, etc).
> 
> Miles, would a buffer-local face definition work just as well for this
> job?

I think _mostly_ -- but:

  1) Sometimes (such as in my Calc example) you want the minibuffer to
     use the same modified default face as the buffer, but only in that
     frame.

  2) The current display code calculates window sizes (and the tool-bar
     size) in integral multiples of the frame's default font, so there
     might be unpleasant artifacts from having that be different from
     the displayed buffer's default font (e.g., fractional lines
     displayed, minibuffer size jumpiness).

     Of course ideally this limitation on window sizes will just be
     removed.

-miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: [patch] XPM in gamegrid.el

[Miles Bader]

BTW, I want to say I think replacing frame-specific faces with
buffer-specific faces would be a fantastic idea.  The frame-specific
nature of faces is the cause of much confusion for new users (it seems
like half the postings to the emacs newsgroups are of the form `why
doesn't my change affect new frames').

I think almost all the uses of frame-specific faces are by mode-authors
for specialized modes such as speedbar, etc., and that 99% of those uses
could be simply replaced by buffer-specific faces (and the latter would
in fact probably make the mode author's job easier, since his special
faces would work even in normal frames).

In fact, if we want to make this change, I'll offer my help to do it
(crossing my fingers that it's not _too_ hairy...).

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

    If one frame use a dark background, and another use a a light
    background.

The background is specified by the definition of the face `default'.
So this application for frame-local face definitions would only arise
if people use frame-local definitions for `default'.

    If the frames are one different screens, maybe even one being a
    termcap frame and the other an X11 frame.

Right now this is not implemented, but we want to support it.  I guess
that means we do need to support frame-local face definitions.

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

      1) Sometimes (such as in my Calc example) you want the minibuffer to
	 use the same modified default face as the buffer, but only in that
	 frame.

Do we always want this?  Should the minibuffer use the face definitions
of the main buffer?

      2) The current display code calculates window sizes (and the tool-bar
	 size) in integral multiples of the frame's default font, 

Removing that limitation is in the task list.  Would someone
like to work on it?

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

    In fact, if we want to make this change, I'll offer my help to do it
    (crossing my fingers that it's not _too_ hairy...).

Thank you very much!

Re: [patch] XPM in gamegrid.el

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>       1) Sometimes (such as in my Calc example) you want the
> 	 minibuffer to use the same modified default face as the buffer,
> 	 but only in that frame.
> 
> Do we always want this?  Should the minibuffer use the face definitions
> of the main buffer?

What's `the main buffer'?  In my example, that's clear to _me_, but I'm
not sure there's any way emacs could figure it out, unless told
explicitly.

If you meant that the minibuffer, when activated, would use face
definitions from the current buffer, I think that's probably a bad idea:
(1) it would mean that the size of the empty minibuffer window might be
different than that of an active minibuffer (causing annoying jumping),
and (2) the default face might change depending on the current buffer,
and I think people generally think of the minibuffer as being attached
global (part of the frame), so that would seem like very odd behavior.

But I think my Calc examples is somewhat atypical.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: [patch] XPM in gamegrid.el

[Miles Bader]

For making faces buffer-local, I think it would be nice if we could
somehow use emacs' variable mechanism, since it already allows both
buffer-local and frame-local values, and is fairly featureful and
familiar to developers.

One suggestion I made a while ago would be to have face names be global,
but to allow a remapping step via a variable, which the programmer could
use to select a different face, for instance, if it were an alist
[maybe a hash-table etc would also be good], you might do:

  (setq face-remappings '((default . my-buffer-default)))

to give your buffer a different default face.

I remember when I suggested this idea before, Gerd didn't like it, but
unfortunately, I don't remember his reasons; does anyone else?

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: [patch] XPM in gamegrid.el

[Richard Stallman]

    >       1) Sometimes (such as in my Calc example) you want the
    > 	 minibuffer to use the same modified default face as the buffer,
    > 	 but only in that frame.
    > 
    > Do we always want this?  Should the minibuffer use the face definitions
    > of the main buffer?

    What's `the main buffer'?

The simplest definition is, the buffer that was current when you
issued the command.

    But I think my Calc examples is somewhat atypical.

Should that Calc example do something special to copy the face
definitions from the current buffer?

Re: [patch] XPM in gamegrid.el

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     > Do we always want this?  Should the minibuffer use the face definitions
>     > of the main buffer?
> 
> The simplest definition is, the buffer that was current when you
> issued the command.

Hmm, well, see the rest of that same message for reason why I think
that's not a good thing.

>     But I think my Calc examples is somewhat atypical.
> 
> Should that Calc example do something special to copy the face
> definitions from the current buffer?

That would be an acceptable solution, certainly (I already do a bunch of
junk to setup this special calc frame, so it's not a problem to a little
more).

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.