From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: XEmbed patches Date: Fri, 20 Jul 2007 21:28:34 +0900 Message-ID: <87vecfntsd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20070718142537.GA27107@movial.fi> <46A05BFA.2010900@swipnet.se> <20070720082425.GD27107@movial.fi> <46A074FC.7040805@gnu.org> <86d4ynxxax.fsf@lola.quinscape.zz> <46A08F7E.9060904@swipnet.se> <46A0920E.7090809@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1184933815 18260 80.91.229.12 (20 Jul 2007 12:16:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jul 2007 12:16:55 +0000 (UTC) Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= , emacs-devel@gnu.org, rms@gnu.org, Timo Savola To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 20 14:16:53 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IBrPg-0006O3-DZ for ged-emacs-devel@m.gmane.org; Fri, 20 Jul 2007 14:16:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IBrPd-0002GO-GU for ged-emacs-devel@m.gmane.org; Fri, 20 Jul 2007 08:16:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IBrPa-0002D4-7g for emacs-devel@gnu.org; Fri, 20 Jul 2007 08:16:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IBrPW-00027g-2y for emacs-devel@gnu.org; Fri, 20 Jul 2007 08:16:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IBrPV-00027Q-SU for emacs-devel@gnu.org; Fri, 20 Jul 2007 08:16:41 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IBrPR-0005ZF-LR; Fri, 20 Jul 2007 08:16:38 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (unknown [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 929367FFD; Fri, 20 Jul 2007 21:16:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CF1A4126DEF; Fri, 20 Jul 2007 21:28:35 +0900 (JST) In-Reply-To: <46A0920E.7090809@gnu.org> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" (+CVS-20070621) XEmacs Lucid X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:75176 Archived-At: Jason Rumney writes: > And can Emacs switch this behaviour [of sizing in character units] > on and off at will? [All windows below are window-system windows, not Emacs windows, which are irrelevant here.] It doesn't work that way, not if Emacs is an ICCCM-conformant application. The window manager tells Emacs, in pixels, where and how big its windows are going to be, and it has the power to enforce this (by reparenting Emacs's top-level window as a subwindow of a window it owns, and clipping Emacs's window to the window manager's preferred geometry). It's Emacs's problem to fit into that space. If Emacs wants to, it can make its window arbitrarily big (up to the limit imposed by the size of the X.h Dimension typedef, often 16 bits), but the user will still only see that part that fits into the space provided by the window manager. If Emacs's desired window is smaller than what it is given, any "slop" will have to be dealt with. An image viewer might prefer to center its display, but typically a text application will align the top-left corner of the top-left character's bounding box with the origin (top-left) of the window. The right side is typically ragged, so a few pixels there will be unnoticed, and (if the text extends that far) the bottom line is typically displayed, and then clipped to the window provided. The use of character size (which is an arbitrary pair of dimensions selected by the programmer, doesn't need to correspond to an actual character cell) is purely a convenience for the user. A window manager can, but need not, respect the nominal character grid. That's entirely up to the window manager. Especially in full-screen maximization, window managers often choose to ignore the grid. And for GUI apps the grid is kinda silly anyway, since it's unlikely that the decorations will be integral multiples of the font size (which may not determine interlinear spacing in the presence of faces or images, anyway). Presumably the XEmbed parent has similar power, and Emacs can deal with it in pretty much exactly the same way that it deals with the window manager. Just remember these words: "Yes, Boss!" and you'll get along with the typical window manager just fine. > If the user selects a variable width font as the default font, then > the character increment is not very useful. Sure it is. Variable width fonts still have a consistent height, and you can assume the standardized aspect ratio of 2:1. This is noticably wider than would correspond to 80-character lines in most proportional fonts, but it's usually far better to underestimate the number of characters that will fit in the window than to overestimate.