[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal to improve the nomenclature of scrolling directions
From: |
Eli Zaretskii |
Subject: |
Re: Proposal to improve the nomenclature of scrolling directions |
Date: |
Sat, 10 Nov 2012 16:49:58 +0200 |
> Date: Sat, 10 Nov 2012 15:10:57 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden, address@hidden, address@hidden,
> address@hidden, address@hidden, address@hidden,
> address@hidden
>
> >> 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?
- Re: Proposal to improve the nomenclature of scrolling directions, (continued)
- Re: Proposal to improve the nomenclature of scrolling directions, Richard Stallman, 2012/11/09
- Re: Proposal to improve the nomenclature of scrolling directions, Eli Zaretskii, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, Eli Zaretskii, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, Nix, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, Eli Zaretskii, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, Nix, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions,
Eli Zaretskii <=
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, Eli Zaretskii, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, Eli Zaretskii, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/09
- Re: Proposal to improve the nomenclature of scrolling directions, Stefan Monnier, 2012/11/09
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions, Stephen J. Turnbull, 2012/11/08
- Re: Proposal to improve the nomenclature of scrolling directions, Stephen Leake, 2012/11/08