byte-code: Wrong type argument: number-or-marker-p, (+ -21)

byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan Nieuwenhuizen]

I want to start my emacs with geometry 80x[full-screen-height], with
menu-bar and tool-bar disabled.

With emacs (21.3.1 and also) today's CVS, there is a problem running
emacs without -q, disabling the tool-bar and having it use the full
screen height.

The problem occurs when the emacs window is taller than the screen, at
the time of disabling the tool-bar (this is what we need to get full
screen height after disabling menu-bar and tool-bar).

Here is my .emacs.el pruned for testing:

    (when (equal emacs-major-version 21)
      (tool-bar-mode -1))

    (message "hi")

Then, starting emacs as:

    emacs --geometry 80x100+0-0&  # too tall for my screen, but ok for testing

prints this error:

    byte-code: Wrong type argument: number-or-marker-p, (+ -520)

After hitting this error emacs exhibits some seemingly unrelated
problems, such as gud not syncing the src window.

Running with --debug-init does not help, adding (setq debug-on-error
t) to ~/.emacs.el yields:

    Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (+ -21))
      frame-notice-user-settings()
      command-line-1(("80x100+0-0"))
      command-line()
      normal-top-level()

however, there is no call to number-or-marker-p in
frame-notice-user-settings.  I'm confused.

This is using:
    GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit) of 2003-10-31 on raven, modified by Debian
or
    GNU Emacs 21.3.50.2 (i686-pc-linux-gnu, GTK+ Version 2.2.4) of 2003-11-12 on oliebij

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan D.]

> 
> I want to start my emacs with geometry 80x[full-screen-height], with
> menu-bar and tool-bar disabled.
> 
...
> 
> Then, starting emacs as:
> 
>     emacs --geometry 80x100+0-0&  # too tall for my screen, but ok for testing
> 
> prints this error:
> 
>     byte-code: Wrong type argument: number-or-marker-p, (+ -520)
> 
> After hitting this error emacs exhibits some seemingly unrelated
> problems, such as gud not syncing the src window.
> 
> Running with --debug-init does not help, adding (setq debug-on-error
> t) to ~/.emacs.el yields:
> 
>     Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (+ -21))
>       frame-notice-user-settings()
>       command-line-1(("80x100+0-0"))
>       command-line()
>       normal-top-level()
> 
> however, there is no call to number-or-marker-p in
> frame-notice-user-settings.  I'm confused.

