Re: Allowing point to be outside the window?

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 28 Nov 2021 16:13:46 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Date: Sun, 28 Nov 2021 11:07:57 +0800
> >> 
> >> I wonder what would be involved in allowing point to be outside a
> >> window's visible area.
> >
> > Two steps:
> >
> >   1. Design the feature: how would it work? which operations would
> >      bring point back into the viewport, and which won't?  For
> >      example, a simple question: if point is outside of the viewport,
> >      what is the effect of C-f or C-n on display?
> 
> The effect would be move point forward, or to the next line, and then to
> recenter the window, so point is at the center of the window.

That's one possibility, perhaps the most obvious one.  But it isn't
the only one, and we should understand well what we want in this
regard, because Emacs sometimes moves point by itself, without the
user's say-so.

> Inserting text should probably recenter the window as well, if point is
> outside the visible area (this is also how other programs behave).

This is IMO less obvious, especially if you keep in mind that text can
be inserted by some Emacs command other than an explicit text
insertion by the user (via self-insert-command, C-y, etc.).  It is
quite possible we will need some finer granularity here, where not
_every_ insertion will bring point into the viewport.

> This is how other programs behave as well.

Emacs is much more complex than "other programs", and many
commands/functions are invoked in different contexts, where user
expectations regarding this aspect could be different.  Moreover, we
have a lot of code that disregards the context because the assumption
is that point is always visible, something that is obtained by a
coordinated effort of many parts of Emacs code (so if one of them
doesn't make point visible, some other one will).  Making this
well-orchestrated effort do something different (let alone do it
optionally, since I expect quite a few users to want not to have this
new behavior) will probably require some new protocol.