[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
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], (continued)
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], Per Starbäck, 2014/01/17
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], David Kastrup, 2014/01/17
- Re: Emacs terminology (not again!?), Glenn Morris, 2014/01/17
- Re: Emacs terminology (not again!?), Lennart Borgman, 2014/01/17
- Re: Emacs terminology (not again!?), Daniel Colascione, 2014/01/17
- Re: Emacs terminology (not again!?), Lennart Borgman, 2014/01/17
- Re: Emacs terminology (not again!?), Daniel Colascione, 2014/01/17
- Re: Emacs terminology (not again!?), Eli Zaretskii, 2014/01/18
- Re: Emacs terminology (not again!?), Daniel Colascione, 2014/01/18
- Re: Emacs terminology (not again!?), Eli Zaretskii, 2014/01/18
- Re: Emacs terminology (not again!?),
David Kastrup <=
- Re: Emacs terminology (not again!?), Eli Zaretskii, 2014/01/18
- Re: Emacs terminology (not again!?), David Kastrup, 2014/01/18
- Re: Emacs terminology (not again!?), Eli Zaretskii, 2014/01/18
- Re: Emacs terminology (not again!?), Lennart Borgman, 2014/01/18
- Re: Emacs terminology (not again!?), Eli Zaretskii, 2014/01/18
- Re: Emacs terminology (not again!?), Richard Stallman, 2014/01/18
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], Eli Zaretskii, 2014/01/18
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], Lennart Borgman, 2014/01/18
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], David Kastrup, 2014/01/18
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], Lennart Borgman, 2014/01/18