[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: |
martin rudalics |
Subject: |
Re: Proposal to improve the nomenclature of scrolling directions |
Date: |
Sat, 10 Nov 2012 19:50:06 +0100 |
>> 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
- Re: Proposal to improve the nomenclature of scrolling directions, (continued)
- Re: Proposal to improve the nomenclature of scrolling directions, martin rudalics, 2012/11/10
- 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, 2012/11/10
- Re: Proposal to improve the nomenclature of scrolling directions,
martin rudalics <=
- 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
- RE: Proposal to improve the nomenclature of scrolling directions, Drew Adams, 2012/11/08