[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 15:10:57 +0100

>> 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

>> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]