These lines in frame-notice-user-settings triggers the error:
            (let* ...
		   (top (frame-parameter frame-initial-frame 'top)))
	      (when (and (consp initial-top) (eq '- (car initial-top)))
		(setq newparms
		      (append newparms
			      `((top . ,(+ top (* lines char-height))))
			      nil)))


When the top of the frame is over the top of the display (i.e. y is negative),
frame-parameter returns a strange value (evaluated in *scratch*):


(frame-parameter (selected-frame) 'top)
(+ -21)

Ditto for left.
This is because of this code in x_report_frame_params:

  /* Represent negative positions (off the top or left screen edge)
     in a way that Fmodify_frame_parameters will understand correctly.  */
  XSETINT (tem, f->left_pos);
  if (f->left_pos >= 0)
    store_in_alist (alistptr, Qleft, tem);
  else
    store_in_alist (alistptr, Qleft, Fcons (Qplus, Fcons (tem, Qnil)));

It has been like this a long time (21.2 at least).  Someone better in lisp
than me can probably fix frame-notice-user-settings so it works ok.
My initial attempt (if (consp top) (car (cdr top)) top) leads to a
serious miscalculation of the top position with your geometry parameter,
the whole frame is over the top.  The bottom of the frame should be on
the bottom of the screen.

	Jan D.

FIX: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan Nieuwenhuizen]

"Jan D." <jan.h.d@swipnet.se> writes:

> These lines in frame-notice-user-settings triggers the error:
>             (let* ...
> 		   (top (frame-parameter frame-initial-frame 'top)))
> 	      (when (and (consp initial-top) (eq '- (car initial-top)))
> 		(setq newparms
> 		      (append newparms
> 			      `((top . ,(+ top (* lines char-height))))
> 			      nil)))

Thanks.  Why did debug-on-error not show me a backtrace?

> When the top of the frame is over the top of the display:
>
> (frame-parameter (selected-frame) 'top)
> (+ -21)
>
> Ditto for left.

I could not trigger the error for left.

> Someone better in lisp than me can probably fix
> frame-notice-user-settings so it works ok.

I'm not sure that I qualify, but below is a fix.

Greetings,
Jan.


2003-11-16  Jan Nieuwenhuizen  <jan.nieuwenhuizen@aspiratie.nl>

	* frame.el (frame-notice-user-settings): Fix for TOP parameter
	of CONS flavour.

--- frame.el.~1.205.~	2003-10-02 16:06:45.000000000 +0200
+++ frame.el	2003-11-16 23:03:18.000000000 +0100
@@ -333,7 +333,12 @@ React to settings of `default-frame-alis
 		   (newparms (list (cons 'height (- height lines))))
 		   (initial-top (cdr (assq 'top
 					   frame-initial-geometry-arguments)))
-		   (top (frame-parameter frame-initial-frame 'top)))
+		   (fif-top (frame-parameter frame-initial-frame 'top))
+		   (top (if (consp fif-top)
+			    (cond ((eq '+ (car fif-top)) (cadr fif-top))
+				  ((eq '- (car fif-top)) (- 0 (cadr fif-top)))
+				  (t 0))
+			  fif-top)))
 	      (when (and (consp initial-top) (eq '- (car initial-top)))
 		(setq newparms
 		      (append newparms

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: FIX: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Kim F. Storm]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> "Jan D." <jan.h.d@swipnet.se> writes:
> 
> > These lines in frame-notice-user-settings triggers the error:
> >             (let* ...
> > 		   (top (frame-parameter frame-initial-frame 'top)))
> > 	      (when (and (consp initial-top) (eq '- (car initial-top)))
> > 		(setq newparms
> > 		      (append newparms
> > 			      `((top . ,(+ top (* lines char-height))))
> > 			      nil)))
> 
> Thanks.  Why did debug-on-error not show me a backtrace?
> 
> > When the top of the frame is over the top of the display:
> >
> > (frame-parameter (selected-frame) 'top)
> > (+ -21)
> >
> > Ditto for left.
> 
> I could not trigger the error for left.
> 
> > Someone better in lisp than me can probably fix
> > frame-notice-user-settings so it works ok.
> 
> I'm not sure that I qualify, but below is a fix.
> 
> Greetings,
> Jan.
> 
> 
> 2003-11-16  Jan Nieuwenhuizen  <jan.nieuwenhuizen@aspiratie.nl>
> 
> 	* frame.el (frame-notice-user-settings): Fix for TOP parameter
> 	of CONS flavour.
> 
> --- frame.el.~1.205.~	2003-10-02 16:06:45.000000000 +0200
> +++ frame.el	2003-11-16 23:03:18.000000000 +0100
> @@ -333,7 +333,12 @@ React to settings of `default-frame-alis
>  		   (newparms (list (cons 'height (- height lines))))
>  		   (initial-top (cdr (assq 'top
>  					   frame-initial-geometry-arguments)))
> -		   (top (frame-parameter frame-initial-frame 'top)))
> +		   (fif-top (frame-parameter frame-initial-frame 'top))
> +		   (top (if (consp fif-top)
> +			    (cond ((eq '+ (car fif-top)) (cadr fif-top))
> +				  ((eq '- (car fif-top)) (- 0 (cadr fif-top)))
> +				  (t 0))
> +			  fif-top)))
>  	      (when (and (consp initial-top) (eq '- (car initial-top)))
>  		(setq newparms
>  		      (append newparms
			      `((top . ,(+ top (* lines char-height))))
			      nil)))

This still looks bogus to me, as the new parameter doesn't preserve
the (+ ...) or (- ...) form of the original setting, but uses the
calculated value directly.  Shouldn't it preserve the top/left (+) or
bottom/right (-) indication?

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

Re: FIX: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan Nieuwenhuizen]

