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

[Jan D.]

Jan Nieuwenhuizen wrote:

> address@hidden (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.