[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs terminology (not again!?)

From: David Kastrup
Subject: Re: Emacs terminology (not again!?)
Date: Sat, 18 Jan 2014 09:55:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> Date: Fri, 17 Jan 2014 19:02:53 -0800
>> From: Daniel Colascione <address@hidden>
>> Cc: Per Starb├Ąck <address@hidden>,
>>      "Richard M. Stallman" <address@hidden>, David Kastrup <address@hidden>,
>>      "address@hidden" <address@hidden>
>> Try making a mode that allows point to be off-screen while scrolling
>> like it can be in most other editors.
> It is a common misconception that Emacs cannot do this.  It can.  How
> do you think it pulls the trick of allowing you to scroll pixel-wise
> through a very large image?
> It is a UI design decision in Emacs to always show point on screen.
> But nothing prevents us from writing a mode that leaves point off
> screen, or even abandoning that decision if we want (and I'm not
> saying we do).  The infrastructure is there, check out the vscroll
> thingy and window-vscroll.

That scrolls "graphically" (no idea whether it works on text terminals):
basically it displaces your screen window by a given distance.  There is
no concept of a "window start" in terms of a text position that can move
away from point, and no real way to implement that.

Also I don't think you can mouse-mark a vscrolled off-screen region
(which would require not setting point when drag-marking a region, but
that seems conceivable) and paste it somewhere afterwards.

It would be possible to experiment around with some of those things.
Judging from my experience with pre-21.1 code (in connection with
preview-latex), this would lead to quite a number of problem reports,
just because it is an area that has been minimally exercised.  Nothing
wrong with that: cleaning out bugs is always a good idea.  But it means
that anybody experimenting with user interface design around that
functionality would be well-advised to compile Emacs from Git and be in
close communication with the developer list.  Even when "nominally"
Emacs has all the functionality he'll be needing.

David Kastrup

reply via email to

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