From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Proposal to improve the nomenclature of scrolling directions Date: Sat, 10 Nov 2012 15:10:57 +0100 Message-ID: <509E6071.5030102@gmx.at> References: <87a9uvv6ng.fsf@uwakimon.sk.tsukuba.ac.jp> <87bof9s7cl.fsf@spindle.srvr.nix> <874nl0ov8g.fsf@spindle.srvr.nix> <20635.63115.874182.168553@winooski.ccs.neu.edu> <87liecnelf.fsf@spindle.srvr.nix> <83390k0wgy.fsf@gnu.org> <83sj8jz0rs.fsf@gnu.org> <83txsxykcp.fsf@gnu.org> <509E3607.6070500@gmx.at> <83obj5y94x.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 1352556683 20652 80.91.229.3 (10 Nov 2012 14:11:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Nov 2012 14:11:23 +0000 (UTC) Cc: dan@haxney.org, rms@gnu.org, eli@barzilay.org, emacs-devel@gnu.org, nix@esperi.org.uk, monnier@iro.umontreal.ca, dmoncayo@gmail.com, stephen@xemacs.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 10 15:11:31 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 1TXBmO-0006k4-VH for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2012 15:11:25 +0100 Original-Received: from localhost ([::1]:40412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXBmF-0001Ni-HH for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2012 09:11:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXBmA-0001Mf-Id for emacs-devel@gnu.org; Sat, 10 Nov 2012 09:11:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXBm7-00075d-Fw for emacs-devel@gnu.org; Sat, 10 Nov 2012 09:11:10 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:40812) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1TXBm7-00075I-60 for emacs-devel@gnu.org; Sat, 10 Nov 2012 09:11:07 -0500 Original-Received: (qmail invoked by alias); 10 Nov 2012 14:11:06 -0000 Original-Received: from 62-47-57-19.adsl.highway.telekom.at (EHLO [62.47.57.19]) [62.47.57.19] by mail.gmx.net (mp040) with SMTP; 10 Nov 2012 15:11:06 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19pPQBTIfZpEWkisUR9pZ2kQ1+OJsQFbfqiXD3M39 j/LZk9vvJqiHNp In-Reply-To: <83obj5y94x.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 213.165.64.22 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:154796 Archived-At: >> Not necessarily. We can always move point lazily, that is, whenever it >> is requested. > > That requires changes to window-scrolling functions, since currently > they do move point, and they do it non-lazily. See > window_scroll_pixel_based, where it calls SET_PT_BOTH etc. I meant to move `point' lazily _after_ we're done with scrolling. If the emulation is on and the command is not a scrolling command recognized by the emulation, move `point' to where it was before scrolling. That's what I do in `scroll-restore-mode' (if wanted). > And what does "whenever it is requested" means, anyway, in practical > terms? Whenever the current command is not a scroll command. In `scroll-restore-mode' I do that in a pre-command hook. > Those "other editors" that allow point to stay out of the > window will scroll the display back to show point when some command is > invoked that modifies the buffer text. Where would we have `forward-char' start moving when emulating such "other editors"? > Given that the modification > commands don't require moving point, and C-v/M-v won't either (as this > is the main justification for the feature we are discussing), what > will? The modification commands can require moving point, if desired. But while it might be useful to emulate other editors in this regard, the main deficiencies we should concentrate on are: - When scrolling for-/backward, a window's point should appear where it was before we started scrolling. Currently, it doesn't when using different faces and maybe in some other cases as well. - Avoid the silly way the region is disfigured when it was scrolled off-screen. >> As long as scrolling proceeds, we can pretend (visually) that it's >> somewhere else. > > You are describing the kludgey solution (IIUC), whereas I'm suggesting > a non-kludgey one. Every solution here will be kludgey. Suppose you scroll a non-selected window and subsequently insert text into its buffer. Would you insert it at its old `window-point' even if its `point' is somewhere else? A basic invariant of Emacs is that at top-level any buffer's `point' coincides with `window-point' of the selected window, provided the buffer appears there. Violating this invariant means we have to rethink lots of code, including things as fragile as the window configuration code. martin