puzzle.el.

puzzle.el.

[Matt Hodges]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

After playing around with insert-sliced-image, I wrote a slide puzzle
program (see attached).

If the number of image slices is too large, Emacs can crash in the
redisplay code. Evaluating the following:

    (let ((puzzle-max-rows-columns 25)
          (puzzle-rows 25)
          (puzzle-columns 25))
      (fset 'puzzle-randomize (lambda ()))
      (puzzle))

leads to a segmentation fault, and the following backtrace:

    #0  0x080aaa21 in display_line (it=0xbfffe490) at xdisp.c:14527
    #1  0x080a5e48 in try_window (window=141168948, pos={charpos = -1073748848, bytepos = 1}) at xdisp.c:12219
    #2  0x080a56c4 in redisplay_window (window=141168948, just_this_one_p=0) at xdisp.c:11861
    #3  0x080a1833 in redisplay_window_0 (window=2761) at xdisp.c:10587
    #4  0x08189a54 in internal_condition_case_1 (bfun=0x80a1800 <redisplay_window_0>, arg=141168948, handlers=138528965, hfun=0x80a17e0 <redisplay_window_error>) at eval.c:1376
    #5  0x080a17de in redisplay_windows (window=141168948) at xdisp.c:10566
    #6  0x080a0949 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10151
    #7  0x0809f802 in redisplay () at xdisp.c:9385
    #8  0x08129a65 in read_char (commandflag=1, nmaps=2, maps=0xbffff3ec, prev_event=138502161, used_mouse_menu=0xbffff428) at keyboard.c:2518
    #9  0x08130553 in read_key_sequence (keybuf=0xbffff550, bufsize=30, prompt=138502161, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8810
    #10 0x08126593 in command_loop_1 () at keyboard.c:1512
    #11 0x0818994e in internal_condition_case (bfun=0x81263d0 <command_loop_1>, handlers=138563089, hfun=0x8125e90 <cmd_error>) at eval.c:1335
    #12 0x081261fe in command_loop_2 () at keyboard.c:1293
    #13 0x0818948b in internal_catch (tag=2761, func=0x81261d0 <command_loop_2>, arg=138502161) at eval.c:1096
    #14 0x081261a3 in command_loop () at keyboard.c:1272
    #15 0x08125c14 in recursive_edit_1 () at keyboard.c:978
    #16 0x08125d51 in Frecursive_edit () at keyboard.c:1039
    #17 0x08124410 in main (argc=5, argv=0xbffffc04) at emacs.c:1687

In the code, I create a blank image with the following:

    (create-image "" 'xpm nil :width (/ width puzzle-columns)
                              :height (/ height puzzle-rows))

which does what I want, but complains with:

    Cannot find image file `'

which seems fair enough. Is there a better way to do this?

On an unrelated note, I find the doc string for random to be
confusing:

    With positive integer argument n, return random number in interval
    [0,n).

Does this really mean between 0 and (n - 1)? The info documentation is
clearer:

    If LIMIT is a positive integer, the value is chosen to be
    nonnegative and less than LIMIT.

Thanks for any feedback on these issues.

Matt


[-- Attachment #2: slide puzzle. --]
[-- Type: application/emacs-lisp, Size: 12823 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: puzzle.el.

[Kim F. Storm]

Matt Hodges <matt@stchem.bham.ac.uk> writes:

> After playing around with insert-sliced-image, I wrote a slide puzzle
> program (see attached).
> 
> If the number of image slices is too large, Emacs can crash in the
> redisplay code. Evaluating the following:
> 
>     (let ((puzzle-max-rows-columns 25)
>           (puzzle-rows 25)
>           (puzzle-columns 25))
>       (fset 'puzzle-randomize (lambda ()))
>       (puzzle))
> 
> leads to a segmentation fault, and the following backtrace:
> 
>     #0  0x080aaa21 in display_line (it=0xbfffe490) at xdisp.c:14527
>     #1  0x080a5e48 in try_window (window=141168948, pos={charpos = -1073748848, bytepos = 1}) at xdisp.c:12219
>     #2  0x080a56c4 in redisplay_window (window=141168948, just_this_one_p=0) at xdisp.c:11861


The problem is that the window's "glyph matrix" is too small.

The height and width of the glyph matrix is calculated from the smallest font that is available on the window's frame.

For example, if the smallest font is 10x10 and your window is 600x800, you will get a glyph matrix of approx 60x80.
Now, if you use a sliced image (or just many images which are less than 10x10 in size, you can easily fill the
window with more than those 60x80 glyphs.

Since there is no bounds checking on inserting into a glyph matrix, emacs eventually traps in such cases.

I will see if there is a trivial fix...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: puzzle.el.

[Matt Hodges]

>>>>> Kim F Storm writes:

 > > If the number of image slices is too large, Emacs can crash in
 > > the redisplay code. Evaluating the following:

[...]

 > The problem is that the window's "glyph matrix" is too small.

 > The height and width of the glyph matrix is calculated from the
 > smallest font that is available on the window's frame.

 > For example, if the smallest font is 10x10 and your window is
 > 600x800, you will get a glyph matrix of approx 60x80. Now, if you
 > use a sliced image (or just many images which are less than 10x10
 > in size, you can easily fill the window with more than those 60x80
 > glyphs.

 > Since there is no bounds checking on inserting into a glyph matrix,
 > emacs eventually traps in such cases.

So I could guess, programmatically, when this might fail. font-info
looks relevant, but I think there is a bug in the documentation; the
reference to CHARSET is obsolete?

 > I will see if there is a trivial fix...

Thanks for taking a look.

Matt

Re: puzzle.el.

[Richard Stallman]

    For example, if the smallest font is 10x10 and your window is 600x800, you will get a glyph matrix of approx 60x80.
    Now, if you use a sliced image (or just many images which are less than 10x10 in size, you can easily fill the
    window with more than those 60x80 glyphs.

Maybe redisplay should notice when it encounters a glyph below
the size that was used for the calculation of the glyph matrix,
and enlarge the glyph matrix at that point.

Re: puzzle.el.

[Miles Bader]

On Mon, Jul 19, 2004 at 02:44:54PM -0400, Richard Stallman wrote:
> Maybe redisplay should notice when it encounters a glyph below
> the size that was used for the calculation of the glyph matrix,
> and enlarge the glyph matrix at that point.

Yes; note that this same problem occurs when using variable-width fonts.

-Miles
-- 
Fast, small, soon; pick any 2.

Re: puzzle.el.

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Mon, Jul 19, 2004 at 02:44:54PM -0400, Richard Stallman wrote:
> > Maybe redisplay should notice when it encounters a glyph below
> > the size that was used for the calculation of the glyph matrix,
> > and enlarge the glyph matrix at that point.
> 
> Yes; note that this same problem occurs when using variable-width fonts.

The changes I have installed also addresses that problem.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: puzzle.el.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     For example, if the smallest font is 10x10 and your window is 600x800, you will get a glyph matrix of approx 60x80.
>     Now, if you use a sliced image (or just many images which are less than 10x10 in size, you can easily fill the
>     window with more than those 60x80 glyphs.
> 
> Maybe redisplay should notice when it encounters a glyph below
> the size that was used for the calculation of the glyph matrix,
> and enlarge the glyph matrix at that point.


It is simpler to increase the matrix size when we try to exceed the current size.

I have just installed (fairly simple) changes to accomplish that.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: puzzle.el.

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> It is simpler to increase the matrix size when we try to exceed the current size.
>
> I have just installed (fairly simple) changes to accomplish that.

Wow thanks Kim, that works a treat!

Now a line full of lower-case variable-pitch "i"s displays correctly in
my "80-character-wide" windows...

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: puzzle.el.

[Miles Bader]

BTW, the biggest win of this change for me is with mode-lines -- they're
natural for using a variable pitch font (alignment doesn't matter), they
can be very long, and the info at the end is often significant...

Before, variable-pitch mode-lines would get strangely cut off but now
they work perfectly.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: puzzle.el.

[Richard Stallman]

    It is simpler to increase the matrix size when we try to exceed
    the current size.  I have just installed (fairly simple) changes
    to accomplish that.

Thanks for taking care of this.  I am glad this embarrassing flaw is
gone now.

Re: puzzle.el.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     It is simpler to increase the matrix size when we try to exceed
>     the current size.  I have just installed (fairly simple) changes
>     to accomplish that.
> 
> Thanks for taking care of this.  I am glad this embarrassing flaw is
> gone now.

Since the modelines very much tend to be too long in a number of
occasions, and since I don't think that it usually contains any
tabulated stuff, could it be a good idea to let the modeline face
inherit from variable-pitch?  Or have some other font that does not
run as wide?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: puzzle.el.

[Kevin Rodgers]

Matt Hodges wrote:
 > In the code, I create a blank image with the following:
 >
 >     (create-image "" 'xpm nil :width (/ width puzzle-columns)
 >                               :height (/ height puzzle-rows))
 >
 > which does what I want, but complains with:
 >
 >     Cannot find image file `'
 >
 > which seems fair enough. Is there a better way to do this?

According to create-image's doc string:

| Optional DATA-P non-nil means FILE-OR-DATA is a string containing image data.

the DATAP argument should be non-nil:

     (create-image "" 'xpm t :width (/ width puzzle-columns)
                             :height (/ height puzzle-rows))

or maybe you could specify an empty file:

     (create-image null-device 'xpm nil :width (/ width puzzle-columns)
                                        :height (/ height puzzle-rows))

-- 
Kevin Rodgers

Re: puzzle.el.

[Matt Hodges]

>>>>> Kevin Rodgers writes:

 > According to create-image's doc string:
 > | Optional DATA-P non-nil means FILE-OR-DATA is a string containing
 > | image data.

 > the DATAP argument should be non-nil:

 >      (create-image "" 'xpm t :width (/ width puzzle-columns)
 >                              :height (/ height puzzle-rows))

 > or maybe you could specify an empty file:

 >      (create-image null-device 'xpm nil :width (/ width puzzle-columns)
 >                                         :height (/ height puzzle-rows))

These also work, but with "Invalid XPM file..." messages.

The XPM format is so simple that I could just generate what I need on
the fly, if I really don't want to see such messages, or if I find
that the above doesn't actually work under certain circumstances.

Thanks,

Matt