[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs terminology (not again!?)
From: |
Eli Zaretskii |
Subject: |
Re: Emacs terminology (not again!?) |
Date: |
Sat, 18 Jan 2014 12:52:52 +0200 |
> From: David Kastrup <address@hidden>
> Date: Sat, 18 Jan 2014 09:55:13 +0100
>
> > 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"
Yes, I don't see how this is important for the issue at hand. On a
text terminal, each character counts as a single pixel.
> (no idea whether it works on text terminals):
It doesn't currently, but that's just because no one bothered to
implement that.
> basically it displaces your screen window by a given distance.
Yes.
> There is no concept of a "window start" in terms of a text position
> that can move away from point
A window start is just a buffer position, so I'm not following your
argument here.
> and no real way to implement that.
??? Why not? Perhaps you mean no way to implement that easily, or
maybe in Lisp alone.
> 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.
Indeed, exposing such functionality will need a lot of supporting code
and features. But that happens with every such endeavor: e.g., when I
introduced menus on a TTY, quite a few of the changes I needed were
because some places hard-coded the assumption that TTYs cannot
possibly have any menus. Simply lifting that condition was all that
was needed.
> 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.
Very true.
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], (continued)
- 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, 2014/01/18
- Re: Emacs terminology (not again!?),
Eli Zaretskii <=
- 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
- Re: Emacs terminology (not again!?) [was: Apologia for bzr], David Kastrup, 2014/01/18