From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#12419: Mouse click changes layout Date: Tue, 25 Sep 2012 16:12:39 +0200 Message-ID: <5061BBD7.8070009@gmx.at> References: <504FB55D.5030405@t-online.de> <5050432C.4060203@gmx.at> <5052450F.8030001@t-online.de> <5052F242.4060303@gmx.at> <5055D769.1060804@t-online.de> <50561046.60902@gmx.at> <505E1FB6.1050504@t-online.de> <505ED4AB.7070009@gmx.at> <505F8576.8070902@t-online.de> <50601715.6030108@gmx.at> <833927jxrx.fsf@gnu.org> <5061802C.1070600@gmx.at> <834nmmi9sq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348582399 9299 80.91.229.3 (25 Sep 2012 14:13:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2012 14:13:19 +0000 (UTC) Cc: occitan@esperanto.org, 12419@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 25 16:13:23 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TGVt5-0005Ld-4J for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2012 16:13:23 +0200 Original-Received: from localhost ([::1]:35584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGVt0-0007HK-4u for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2012 10:13:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGVsp-0007FO-0T for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 10:13:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGVsk-0005WQ-Vy for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 10:13:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGVsk-0005WM-TI for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 10:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGVug-00060J-97 for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 10:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Sep 2012 14:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12419-submit@debbugs.gnu.org id=B12419.134858246023016 (code B ref 12419); Tue, 25 Sep 2012 14:15:02 +0000 Original-Received: (at 12419) by debbugs.gnu.org; 25 Sep 2012 14:14:20 +0000 Original-Received: from localhost ([127.0.0.1]:55320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGVu0-0005zA-9a for submit@debbugs.gnu.org; Tue, 25 Sep 2012 10:14:20 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:60205) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGVtx-0005z0-PP for 12419@debbugs.gnu.org; Tue, 25 Sep 2012 10:14:19 -0400 Original-Received: (qmail invoked by alias); 25 Sep 2012 14:12:16 -0000 Original-Received: from 62-47-32-73.adsl.highway.telekom.at (EHLO [62.47.32.73]) [62.47.32.73] by mail.gmx.net (mp016) with SMTP; 25 Sep 2012 16:12:16 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1++jhl1n+a+7jzKzroLlRpeh7h79K1YYkK+JIQCNd Wy/gjva3eLb/be In-Reply-To: <834nmmi9sq.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64878 Archived-At: >> > Where in the code or the infrastructure do we enforce an integral >> > number of lines in a window? >> >> All over the window handling code, presently. > > Can you humor me with a typical example, please? The central routine is `window--resize-child-windows'. But `balance-windows-2' and `fit-window-to-buffer' are typical too. All these go a long way to meet a self-imposed restriction specified in lines (and columns) by adding lines one-by-one to some window. Obviously, we can replace this restriction by a pixel specified one and things become probably much simpler. In any case, these routines have to be rewritten. I can't tell how this will affect the remaining code (large parts of which rely on `window--resize-child-windows'). > Why? Emacs doesn't promise to have the last line visible even now, if > the window has variable size fonts. What we currently do promise > (IIUC) is to have each window's height an integral multiple of the > default face's height. But if the window shows no characters with the > default face, that contract is irrelevant anyway. It's not me you have to convince here ;-) >> So even if we manage to provide really maximized frames, the window >> handling code will have to show most windows with fully visible >> lines. > > See above: you cannot guarantee that. My experience tells me that people using the default face and only that will ask for it. Let's hope I'm wrong. > Do we really need such a change? What damage could be caused by > accepting a window size in integral lines, but producing a window that > is slightly larger or smaller? Again, this happens today already as > long as non-default faces are displayed in the window. Probably not much. Parts of the mouse code might report incongruent results. And likely, window resizing will get inconsistent over time. Give it a try. Have you ever looked at the routines XEmacs uses for handling frame/window pixel sizes? There's quite a lot of them. >> And I suppose that we want a function that calculates the number of >> pixels between two buffer positions > > Doesn't pos-visible-in-window-p fit the bill already? Have you looked at the loop at the end of `fit-window-to-buffer'? It's apparently needed because `count-screen-lines' doesn't return a value that's good enough there. martin