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 19:50:06 +0100 Message-ID: <509EA1DE.5060105@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> <509E6071.5030102@gmx.at> <83ip9dy0kp.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 1352573430 19136 80.91.229.3 (10 Nov 2012 18:50:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Nov 2012 18:50:30 +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 19:50:38 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 1TXG8c-0004mm-FN for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2012 19:50:38 +0100 Original-Received: from localhost ([::1]:34211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXG8T-0000G4-7w for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2012 13:50:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXG8O-0000FY-9g for emacs-devel@gnu.org; Sat, 10 Nov 2012 13:50:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXG8L-0002I4-7h for emacs-devel@gnu.org; Sat, 10 Nov 2012 13:50:24 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:49170) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1TXG8K-0002HZ-UW for emacs-devel@gnu.org; Sat, 10 Nov 2012 13:50:21 -0500 Original-Received: (qmail invoked by alias); 10 Nov 2012 18:50:19 -0000 Original-Received: from 62-47-50-62.adsl.highway.telekom.at (EHLO [62.47.50.62]) [62.47.50.62] by mail.gmx.net (mp027) with SMTP; 10 Nov 2012 19:50:19 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/UJSx6BjfUtdzUVooMfFrCi9qGz11jGww2iPuAYq IwRebVRJO0H62d In-Reply-To: <83ip9dy0kp.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.23 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:154806 Archived-At: >> I meant to move `point' lazily _after_ we're done with scrolling. > > Do you mean moving the real point or its emulation? When I start scrolling, I save the original position of `window-point'. `window-point' and move `point' as usual. When I now want to interactively insert text into the buffer, I move `point' to the saved original position before. > If the former, it > is currently done as part of window_scroll_pixel_based, and that part > will need to be changed if you want point to stay put disregarding the > scrolling commands. `point' moves as before. But we don't show it any more when it's moved. >> 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). > > You do that in scroll-restore-mode because the C code moves point. > But if C code won't move point in these situations, then there will be > no reason to move point back, because it will stay put. Yes. And the region would be handled automatically as well. >> Where would we have `forward-char' start moving when emulating such >> "other editors"? > > At the original point position, i.e. forward-char will return there > and cause point be displayed after the move. My question was addressing your earlier statement: > 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. So we do not only "scroll back" when we modify text but also when we use commands like `forward-char' and probably in many more cases. >> > 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. > > Doesn't make sense, IMO: it defeats the reason for not moving point on > scroll in the first place. The primary concerns of `scroll-restore-mode' are to preseve `point' when scrolling back to where it was and to restore the region when scrolling back to where `point' was. Jumping back on anything but a scroll command is just an option. So I principally allow to move `point' on scroll. > I think the only commands that should move point in this mode are > those which, well, move point. That is, goto-char, C-f/C-b, mouse-1 > click, etc. And these should cause display to scroll so that point > comes into view. How would commands calling `set-window-start' or `recenter' be classified in this regard? >> 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. > > I don't think anything I said violates this. What am I missing? Ok. Then `window-start' <= `window-point' <= `window-end' is no more an invariant? martin