emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

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