From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: 23.0.50; Cannot run calculator on TTY Date: Sat, 13 Oct 2007 15:47:54 -0400 Message-ID: References: <20071001023514.E164D12A4071@localhost> <470090AD.7020701@gmx.at> <18176.62320.27921.579761@gargle.gargle.HOWL> <4701153E.7010408@gmx.at> <18177.46954.59945.891659@gargle.gargle.HOWL> <4701F402.6060403@gmx.at> <18178.18023.858644.85600@gargle.gargle.HOWL> <47028522.60003@gmx.at> <18178.62745.602748.437486@gargle.gargle.HOWL> <470334E7.9020102@gmx.at> <18179.41840.532732.664369@gargle.gargle.HOWL> <18187.33374.913139.901742@gargle.gargle.HOWL> <470BB544.8090708@gmx.at> <18189.42188.229008.184425@gargle.gargle.HOWL> <470DE3E8.3080401@gmx.at> <18190.9560.402525.665860@gargle.gargle.HOWL> <470F3D19.2080702@gmx.at> <471089B7.7030503@gmx.at> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1192304899 14249 80.91.229.12 (13 Oct 2007 19:48:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2007 19:48:19 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, raman@users.sf.net To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 13 21:48:09 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 1Igmxz-0005kv-Ss for ged-emacs-devel@m.gmane.org; Sat, 13 Oct 2007 21:48:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Igmxt-00089f-Be for ged-emacs-devel@m.gmane.org; Sat, 13 Oct 2007 15:48:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Igmxp-000892-8L for emacs-devel@gnu.org; Sat, 13 Oct 2007 15:47:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Igmxn-00088U-TU for emacs-devel@gnu.org; Sat, 13 Oct 2007 15:47:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Igmxn-00088J-J4 for emacs-devel@gnu.org; Sat, 13 Oct 2007 15:47:55 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Igmxn-00012a-Dl for emacs-devel@gnu.org; Sat, 13 Oct 2007 15:47:55 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Igmxm-0002Fk-Du; Sat, 13 Oct 2007 15:47:54 -0400 In-reply-to: <471089B7.7030503@gmx.at> (message from martin rudalics on Sat, 13 Oct 2007 11:02:47 +0200) X-detected-kernel: by monty-python.gnu.org: 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:80810 gmane.emacs.pretest.bugs:20112 Archived-At: > One idea that occurs to me is that `window-min-height' could count the > header line, if any. Do you mean "One idea that occurs to me is that the `split-window' could NOT count the header line, if any." We may be trying to say the same thing in two ways. Basically, my idea is that the minimum allowed number of lines in a window -- in every sense -- would not depend on whether one of those lines is used as a header line. This might require changes in redisplay as well in order to function correctly. The only drawback I can think of is that splitting may produce a window showing a header- and a mode-line only. Yes, that could happen. It might be a lesser problem than the one we now have. At least it would be comprehensible and would follow a simple rule. > That way, the fact that some buffers have header > lines and others don't will not cause any problems for vertical > splitting of windows. In the most usual cases, at least -- but not > in all cases, perhaps. > > Another solution would be to pass a two buffers to `split-window', > telling it to select those two buffers, and to calculate based > on the assumption that those buffers will be displayed. That's what I meant with "provide explicit (optional) parameters for `split-window-vertically' and `split-window-horizontally'". This would also mean that the client of these functions (and `split-window') would have to set the corresponding (buffer-local) variables _before_ calling these. Then we both had the same idea. If people like this better, it is fine with me.