From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: (Not) scrolling past the end of a buffer Date: Sat, 20 Oct 2012 00:34:12 +0200 Message-ID: <20121020003412.0331c798@forcix.kollektiv-hamburg.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1350686062 22920 80.91.229.3 (19 Oct 2012 22:34:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2012 22:34:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 20 00:34:30 2012 Return-path: Envelope-to: ged-emacs-devel@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 1TPL9A-00079g-EX for ged-emacs-devel@m.gmane.org; Sat, 20 Oct 2012 00:34:28 +0200 Original-Received: from localhost ([::1]:43891 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPL93-0001i9-7d for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2012 18:34:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPL90-0001gt-2x for emacs-devel@gnu.org; Fri, 19 Oct 2012 18:34:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TPL8y-0005zD-O3 for emacs-devel@gnu.org; Fri, 19 Oct 2012 18:34:17 -0400 Original-Received: from istinn.electusmatari.com ([83.169.37.145]:44451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPL8y-0005z4-Ep for emacs-devel@gnu.org; Fri, 19 Oct 2012 18:34:16 -0400 Original-Received: from forcix.kollektiv-hamburg.de (hmbg-5f767a13.pool.mediaWays.net [95.118.122.19]) by istinn.electusmatari.com (Postfix) with ESMTPSA id 4A55215DC0004 for ; Sat, 20 Oct 2012 00:34:14 +0200 (CEST) X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 83.169.37.145 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154451 Archived-At: Hello! There was a discussion back in February about Emacs scrolling past the end of buffers, but that discussion never finished (as far as I can tell). http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00314.html Emacs' scrolling behavior allows for a window to move past the end of a buffer up to the point where the last line of a buffer is the only thing displayed. This can be useful for editing, but it is unexpected behavior for modes that interact with other programs. Based on the behavior of terminals, the expectation and preference there is that the input line would remain at the bottom edge of a window as long as there is enough data to be displayed. There have been a number of hacks to implement this behavior. For example, `comint-mode' introduced the variable `comint-scroll-show-maximum-output' to achieve just this effect, but it's an incomplete solution as manual scrolling or splitting windows still can cause the prompt to show up in the middle of a window. The IRC clients ERC and Circe both implement a specific hook to do this. Both actually used `window-scroll-functions' for this, which worked well but is problematic because other functions on the hook rely on the view port not to change during the running of the hook. Hence a warning to that effect was added to the hook description and ERC was changed to use `post-command-hook', causing quite a bit of unnecessary computation. Eshell and rcirc both have copied the comint behavior after originally following ERC's approach. And from the thread linked to above, it seems that some users would like this behavior in editing buffers as well. Based on the apparent need for such a functionality, I actually looked at window.c to see if I can figure out how to add it right in the scrolling code, but my C seems to be too rusty to actually get this done. Though a buffer-local variable that's checked from the scrolling code seems to me to be the correct solution for this problem. So, with `window-scroll-functions' off-limits to this kind of code, what's the officially recommended approach for modes that want to keep their input line at the end of a window, and not break because of splitting a window (or manual recentering, or any manual scrolling, or ...)? Regards, -- Jorgen