storm@cua.dk (Kim F. Storm) writes:

>> +			    (cond ((eq '+ (car fif-top)) (cadr fif-top))
>> +				  ((eq '- (car fif-top)) (- 0 (cadr fif-top)))

> This still looks bogus to me, as the new parameter doesn't preserve
> the (+ ...) or (- ...) form of the original setting, but uses the
> calculated value directly.  Shouldn't it preserve the top/left (+) or
> bottom/right (-) indication?

Ah, so that's what (and why) the strange notation means.  Then it
should probably be something like:

 (cond ((eq '+ (car fif-top)) (cadr fif-top))
       ((eq '- (car fif-top)) (- <DISPLAY-HEIGHT> (cadr fif-top)))

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: FIX: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Ah, so that's what (and why) the strange notation means.  Then it
> should probably be something like:
>
>  (cond ((eq '+ (car fif-top)) (cadr fif-top))
>        ((eq '- (car fif-top)) (- <DISPLAY-HEIGHT> (cadr fif-top)))

So here's a new try.

Jan.

2003-11-18  Jan Nieuwenhuizen  <jan.nieuwenhuizen@aspiratie.nl>

	* frame.el (frame-notice-user-settings): Fix for TOP parameter
	of CONS flavour.

--- frame.el.~1.205.~	2003-10-02 16:06:45.000000000 +0200
+++ frame.el	2003-11-18 22:07:36.000000000 +0100
@@ -333,7 +333,13 @@ React to settings of `default-frame-alis
 		   (newparms (list (cons 'height (- height lines))))
 		   (initial-top (cdr (assq 'top
 					   frame-initial-geometry-arguments)))
-		   (top (frame-parameter frame-initial-frame 'top)))
+		   (fif-top (frame-parameter frame-initial-frame 'top))
+		   (top (if (consp fif-top)
+			    (cond ((eq '+ (car fif-top)) (cadr fif-top))
+				  ((eq '- (car fif-top))
+				   (- (display-pixel-height) (cadr fif-top)))
+				  (t 0))
+			  fif-top)))
 	      (when (and (consp initial-top) (eq '- (car initial-top)))
 		(setq newparms
 		      (append newparms


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: FIX: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Kim F. Storm]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Jan Nieuwenhuizen <janneke@gnu.org> writes:
> 
> > Ah, so that's what (and why) the strange notation means.  Then it
> > should probably be something like:
> >
> >  (cond ((eq '+ (car fif-top)) (cadr fif-top))
> >        ((eq '- (car fif-top)) (- <DISPLAY-HEIGHT> (cadr fif-top)))
> 
> So here's a new try.
> 
> Jan.
> 
> 2003-11-18  Jan Nieuwenhuizen  <jan.nieuwenhuizen@aspiratie.nl>
> 
> 	* frame.el (frame-notice-user-settings): Fix for TOP parameter
> 	of CONS flavour.
> 
> --- frame.el.~1.205.~	2003-10-02 16:06:45.000000000 +0200
> +++ frame.el	2003-11-18 22:07:36.000000000 +0100
> @@ -333,7 +333,13 @@ React to settings of `default-frame-alis
>  		   (newparms (list (cons 'height (- height lines))))
>  		   (initial-top (cdr (assq 'top
>  					   frame-initial-geometry-arguments)))
> -		   (top (frame-parameter frame-initial-frame 'top)))
> +		   (fif-top (frame-parameter frame-initial-frame 'top))
> +		   (top (if (consp fif-top)
> +			    (cond ((eq '+ (car fif-top)) (cadr fif-top))
> +				  ((eq '- (car fif-top))
> +				   (- (display-pixel-height) (cadr fif-top)))
> +				  (t 0))
> +			  fif-top)))
>  	      (when (and (consp initial-top) (eq '- (car initial-top)))
>  		(setq newparms
>  		      (append newparms
> 

This is definitely better than before, but you still do not address
the issue whether the new setting for top should be top/left or
bottom/right relative, ie. whether the new top value should be (+ INT)
or (- INT) if the old settings had that format (rather than an
integer).

I don't quite know what's the right thing to do.  WDOT?

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

Re: FIX: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan Nieuwenhuizen]

storm@cua.dk (Kim F. Storm) writes:

> This is definitely better than before, but you still do not address
> the issue whether the new setting for top should be top/left or
> bottom/right relative, ie. whether the new top value should be (+ INT)
> or (- INT) if the old settings had that format (rather than an
> integer).

Ah.  I assumed this:

    `((top . ,(+ top (* lines char-height))))

to be correct, and the value of TOP wrong if not an INT, but you're
suggesting something like:

    `((top . ,((if (consp top)
                   (cond ((eq '+ (car top))
                          (list '+ (+ (cadr top) (* lines char-height))))
                         ((eq '- (car top))
                          (list '- (- (cadr top) (* lines char-height))))
                         (t 0))
                 ,(+ top (* lines char-height))))))

but I'm not at all sure about the right arithmetic for (+/- INT) ...

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: FIX: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Kim F. Storm]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > This is definitely better than before, but you still do not address
> > the issue whether the new setting for top should be top/left or
> > bottom/right relative, ie. whether the new top value should be (+ INT)
> > or (- INT) if the old settings had that format (rather than an
> > integer).
> 
> Ah.  I assumed this:
> 
>     `((top . ,(+ top (* lines char-height))))
> 
> to be correct, and the value of TOP wrong if not an INT, but you're
> suggesting something like:
> 
>     `((top . ,((if (consp top)
>                    (cond ((eq '+ (car top))
>                           (list '+ (+ (cadr top) (* lines char-height))))
>                          ((eq '- (car top))
>                           (list '- (- (cadr top) (* lines char-height))))
>                          (t 0))
>                  ,(+ top (* lines char-height))))))

Exactly (but the , in the last line isn't needed).

> 
> but I'm not at all sure about the right arithmetic for (+/- INT) ...
> 

Me neither...   What do others think about this?

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

Re: FIX#3: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan Nieuwenhuizen]

storm@cua.dk (Kim F. Storm) writes:

>> but I'm not at all sure about the right arithmetic for (+/- INT) ...
>
> Me neither...   What do others think about this?

So here's a patch #3 to try.

Jan.

2003-11-20  Jan Nieuwenhuizen  <jan.nieuwenhuizen@aspiratie.nl>

	* frame.el (frame-notice-user-settings): Fix for TOP parameter
	of CONS flavour.

--- frame.el.~1.205.~	2003-10-02 16:06:45.000000000 +0200
+++ frame.el	2003-11-20 01:51:14.000000000 +0100
@@ -335,10 +335,18 @@ React to settings of `default-frame-alis
 					   frame-initial-geometry-arguments)))
 		   (top (frame-parameter frame-initial-frame 'top)))
 	      (when (and (consp initial-top) (eq '- (car initial-top)))
-		(setq newparms
-		      (append newparms
-			      `((top . ,(+ top (* lines char-height))))
-			      nil)))
+		(let ((new-top
+		       (if (consp top)
+			   (cond ((eq '+ (car top))
+				  (list
+				   '+ (+ (cadr top) (* lines char-height))))
+				 ((eq '- (car top))
+				  (list
+				   '- (- (display-pixel-height)
+					 ((cadr top) (* lines char-height)))))
+				 (t 0))
+			 (+ top (* lines char-height)))))
+		  (setq newparms (append newparms `((top . ,new-top)) nil))))
 	      (modify-frame-parameters frame-initial-frame newparms)
 	      (tool-bar-mode -1)))))
 

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: FIX#3: byte-code: Wrong type argument: number-or-marker-p, (+ -21)

[Jan D.]

> storm@cua.dk (Kim F. Storm) writes:
> 
> >> but I'm not at all sure about the right arithmetic for (+/- INT) ...
> >
> > Me neither...   What do others think about this?
> 
> So here's a patch #3 to try.
> 

This is tricky, the patch is quite good, but not entirely correct.
% emacs -g 80x100+0-0
and
% emacs -g 80x100-0-0

should align vertically and only differ horizontally, but they don't.

	Jan D.


> Jan.
> 
> 2003-11-20  Jan Nieuwenhuizen  <jan.nieuwenhuizen@aspiratie.nl>
> 
> 	* frame.el (frame-notice-user-settings): Fix for TOP parameter
> 	of CONS flavour.
> 
> --- frame.el.~1.205.~	2003-10-02 16:06:45.000000000 +0200
> +++ frame.el	2003-11-20 01:51:14.000000000 +0100
> @@ -335,10 +335,18 @@ React to settings of `default-frame-alis
>  					   frame-initial-geometry-arguments)))
>  		   (top (frame-parameter frame-initial-frame 'top)))
>  	      (when (and (consp initial-top) (eq '- (car initial-top)))
> -		(setq newparms
> -		      (append newparms
> -			      `((top . ,(+ top (* lines char-height))))
> -			      nil)))
> +		(let ((new-top
> +		       (if (consp top)
> +			   (cond ((eq '+ (car top))
> +				  (list
> +				   '+ (+ (cadr top) (* lines char-height))))
> +				 ((eq '- (car top))
> +				  (list
> +				   '- (- (display-pixel-height)
> +					 ((cadr top) (* lines char-height)))))
> +				 (t 0))
> +			 (+ top (* lines char-height)))))
> +		  (setq newparms (append newparms `((top . ,new-top)) nil))))
>  	      (modify-frame-parameters frame-initial-frame newparms)
>  	      (tool-bar-mode -1)))))
>  
> 
> -- 
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
> http://www.xs4all.nl/~jantien       | http://www.lilypond.org
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Geometry interpretation change? (was: FIX#3: byte-code: Wrong type argument: number-or-marker-p, (+ -21))

[Jan D.]

Jan Nieuwenhuizen wrote:

> storm@cua.dk (Kim F. Storm) writes:
>
>>> but I'm not at all sure about the right arithmetic for (+/- INT) ...
>>
>> Me neither...   What do others think about this?
>
> So here's a patch #3 to try.

I am now conviced this can't be solved in Lisp with the information
available.  Additional information could be made available to lisp,
but that does not seem right as this is fundamentally an X problem,
Mac and W32 does not have window managers.

Anyway, I have a solution I'd like to test some more and check in
next weekend if it is OK (still away during the week).  But it
makes a change on how the geometry height is interpreted.  Now
a height of 24 means 24 - tool bar height - menu bar height.  I'd like
it to be that if you disable both the menu bar and the tool bar, you
get 24, and external menu bar and/or tool bar does not count.

Thus, for GTK you would always get 24 (external tool and menu bar).
For Lucid, you would get 24 - tool bar height (external menu bar).
For no toolkit version you would get 24 - tool bar height - menu bar
height.
If you have disabled both menu and tool bar you always get 24.

Does this sound reasonable?

One advantage of the purposed solution is that geometry -0-0 will always
end up in the lower right corner, regardless if you have removed tool
or menu bar in .emacs.  Also when you say
(set-frame-parameter nil 'top '(- 0))
the frame does end up at the bottom.  Ditto for left.

I don't know if this will have any impact on W32 or Mac, probably not.

	Jan D.

Re: Geometry interpretation change? (was: FIX#3: byte-code: Wrong type argument: number-or-marker-p, (+ -21))

[Kim F. Storm]

"Jan D." <jan.h.d@swipnet.se> writes:

> Anyway, I have a solution I'd like to test some more and check in
> next weekend if it is OK (still away during the week).  But it
> makes a change on how the geometry height is interpreted.  Now
> a height of 24 means 24 - tool bar height - menu bar height.  I'd like
> it to be that if you disable both the menu bar and the tool bar, you
> get 24, and external menu bar and/or tool bar does not count.
> 
> Thus, for GTK you would always get 24 (external tool and menu bar).
> For Lucid, you would get 24 - tool bar height (external menu bar).
> For no toolkit version you would get 24 - tool bar height - menu bar
> height.
> If you have disabled both menu and tool bar you always get 24.
> 
> Does this sound reasonable?

Sounds reasonable to me.

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