From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Proposal to improve the nomenclature of scrolling directions Date: Sat, 10 Nov 2012 16:49:58 +0200 Message-ID: <83ip9dy0kp.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1352559040 5864 80.91.229.3 (10 Nov 2012 14:50:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Nov 2012 14:50:40 +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: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 10 15:50:49 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 1TXCOV-0001Sj-7G for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2012 15:50:47 +0100 Original-Received: from localhost ([::1]:48371 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXCOL-00005e-TM for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2012 09:50:37 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXCOH-000057-8k for emacs-devel@gnu.org; Sat, 10 Nov 2012 09:50:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXCOE-0001OE-67 for emacs-devel@gnu.org; Sat, 10 Nov 2012 09:50:33 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXCOD-0001Nq-U5; Sat, 10 Nov 2012 09:50:30 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDA00B00149CZ00@a-mtaout20.012.net.il>; Sat, 10 Nov 2012 16:49:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDA00BS51716VC0@a-mtaout20.012.net.il>; Sat, 10 Nov 2012 16:49:49 +0200 (IST) In-reply-to: <509E6071.5030102@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:154803 Archived-At: > Date: Sat, 10 Nov 2012 15:10:57 +0100 > From: martin rudalics > 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 > > >> 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. Do you mean moving the real point or its emulation? 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. > 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. > > 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"? At the original point position, i.e. forward-char will return there and cause point be displayed after the move. > > 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. 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. > > 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? Why at window-point? At point, of course. Isn't this how things work now? > 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?