"Attempt to modify read-only object" error with set-frame-configuration

"Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

With Emacs -Q evaluating the form

(let ((cfg (current-frame-configuration)))
   (set-frame-configuration cfg))

I am told

Debugger entered--Lisp error: (error "Attempt to modify read-only object")
   modify-frame-parameters(#<frame EMACS@MACHNO 0x1ae2400> ((parent-id) (explicit-name) (display . "") (icon-name) (window-id . "2224") (top . 100) (left . 100) (buried-buffer-list) (buffer-list #<buffer *scratch*>) (unsplittable) (modeline 
. t) (width . 80) (height . 42) (environment) (background-mode . light) (display-type . color) (right-fringe . 10) (left-fringe . 10) (right-fringe) (left-fringe) (horizontal-scroll-bars . t) (window-system . w32) (visibility . t) 
(scroll-bar-width . 20) (cursor-type . box) (auto-lower) (auto-raise) (icon-type) (title) (buffer-predicate) (tool-bar-lines . 2) (menu-bar-lines . 1) (right-fringe) (left-fringe) (line-spacing) (screen-gamma) (border-color . "black") 
(cursor-color . "black") (mouse-color . "black") (background-color . "SystemWindow") (foreground-color . "SystemWindowText") (vertical-scroll-bars . right) (internal-border-width . 0) (border-width . 2) (font . "-outline-Courier 
New-normal-r-normal-normal-16-96-120-120-c-*-iso8859-1")))
   set-frame-configuration((frame-configuration (#<frame EMACS@MACHNO 0x1ae2400> (... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ...) #<window-configuration>)))
   (let ((cfg ...)) (set-frame-configuration cfg))
   eval((let ((cfg ...)) (set-frame-configuration cfg)))
   eval-last-sexp-1(nil)
   eval-last-sexp(nil)
   call-interactively(eval-last-sexp)

Can anyone reproduce that?


In GNU Emacs 23.0.50.1 (i386-mingw-windows98.3000)
  of 2007-12-04 on MACHNO
Windowing system distributor `Microsoft Corp.', version 4.90.3000
configured using `configure --with-gcc (3.4)'

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: dea
   locale-coding-system: cp1252
   default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   tool-bar-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   line-number-mode: t

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Andreas Schwab]

martin rudalics <rudalics@gmx.at> writes:

> With Emacs -Q evaluating the form
>
> (let ((cfg (current-frame-configuration)))
>   (set-frame-configuration cfg))
>
> I am told
>
> Debugger entered--Lisp error: (error "Attempt to modify read-only object")
>
> Can anyone reproduce that?
>
> In GNU Emacs 23.0.50.1 (i386-mingw-windows98.3000)

Works fine on powerpc-suse-linux-gnu.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Stephen Berman]

On Wed, 19 Dec 2007 22:47:13 +0100 Andreas Schwab <schwab@suse.de> wrote:

> martin rudalics <rudalics@gmx.at> writes:
>
>> With Emacs -Q evaluating the form
>>
>> (let ((cfg (current-frame-configuration)))
>>   (set-frame-configuration cfg))
>>
>> I am told
>>
>> Debugger entered--Lisp error: (error "Attempt to modify read-only object")
>>
>> Can anyone reproduce that?
>>
>> In GNU Emacs 23.0.50.1 (i386-mingw-windows98.3000)
>
> Works fine on powerpc-suse-linux-gnu.

Also works fine with GNU Emacs 22.1.1 (i586-suse-linux-gnu, GTK+ Version
2.12.0) of 2007-11-24 on dede and with GNU Emacs 23.0.50.1
(i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2007-12-09 on escher

Steve Berman

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Johan Bockgård]

martin rudalics <rudalics@gmx.at> writes:

> Can anyone reproduce that?

Is it the same bug as this (also on Windows)?:

Does not accept "visibility" in default-frame-alist
http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg01039.html

visibility not allowed in default-frame-alist
http://lists.gnu.org/archive/html/emacs-devel/2007-08/msg01534.html

-- 
Johan Bockgård

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Juanma Barranquero]

On Dec 19, 2007 10:32 PM, martin rudalics <rudalics@gmx.at> wrote:

> (visibility . t)

I'd bet this causes the bug. Setting visibility causes problems on
Windows since the multi-tty merge. See

http://thread.gmane.org/gmane.emacs.devel/77325

             Juanma

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

 >>(visibility . t)
 >
 >
 > I'd bet this causes the bug. Setting visibility causes problems on
 > Windows since the multi-tty merge. See

Hmm ...  Why does Emacs -Q and evaluating

(setq default-frame-alist '((visibility . t)))

not cause the problem?  Why does removing the visibility entry from
`parms' in `set-frame-configuration' still cause the problem?

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Juanma Barranquero]

On Dec 20, 2007 10:59 AM, martin rudalics <rudalics@gmx.at> wrote:

> Hmm ...  Why does Emacs -Q and evaluating
>
> (setq default-frame-alist '((visibility . t)))
>
> not cause the problem?  Why does removing the visibility entry from
> `parms' in `set-frame-configuration' still cause the problem?

That's why I said "I'd bet": because I had not tested. :)

Try this:

(let* ((cfg (current-frame-configuration))
       (atr (cdadr cfg)))
  (setcar atr (assq-delete-all 'horizontal-scroll-bars (car atr)))
  (setcar atr (assq-delete-all 'visibility (car atr)))
  (set-frame-configuration cfg))

             Juanma

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

 > Try this:
 >
 > (let* ((cfg (current-frame-configuration))
 >        (atr (cdadr cfg)))
 >   (setcar atr (assq-delete-all 'horizontal-scroll-bars (car atr)))
 >   (setcar atr (assq-delete-all 'visibility (car atr)))
 >   (set-frame-configuration cfg))

Splendid!  Where can we fix this (at least temporarily)?  In
x_set_frame_parameters?

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Juanma Barranquero]

On Dec 20, 2007 5:02 PM, martin rudalics <rudalics@gmx.at> wrote:

> Splendid!  Where can we fix this (at least temporarily)?  In
> x_set_frame_parameters?

I don't know. It broke with multi-tty, and multi-tty is not exactly
overdocumented, IIRC.

It'll be a horrible hack, though.

             Juanma

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

A related question: With Emacs -Q `frame-parameters' gives me three
entries for "right-fringe" and "left-fringe" each.  What's the idea
behind these?  Do you see these as well?

((parent-id)
  ...
  (right-fringe . 10)
  (left-fringe . 10)
  (right-fringe)
  (left-fringe)
  ...
  (right-fringe)
  (left-fringe)
  ...))

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Juanma Barranquero]

On Dec 20, 2007 7:36 PM, martin rudalics <rudalics@gmx.at> wrote:

> What's the idea behind these?

I don't think they are on purpose.

> Do you see these as well?

Yes. I see duplications for `height', `width', `left-fringe',
`right-fringe' and `vertical-scroll-bars'.

             Juanma

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Eli Zaretskii]

> Date: Thu, 20 Dec 2007 00:59:07 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> On Dec 19, 2007 10:32 PM, martin rudalics <rudalics@gmx.at> wrote:
> 
> > (visibility . t)
> 
> I'd bet this causes the bug. Setting visibility causes problems on
> Windows since the multi-tty merge. See
> 
> http://thread.gmane.org/gmane.emacs.devel/77325

I debugged this a bit.  The error is thrown from Fsetcdr, when it
checks its first arg `cell' for being pure.  Looking for the reason of
this, I found that Fsetcdr is called by store_frame_param in this
snippet (around line 2300 in frame.c):

  /* Update the frame parameter alist.  */
  old_alist_elt = Fassq (prop, f->param_alist);
  if (EQ (old_alist_elt, Qnil))
    f->param_alist = Fcons (Fcons (prop, val), f->param_alist);
  else
    Fsetcdr (old_alist_elt, val);

GDB shows that old_alist_elt's value is 18412069 decimal or 118f225
hex, which indeed seems to be in pure space.  The value of
f->param_alist includes `(visibility)', and I verified by stepping
into Fassq that it finds this element of the alist, and then this last
line of Fassq:

  return CAR (list);

returns the offending value of 18412069, as the car of this list:

  ((visibility) (scroll-bar-width) (cursor-type . box) (auto-lower) (auto-raise) (icon-type) (title) (buffer-predicate) (tool-bar-lines . 1) (menu-bar-lines . 1) (right-fringe) (left-fringe) (line-spacing) (screen-gamma) (border-color . "black") (cursor-color . "black") (mouse-color . "black") (background-color . "SystemWindow") (foreground-color . "SystemWindowText") (vertical-scroll-bars . right) (internal-border-width . 0) (border-width . 2) (font . "-outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1"))

This is where I ran out of time.  Someone, please continue debugging.
The way to reproduce this is to run Emacs under GDB with the following
command:

  (gdb) r -Q --eval "(setq default-frame-alist '((visibility . t)))"

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Richard Stallman]

    GDB shows that old_alist_elt's value is 18412069 decimal or 118f225
    hex, which indeed seems to be in pure space.  The value of
    f->param_alist includes `(visibility)', and I verified by stepping
    into Fassq that it finds this element of the alist, and then this last
    line of Fassq:

The bug is making that cons cell pure in the first place.
These cells are all meant to be setcdr'd.
So if you (someone) can find where that cons cell is made,
you will find the bug.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: lekktu@gmail.com, rudalics@gmx.at, emacs-devel@gnu.org
> Date: Sun, 23 Dec 2007 10:32:04 -0500
> 
>     GDB shows that old_alist_elt's value is 18412069 decimal or 118f225
>     hex, which indeed seems to be in pure space.  The value of
>     f->param_alist includes `(visibility)', and I verified by stepping
>     into Fassq that it finds this element of the alist, and then this last
>     line of Fassq:
> 
> The bug is making that cons cell pure in the first place.
> These cells are all meant to be setcdr'd.
> So if you (someone) can find where that cons cell is made,
> you will find the bug.

What about the fact that "xtype 18412069" says "int"? isn't that in
itself a manifestation of a bug?  I'd expect it to be a cons cell.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Richard Stallman]

    What about the fact that "xtype 18412069" says "int"? isn't that in
    itself a manifestation of a bug?  I'd expect it to be a cons cell.

That is a mystery to me, but we know the value IS a cons cell, right?
If it were not a cons cell, there would be a different error.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

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

 > This is where I ran out of time.  Someone, please continue debugging.

I was able to remove both bugs - the `horizontal-scroll-bars' and the
`visibility' related one - with the attached patch.  I'm not sure
whether this causes a supposedly invisible or iconified frame to appear
(shortly before the actual parameters are applied) but at least seems to
identify the origin of the bug.

[-- Attachment #2: frame-el.patch --]
[-- Type: text/plain, Size: 2105 bytes --]

*** frame.el.~1.265.~	Thu Nov 22 14:50:36 2007
--- frame.el	Mon Dec 24 22:49:32 2007
***************
*** 196,202 ****
  (defvar frame-initial-frame nil)
  
  ;; Record the parameters used in frame-initialize to make the initial frame.
! (defvar frame-initial-frame-alist)
  
  (defvar frame-initial-geometry-arguments nil)
  
--- 196,202 ----
  (defvar frame-initial-frame nil)
  
  ;; Record the parameters used in frame-initialize to make the initial frame.
! (defvar frame-initial-frame-alist nil)
  
  (defvar frame-initial-geometry-arguments nil)
  
***************
*** 221,236 ****
  	    (progn
  	      (setq frame-initial-frame-alist
  		    (append initial-frame-alist default-frame-alist nil))
- 	      (or (assq 'horizontal-scroll-bars frame-initial-frame-alist)
- 		  (setq frame-initial-frame-alist
- 			(cons '(horizontal-scroll-bars . t)
- 			      frame-initial-frame-alist)))
  	      (setq frame-initial-frame-alist
! 		    (cons (cons 'window-system initial-window-system)
! 			  frame-initial-frame-alist))
  	      (setq default-minibuffer-frame
  		    (setq frame-initial-frame
  			  (make-frame frame-initial-frame-alist)))
  	      ;; Delete any specifications for window geometry parameters
  	      ;; so that we won't reapply them in frame-notice-user-settings.
  	      ;; It would be wrong to reapply them then,
--- 221,237 ----
  	    (progn
  	      (setq frame-initial-frame-alist
  		    (append initial-frame-alist default-frame-alist nil))
  	      (setq frame-initial-frame-alist
! 		    (if (eq initial-window-system 'w32)
! 			(list (cons 'window-system initial-window-system)
! 			      (cons 'visibility t)
! 			      frame-initial-frame-alist)
! 		      (list (cons 'window-system initial-window-system)
! 			    frame-initial-frame-alist)))
  	      (setq default-minibuffer-frame
  		    (setq frame-initial-frame
  			  (make-frame frame-initial-frame-alist)))
+ 
  	      ;; Delete any specifications for window geometry parameters
  	      ;; so that we won't reapply them in frame-notice-user-settings.
  	      ;; It would be wrong to reapply them then,

[-- 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: "Attempt to modify read-only object" error with set-frame-configuration

[Eli Zaretskii]

> Date: Mon, 24 Dec 2007 23:05:07 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Juanma Barranquero <lekktu@gmail.com>,  emacs-devel@gnu.org
> 
> ! 		    (if (eq initial-window-system 'w32)
> ! 			(list (cons 'window-system initial-window-system)
> ! 			      (cons 'visibility t)
> ! 			      frame-initial-frame-alist)
> ! 		      (list (cons 'window-system initial-window-system)
> ! 			    frame-initial-frame-alist)))

Thanks.  However, I'm not sure this is right: why do we need to make
an explicit (visibility . t) element on w32, whereas on X we do not?

I think it would be useful to compare the values of the frame
parameters in Emacs 22 with what I have shown for the CVS code, and
find why it works in Emacs 22, but not in CVS.  Maybe then we will
understand what went wrong after the multi-tty merge.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

 > Thanks.  However, I'm not sure this is right: why do we need to make
 > an explicit (visibility . t) element on w32, whereas on X we do not?

By all means I never claimed that the patch would DTRT ;-).  Anyway,
before applying the patch I was able to create a new frame that behaved
correctly by calling

(x-create-frame-with-faces '((visibility . t)))

while that frame did _not_ behave correctly when I simply called

(x-create-frame-with-faces)

The problem doesn't seem to be with `x-create-frame-with-faces' not
calling `modify-frame-parameters' because with

	  (if (null visibility-spec)
	      (modify-frame-parameters frame '((visibility . t)))
	    (modify-frame-parameters frame (list visibility-spec)))

the initial frame gets killed immediately.  Hence the bug occurs before,
probably somewhere in `x_make_frame_visible' called by `x-create-frame',
but I simply fail to understand that code yet.

 > I think it would be useful to compare the values of the frame
 > parameters in Emacs 22 with what I have shown for the CVS code, and
 > find why it works in Emacs 22, but not in CVS.  Maybe then we will
 > understand what went wrong after the multi-tty merge.

Maybe the multi-tty merge just revealed an existing problem in the
Windows port.  BTW it should be _much_ simpler to analyze the
`horizontal-scroll-bars' problem first.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Eli Zaretskii]

> Date: Tue, 25 Dec 2007 10:23:25 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC:  lekktu@gmail.com,  emacs-devel@gnu.org
> 
> Maybe the multi-tty merge just revealed an existing problem in the
> Windows port.

It could be, but this, of course, does not help us debug the problem.

> BTW it should be _much_ simpler to analyze the
> `horizontal-scroll-bars' problem first.

Why do you think it's much simpler?

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

 >>BTW it should be _much_ simpler to analyze the
 >>`horizontal-scroll-bars' problem first.
 >
 >
 > Why do you think it's much simpler?

I guess because it has one clearly identifiable place where it gets set.
`frame-initialize' has

	      (or (assq 'horizontal-scroll-bars frame-initial-frame-alist)
		  (setq frame-initial-frame-alist
			(cons '(horizontal-scroll-bars . t)
			      frame-initial-frame-alist)))

and I don't have the slightest idea where and how visibility is set.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Richard Stallman]

    ! 		    (if (eq initial-window-system 'w32)
    ! 			(list (cons 'window-system initial-window-system)
    ! 			      (cons 'visibility t)
    ! 			      frame-initial-frame-alist)
    ! 		      (list (cons 'window-system initial-window-system)
    ! 			    frame-initial-frame-alist)))

Does that really need to be conditional on Windows?
If you specify visibility here on all systems,
that would be simpler.  Would it break anything?

Please install your patch, correcting that if appropriate.

There is still a mystery why visibility's cons cell is pure
without this, but we may as well fix the bug.

If you want to figure out the mystery, then take out this change, put
a breakpoint at the start of the primitive that creates the frame, and
see if its args include a cons cell for visibility.  If yes, is that
pure?  If yes, where was it made?  If it doesn't have a cons cell for
visibility, then step thru it and see where it puts visibility into
the alist and how.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 26 Dec 2007 00:28:42 -0500, Richard Stallman <rms@gnu.org> said:

> There is still a mystery why visibility's cons cell is pure

I guess the reason is:

  1. w32-win.el has a literal cons-cell in the following function:

    (defun x-handle-iconic (switch)
      "Make \"-iconic\" SWITCH apply only to the initial frame."
      (push '(visibility . icon) initial-frame-alist))

     Note that x-win.el also has an equivalent one.

  2. On the multi-tty merge, term/*-win.elc files are changed to be
     preloaded.  As a result, the above cons cell is allocated in the
     pure storage on Emacs 23.

  3. The X11 version of Fx_create_frame creates a copy of frame
     parameters,

      3030	DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
       :
      3057	  parms = Fcopy_alist (parms);

     but the W32 port doesn't do so.

You don't see the problem on Emacs 22 or on X11 because of 2 or 3
above, respectively.

As for 3 above, the Carbon port of Emacs 22 creates a copy of frame
parameters just as in X11.  But it seems to be changed not to do so on
the multi-tty merge for some reason I'm not sure.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

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

 >   1. w32-win.el has a literal cons-cell in the following function:
 >
 >     (defun x-handle-iconic (switch)
 >       "Make \"-iconic\" SWITCH apply only to the initial frame."
 >       (push '(visibility . icon) initial-frame-alist))
 >
 >      Note that x-win.el also has an equivalent one.
 >
 >   2. On the multi-tty merge, term/*-win.elc files are changed to be
 >      preloaded.  As a result, the above cons cell is allocated in the
 >      pure storage on Emacs 23.
 >
 >   3. The X11 version of Fx_create_frame creates a copy of frame
 >      parameters,
 >
 >       3030	DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
 >        :
 >       3057	  parms = Fcopy_alist (parms);
 >
 >      but the W32 port doesn't do so.
 >
 > You don't see the problem on Emacs 22 or on X11 because of 2 or 3
 > above, respectively.
 >
 > As for 3 above, the Carbon port of Emacs 22 creates a copy of frame
 > parameters just as in X11.  But it seems to be changed not to do so on
 > the multi-tty merge for some reason I'm not sure.

Confirmed :-)

The simple patch I attached handles all problems I encountered in this
context, including the pure storage problems and that of multiple
occurrences of fringes I mentioned earlier.

[-- Attachment #2: w32fns.patch --]
[-- Type: text/plain, Size: 363 bytes --]

*** w32fns.c.~1.307.~	Wed Nov 14 18:33:36 2007
--- w32fns.c	Wed Dec 26 09:35:06 2007
***************
*** 4165,4170 ****
--- 4165,4172 ----
  
    check_w32 ();
  
+   parameters = Fcopy_alist (parameters);
+ 
    /* Use this general default value to start with
       until we know if this frame has a specified name.  */
    Vx_resource_name = Vinvocation_name;

[-- 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: "Attempt to modify read-only object" error with set-frame-configuration

[Richard Stallman]

     > As for 3 above, the Carbon port of Emacs 22 creates a copy of frame
     > parameters just as in X11.  But it seems to be changed not to do so on
     > the multi-tty merge for some reason I'm not sure.

    Confirmed :-)

    The simple patch I attached handles all problems I encountered in this
    context, including the pure storage problems and that of multiple
    occurrences of fringes I mentioned earlier.

You have resolved the mystery.  That is the right fix.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[Bob Rogers]

   From: Richard Stallman <rms@gnu.org>
   Date: Wed, 26 Dec 2007 00:28:42 -0500

       ! 		    (if (eq initial-window-system 'w32)
       ! 			(list (cons 'window-system initial-window-system)
       ! 			      (cons 'visibility t)
       ! 			      frame-initial-frame-alist)
       ! 		      (list (cons 'window-system initial-window-system)
       ! 			    frame-initial-frame-alist)))

Shouldn't that be list* instead of list, in both cases?

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

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

With my previous patch and

(let ((cfg (current-frame-configuration)))
   (set-frame-configuration cfg))

the following bug still persists:

Debugger entered--Lisp error: (wrong-type-argument symbolp (left-fringe))
   modify-frame-parameters(#<frame .emacs 0x1ae2200> ((parent-id) (explicit-name) (display . "") (icon-name) (window-id . "1448") (top + -4) (left + -4) (buried-buffer-list) (buffer-list #<buffer .emacs> #<buffer  *sobar*> #<buffer 
*scratch*>) (unsplittable) (modeline . t) (width . 124) (height . 49) (environment) (background-mode . light) (display-type . color) ((left-fringe) (right-fringe) (left-fringe) (right-fringe)) (visibility . t) (window-system . w32) 
(visibility) (scroll-bar-width . 20) (cursor-type . box) (auto-lower) (auto-raise) (icon-type) (title) (buffer-predicate) (tool-bar-lines . 0) (menu-bar-lines . 1) (right-fringe . 10) (left-fringe . 10) (line-spacing) (screen-gamma) 
(border-color . "black") (cursor-color . "red3") (mouse-color . "black") (background-color . "grey92") (foreground-color . "black") (vertical-scroll-bars . right) (internal-border-width . 0) (border-width . 2) (font . "-outline-Courier 
New-normal-r-normal-normal-16-96-120-120-c-*-iso8859-1")))
   set-frame-configuration((frame-configuration (#<frame .emacs 0x1ae2200> (... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
...) #<window-configuration>)))
   (let ((cfg ...)) (set-frame-configuration cfg))
   eval((let ((cfg ...)) (set-frame-configuration cfg)))
   eval-last-sexp-1(nil)
   eval-last-sexp(nil)
   call-interactively(eval-last-sexp)

To cure this I'd propose the attached patch to fringe.el (it also gets
rid of stale occurrences of left/right fringes in `frame-parameters').


[-- Attachment #2: fringe.patch --]
[-- Type: text/plain, Size: 1116 bytes --]

*** fringe.el.~1.30.~	Wed Aug 29 08:28:06 2007
--- fringe.el	Mon Dec 24 23:47:12 2007
***************
*** 104,116 ****
  See `fringe-mode' for possible values and their effect."
    (setq fringe-mode value)
  
!   (modify-all-frames-parameters
!    (list (cons 'left-fringe (if (consp fringe-mode)
! 				(car fringe-mode)
! 			      fringe-mode))
! 	 (cons 'right-fringe (if (consp fringe-mode)
! 				 (cdr fringe-mode)
! 			       fringe-mode)))))
  
  ;; For initialization of fringe-mode, take account of changes
  ;; made explicitly to default-frame-alist.
--- 104,118 ----
  See `fringe-mode' for possible values and their effect."
    (setq fringe-mode value)
  
!   (when (and (fboundp 'frame-notice-user-settings)
! 	     (not frame-notice-user-settings))
!     (modify-all-frames-parameters
!      (list (cons 'left-fringe (if (consp fringe-mode)
! 				  (car fringe-mode)
! 				fringe-mode))
! 	   (cons 'right-fringe (if (consp fringe-mode)
! 				   (cdr fringe-mode)
! 				 fringe-mode))))))
  
  ;; For initialization of fringe-mode, take account of changes
  ;; made explicitly to default-frame-alist.

[-- 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: "Attempt to modify read-only object" error with set-frame-configuration

[Eli Zaretskii]

> Date: Mon, 24 Dec 2007 23:53:49 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Juanma Barranquero <lekktu@gmail.com>,  emacs-devel@gnu.org
> 
> With my previous patch and
> 
> (let ((cfg (current-frame-configuration)))
>    (set-frame-configuration cfg))
> 
> the following bug still persists:
> 
> Debugger entered--Lisp error: (wrong-type-argument symbolp (left-fringe))

I think this means that your previous patch and the one you suggest
here is not the correct solution.  We must first understand what is
the problem with initial frame parameters on w32, and what causes that
problem.

Re: "Attempt to modify read-only object" error with set-frame-configuration

[martin rudalics]

 > I think this means that your previous patch and the one you suggest
 > here is not the correct solution.  We must first understand what is
 > the problem with initial frame parameters on w32, and what causes that
 > problem.

I think something like this patch is needed to avoid that the fringes
creep into `initial-frame-alist' and `default-frame-alist'.  Otherwise,
customizing these is broken.  And the fringes show up multiple times in
`frame-parameters' due to the simple-minded

	      (setq frame-initial-frame-alist
		    (append initial-frame-alist default-frame-alist nil))

in `frame-initialize'.